問題タブ [nosql]

これまで見てきたことは、ブロブを格納するための単一のテーブルとそれに適用されるタグのための 2 番目のテーブルよりも興味深いものではないことを示唆しているため、何かが欠けているに違いありません。

確かに、設計パターンからある程度の利点が得られますが、SQL Server、Oracle、Postgres などの従来のデータベースを使用して構築するのではなく、「ドキュメント指向の DBMS」を使用する必要があるのはなぜでしょうか?

次のサンプルコードは1つのドキュメントしか更新しないことに驚きました。

ループして、すべてが変更されるまで更新を続けることができることはわかっていますが、それはひどく非効率的なようです。もっと良い方法はありますか？

IIRC、各Facebookユーザーは5000人の友達を持つことができます。平均は130ですが、最大値ははるかに高くなっています。それらの友達のそれぞれは、数百万のセットから引き出された0個以上のエンティティを「いいね」することができます。たとえば、N軸（カテゴリやサイズなど）でグループ化されたこれらのエンティティのサブセットを見ると、友達が気に入っているエンティティをどのように見つけることができますか？

GAEの場合、コストはデータサイズではなく計算時間です。検索時に、特定のカテゴリとサイズの友達によるすべてのエントリを見つけることはできません。各友達がアクションを実行するときにユーザーのエントリを追加できますが、それは友達が何かをするたびに最大5000のデータエントリを意味します。これは、バックグラウンドであっても、多くのCPU時間です。また、最初の追加で逃した新しい友達がアプリを試してみるのも見逃します。スペースをセグメント化することは理にかなっていますが、友達はグループ化するのが非常に難しい方法でリンクされています。

何か案は？同様の問題を解決しましたか？

2つの質問：

• コレクション（db.mycollection.remove（{}））内のすべてのデータを削除すると、以前に作成したインデックス情報は失われますか？
• インデックスを再作成する頻度（あといくつのエントリが必要ですか）。

私は次の設定をしています：

• 2 GB の RAM を搭載した Mac Pro (はい、それほど多くはありません)
• MongoDB 1.1.3 64 ビット
• 1 つのコレクションに 800 万件のエントリ
• 1 つのフィールド (整数) のインデックスが必要です

呼び出し.ensureIndex(...)には 1 時間以上かかります。実際には、その後プロセスを強制終了しました。私の印象は、時間がかかりすぎるということです。また、プロセスを終了しましたが、インデックスは.getIndexes()後で見ることができます。

ここで何がうまくいかないのか誰にもわかりますか？

nosqlムーブメントの台頭により、オブジェクトを格納するためのさまざまなオプションが表示されます。sqlバックエンドとnosqlバックエンドの両方を処理でき、2つを簡単に切り替えることができるオブジェクト永続化パターンはありますか？

Riak http://riak.basho.com/で遊んだり、少なくともWindowsシステムで実行したりしたいと思います。ソースコードをダウンロードしてコンパイルしましたが、そこで行き詰まります。どうすれば起動できますか？

私は数年間、次の Web 開発スタックを使用しています。

Java/春/休止状態/mysql/桟橋/ウィケット/jquery

特定の要件については、AJAX フロントエンドを備えた NoSQL データストアに切り替えることを検討しています。おそらく jQuery でフロントエンドを構築し、JSON を使用して Web アプリケーション ミドルウェアと通信するでしょう。より動的なクエリ機能があるため、MongoDB に傾倒していますが、まだ CouchDB を検討しています。

途中で何を使うべきかわかりません。おそらくRESTfulな何か？ルールには Drools、セキュリティには Shiro などのツールを使用しているため、Java (または Scala または Groovy) を使用することを好みます。しかし、繰り返しになりますが、すばやく簡単に操作できるものを選択したいので、他のソリューションも受け入れます。

ajax/json/nosql ソリューションを構築している場合は、使用しているツールと、それらを使用することで見つかった長所/短所について詳しく教えてください。

Recently I'm exploring NoSQL Databases. I need an advice about how to store data in the most optimal and efficient way for a given problem. I'm targeting MongoDB, now. However it should be the same with CouchDB.

Let's say we have these 3 Models:

I want to be able to ask the database these questions:

• Who has voted for this Story?
• What this User has Voted for?

I'm doing simple joins while working with a relational DB. The question is, how should I store the data for those objects in order to be most efficient.

For example, if I store the Vote objects as a subcollection of Stories it wont be easy to get the info - "What a user has voted for".

ログ分析アプリケーションを作成しているとしましょう。メインドメインオブジェクトはLogEntryになります。加えて。アプリケーションのユーザーは、関心のあるログエントリを説明するLogTopicを定義します。アプリケーションはログエントリを受信すると、それらをcouchDBに追加し、システム内のすべてのLogTopicsと照合して、トピックの基準に一致するかどうかを確認します。 。その場合、システムはエントリがトピックに一致することを記録する必要があります。したがって、LogEntriesとLogTopicsの間には多対多の関係があります。

これをRDBMSに保存する場合は、次のようにします。

CouchDBを使用して、私は最初に2つのドキュメントタイプだけを試してみました。LogEntryタイプがあり、次のようになります。

LogTopicタイプがあり、次のようになります。

matching_entries各LogTopicドキュメントのフィールドを使用してLogEntryドキュメントIDのリストを格納することにより、関係を表していることがわかります。これはある程度までは正常に機能しますが、複数のクライアントが両方とも一致するエントリをトピックに追加しようとすると問題が発生します。どちらも楽観的な更新を試み、一方は失敗します。私が現在使用している解決策は、基本的にRDBMSアプローチを再現し、次のような3番目のドキュメントタイプを追加することです。

これは機能し、同時更新の問題を乗り越えますが、2つの予約があります。

1. リレーショナルDBで行うので、このアプローチを使用しているだけだと心配しています。もっとcouchDBのような（リラックスできる？）ソリューションがあるのだろうか。
2. ビューは、1回の呼び出しで特定のトピックのすべてのエントリを取得できなくなりました。以前のソリューションではそれが可能でした（include_docsパラメーターを使用した場合）。

誰かが私のためのより良い解決策を持っていますか？使用しているビューも投稿すると役に立ちますか？