それは本当にデータセットに依存します。NoSQL 設計の第 1 のルールは、最初にクエリ シナリオを定義することです。データのクエリ方法を本当に理解したら、さまざまな NoSQL ソリューションを調べることができます。デフォルトの配布単位はキーです。したがって、ノード マシン間でデータを効果的に分割できるようにする必要があることを覚えておく必要があります。そうしないと、水平方向にスケーラブルなシステムになり、すべての作業が 1 つのノードで実行されたままになります (場合によってはクエリが改善されますが)。
また、CAP 定理を思い返す必要があります。ほとんどの NoSQL データベースは結果整合性 (CP または AP) ですが、従来のリレーショナル DBMS は CA です。これは、データの処理方法や特定のものの作成に影響を与えます。たとえば、鍵の生成はトリッキーになる可能性があります。
また、HBase などの一部のシステムにはインデックス作成の概念がないことも覚えておいてください。すべてのインデックスはアプリケーション ロジックによって構築する必要があり、更新と削除はそのように管理する必要があります。Mongo を使用すると、実際にフィールドにインデックスを作成し、比較的迅速にクエリを実行できます。また、Solr を Mongo と統合することもできます。基本的にネストされたキーと値のペアを持つ列ファミリー（別名Google BigTableスタイルのデータベース）であるHBaseのように、MongoでIDでクエリする必要はありません。
繰り返しますが、データ、何を保存したいか、どのように保存するか、そして最も重要なのはどのようにアクセスしたいかということです。Lily プロジェクトは非常に有望に見えます。私が関わっている仕事では、ウェブから大量のデータを取得し、それを保存、分析、削除、解析、分析、ストリーミング、更新などを行います。1 つのシステムだけを使用するのではなく、多くのシステムを使用します。目の前の仕事に最適です。このプロセスでは、さまざまな段階でさまざまなシステムを使用します。これにより、必要な場所にすばやくアクセスでき、リアルタイムでデータをストリーミングおよび分析する機能が提供され、重要なことに、進行中のすべてを追跡できます (製品でのデータ損失として)システムは大したことではありません）。Hadoop、HBase、Hive、MongoDB、Solr、MySQL、さらには古き良きテキスト ファイルを使用しています。これらの技術を使用してシステムを製品化することは、サーバーに Oracle をインストールするよりも少し難しいことに注意してください。いくつかのリリースはそれほど安定していないため、最初にテストを行う必要があります。結局のところ、それはビジネスの抵抗のレベルとシステムのミッション クリティカルな性質に大きく依存します。
これまで誰も言及していないもう 1 つのパスは、NewSQL です。つまり、水平方向にスケーラブルな RDBMS です。MySQL クラスター (と思います) や VoltDB など、あなたの目的に合ったものはいくつかあります。
繰り返しますが、データとアクセス パターンを理解することになります。NoSQL システムは Non-Rel、つまり非リレーショナルでもあり、非リレーショナル データ セットにより適したものです。データが本質的にリレーショナルであり、デカルト積 (結合) などを実際に実行する必要がある SQL クエリ機能が必要な場合は、Oracle に固執し、インデックス作成、シャーディング、およびパフォーマンス チューニングに時間を費やす方がよいでしょう。
私のアドバイスは、実際にいくつかの異なるシステムで遊んでみることです。見る;
MongoDB - ドキュメント - CP
CouchDB - ドキュメント - AP
Redis - メモリ内のキー値 (列ファミリーではない) - CP
Cassandra - カラム ファミリー - 利用可能でパーティション トレラント (AP)
HBase - 列ファミリー - コンシステント & パーティション トレラント (CP)
Hadoop/ハイブ
VoltDB - 非常に見栄えの良い製品であり、分散型であり、あなたのケースで機能する可能性のある関係データベースです (より簡単な移動かもしれません)。また、製品環境により適したエンタープライズ サポートも提供しているようです (つまり、ビジネス ユーザーに安心感を与えます)。
とにかくそれが私の2cです。システムをいじってみることが、自分のケースで何が実際に機能するかを知る唯一の方法です。