問題タブ [nosql]

ログ分析アプリケーションを作成しているとしましょう。メインドメインオブジェクトは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パラメーターを使用した場合）。

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

これは明白な（またはそれほど明白ではない）質問のように思えるかもしれませんが、説明させてください。GoogleのデータベーステクノロジーであるBigTableを使用してGoogleAppEngineサイトをコーディングしています。App Engineのコーダーなら誰でも、GoogleにはGQLと呼ばれる独自の限定されたクエリ言語があることを知っているでしょう。その結果、Googleがデータをフェッチするためにバックエンドメソッドで生の文字列クエリを使用していないと想定しているため、アプリでSQL（またはGQL）インジェクションのチェックを行わないように誘惑されます。

さらに、CouchDB、MongoDB、その他のオブジェクトまたはドキュメント（別名NoSQL）データベースなどのDBテクノロジーのライブラリを使用すると、悪意のあるユーザーがデータベース操作コマンドを挿入しているかどうかを確認する必要がなくなるようです。多くの場合、データベース内のオブジェクトを選択した言語のオブジェクトに直接マップするライブラリがあります。これを行うSQLライブラリもたくさんあることは知っていますが、あるレベルでは、パラメータを組み合わせて文字列に対してクエリを実行していると思います。したがって、これらのフレームワークでもSQLインジェクション保護を使用する必要があります。

私は近視眼的ですか？それとも、次の優れたDBシステムが定着し、それらのシステムへの注入が行われるのは時間の問題ですか？

NOSQLパターンに関するこの記事に出くわしました（私のものではありません）。開発者の観点から、多くの NOSQL 実装パターン (ハッシュやレプリケーション パターンなど) をカバーしています。

全体として、誰かが質問について自問している場合に非常に役立ちます。

NOSQL 実装パターンに関する情報はどこにありますか?

ここに質問を追加しました。お気軽に回答を追加してください。

私は、データ サイズと SQL クエリが重くなるアプリケーションに取り組んでいます。Cassandra と Amazon SimpleDB の間で考えています。この種のシナリオでどちらがより適しているか教えてください。

Cassandra データのインデックス作成は Amazon simpleDB より優れているように見えますが、Amazon SimpleDB に比べてクエリのオプションが少なくなっています。Amazon SimpleDB の I/O レートが高いようです。

複雑なユース ケースのほとんどは、ユーザーがいくつかの興味深いアクティビティに絞り込むことができるさまざまなフィルターを使用したユーザー アクティビティです。

これら 2 つ以外に、よりクリーンで優れた解決策があると思われる場合は、提案してください。

ビューが要求されたときに「マップ」が最後に要求されてから追加されたドキュメントにのみ実行されることをどこかで読んだと思いますか？これはどのように決定されますか？シーケンス番号について何か見たと思いました。これはあなたが得ることができるものですか？_revフィールドの末尾にあるUUIDの一部ではありませんか？

ビュー全体（すべてのレコードにわたって）の「再計算」を強制する方法はありますか？

今後のプロジェクトのストレージプラットフォームを評価しており、Cassandraに戻ってきます。このプロジェクトでは、データの量を失うことは容認できません。これまでリレーショナルデータベース（Microsoft SQL Server）を使用してきましたが、データが非常に多様で大きいため、保存とクエリが問題になっています。

Cassandraはプライマリデータストアとして使用するのに十分堅牢ですか？または、アクセスを高速化するために既存のデータをミラーリングするためにのみ使用する必要がありますか？

4 つのオプションがあり、その中に 1 つの答えがあるゲーム アプリケーションを実装しました。オプションはランダムに配置されます。選択した選択肢が正しいかどうかを確認するにはどうすればよいですか?

SimpleDBはMongoDBに似ていますか？

実稼働システムで使用できる実稼働品質の nosql ストアはありますか。私はcassandra、tokyodb、couchdbなどを見てきましたが、どれも本番環境のような環境に展開する準備ができていないようです. 毎分数千のリクエストと、大量の読み取り/書き込み/更新について話しています。私の唯一の懸念は、速度とサービス時間です。nosqlストアを効果的に使用する本番システムを知っている人はいますか? Google/Yahoo/IBM などの大企業が支援する nosql ストアを知っている人はいますか?

格納されたエンティティ間の関係を格納/維持するための nosql キー値ストアを探しています。Google App Engine のデータストアでは、エンティティ間の所有関係と非所有関係が許可されていることは知っています。人気のある nosql ストアのいずれかが同様のものを提供していますか?

それらのほとんどはスキーマレスですが、関係をキー値ストアに割り当てる方法はありますか?