私は非リレーショナル データベースに非常に興味がありますが、多くの理由により、そのごく一部しか知りません。そこで、基本的なユースケース、長所と短所とともに、あなたが使用するすべての NoSQL テクノロジーをリストしたいと思います。
いくつかのテクノロジーや興味深い経験などの作業中に特定の問題が発生した場合は、コミュニティと共有してください。
個人的に私は一緒に働きました：
モンゴッド:
ユースケース: 私の意見では、優れた集約機能である自動レプリケーションが必要な場合に最適です。スケールがいい。日常的に使用するデータベースのように使用できる多くの機能があり、何らかの理由で SQL ソリューションを使用したくない場合は、Mongo が最適です。また、動的クエリが必要な場合は、mongo が最適です。また、mongodb はインデックス作成をサポートしています。これも重要な機能です。
長所: 高速、拡張性に優れ、使いやすい、内部地理空間インデックス
短所: 書き込み操作が比較的遅く、アトミック操作をブロックすると多くの問題が発生する可能性があります。メモリを消費するプロセスは、利用可能なすべてのメモリを「消費」する可能性があります。
カウチデータベース:
ユースケース: 私は Wiki が好きなプロジェクトで使用しており、その場合には完璧なデータベースだと思います。更新中に各ドキュメントが新しいリビジョンに自動的に保存されるという事実は、すべての変更を確認するのに役立ちます。事前に定義されたクエリが実行される、時々変化するデータを蓄積するため。
長所: 使いやすい、REST 指向のインターフェース、バージョン。
短所: ドキュメントの量が非常に多い (50 万以上) 場合のパフォーマンスの問題、少し純粋なクエリ機能 (Lucene を追加することで解決できる可能性があります)
シンプルDB:
ユースケース: これは Amazon のデータ サービスであり、Amazon が提供するすべてのものの中で最も安価です。機能が非常に限られているため、主な使用例は、Amazon サービスを使用したい場合に使用することですが、支払いはできるだけ少なくします。
長所: 安価で、すべてのデータがテキストのように保存されます。操作が簡単で、使いやすいです。
短所: 非常に多くの制限があります (ドキュメント サイズ、コレクション サイズ、属性数、属性サイズ)。すべてのデータがテキストのように保存される方法は、日付または数値による並べ替え中に追加の問題を引き起こします (日付または数値を保存するときにいくつかの回避策が必要な辞書式並べ替えを使用するため)。