私が行った調査に基づいて、キー値ストアは適していないと思われますが、より直接的な入力を取得したかったのです。
- キー値ストアが私の使用法にとって実行可能なソリューションであるかどうかを判断してください。
- 代わりにドキュメント ストアを好む理由を明確に説明できるようにします。
私のユースケースを説明するには
多くの「ドキュメント」で構成されるアプリケーションがあります。これらは現在、一種の CMIS リポジトリに保存されています。ただし、アプリケーションは、elasticsearch にインデックスが作成された後にのみ、これらのドキュメントと対話します。これは、すべての読み取り操作がelasticsearchにヒットし、すべての書き込み操作がelasticsearchとリポジトリの両方を更新することを意味します.
リクエストされた機能により、現在のリポジトリが厳しすぎることが明らかになり、そのレベルでモデル スキーマを強制する理由はまったくありません。もちろん、これは NoSQL オプションの調査につながりました。
これらの「ドキュメント」をelasticsearchインデックスに入力するには、それらがどこかに存在する必要があり、インデックスに読み込まれるときにすべてを取得してページ分割できる必要があります（データを入力するために、このステップで発生する集計もあります）既存のフィールドから構築されたフィールド)。
現在、すべての取得は実際にはドキュメントのタイプに基づいて段階的に行われていますが、この要件は交渉可能であり、代わりにすべてのタイプの単純なすべての取得で十分かもしれませんが、理想的ではありません.
キー値ストアに関する私の理解では、ストアは格納する値について何も認識しておらず、キーによってのみ参照できます。これにより、キーの完全なリストをどこにも維持する予定がない場合に、 get allを実行できるかどうか疑問に思います。辞書をキー (redis) として使用することをサポートするキー値ストアがあることを確認しました。これが型でクエリできることを意味するのか (辞書のエントリの場合)、または値をフェッチできるようにするために完全な辞書を知る必要があるのかどうかはわかりません。
インデックスの作成は、elasticsearch に障害が発生した場合にのみ発生する必要があるため、パフォーマンスは最優先事項ではありません (ただし、パフォーマンスが損なわれることはありません)。私にとって、MongoDB はほぼ完璧にフィットするように思えます。ドキュメントを保存し、タイプ別に簡単にクエリを実行できます。
- 私の使用例を考えると、ドキュメント ストアは適切な決定のように思えますか?
- これもキー値ストアによって合理的に解決できますか?
- 1 つを別のものよりも使用する利点は他にありますか?
念のため、ドキュメント ストアについては、CouchDB、Couchbase、および MongoDB を比較してきました。キー値ストアについては、Redis と BerkeleyDB を検討してきました。