まず、ここで重要な違いがあります。MongoDBは汎用データベースであり、ElasticsearchはLuceneがサポートする分散テキスト検索エンジンです。人々はElasticsearchを汎用データベースとして使用することについて話していましたが、それが元の設計ではなかったことを知っています。汎用のNoSQLデータベースと検索エンジンは統合に向かっていると思いますが、現状では、2つは2つのまったく異なるキャンプから来ています。
私の会社ではMongoDBとElasticsearchの両方を使用しています。データをMongoDBに保存し、Elasticsearchをその全文検索機能専用に使用します。クエリする必要のあるmongoデータフィールドのサブセットのみをelasticに送信します。私たちのユースケースは、Mongoデータが常に変化するという点であなたのユースケースとは異なります。レコード、またはレコードのフィールドのサブセットは1日に数回更新でき、これにより、そのレコードのエラスティックへのインデックスの再作成が必要になる場合があります。その理由だけでも、selectフィールドを更新できないため、elasticを唯一のデータストアとして使用することは適切なオプションではありません。ドキュメント全体のインデックスを再作成する必要があります。これは弾力性のある制限ではありません。これは、弾力性の背後にある基盤となる検索エンジンであるLuceneの仕組みです。あなたの場合、一度保存されるとレコードが変更されないという事実により、その選択をする必要がなくなります。そうは言っても、データの安全性が懸念される場合は、Elasticsearchをデータの唯一のストレージメカニズムとして使用することを考え直します。いつかそこに到達するかもしれませんが、まだそこにあるかどうかはわかりません。
速度に関しては、Elastic / LuceneがMongoのクエリ速度と同等であるだけでなく、「どのフィールドがいつでもフィルタリングに使用されるかについての定数がほとんどない」場合は、次のようになります。特にデータセットが大きくなるにつれて、桁違いに速くなります。違いは、基盤となるクエリの実装にあります。
- Elastic / Luceneは、情報検索にベクトル空間モデルと転置インデックスを使用します。これは、レコードの類似性をクエリと比較する非常に効率的な方法です。 Elastic / Luceneにクエリを実行すると、その答えはすでにわかっています。その仕事のほとんどは、クエリ用語に一致する可能性が最も高い結果によって結果をランク付けすることにあります。これは重要なポイントです。データベースとは対照的に、検索エンジンは正確な結果を保証することはできません。クエリにどれだけ近づいたかによって結果をランク付けします。ほとんどの場合、結果はほぼ正確です。
- Mongoのアプローチは、より汎用的なデータストアのアプローチです。 JSONドキュメントを相互に比較します。どうしても優れたパフォーマンスを得ることができますが、実行するクエリに一致するようにインデックスを慎重に作成する必要があります。具体的には、クエリを実行するフィールドが複数ある場合は、複合キーを慎重に作成して、クエリされるデータセットをできるだけ速く削減する必要があります。例えば。最初のキーはデータセットの大部分をフィルタリングし、2番目のキーは残っているものをさらにフィルタリングする必要があります。クエリがキーと定義されたインデックス内のキーの順序と一致しない場合、パフォーマンスはかなり低下します。一方、Mongoは真のデータベースであるため、正確さが必要な場合は、Mongoが提供する答えが明確になります。
古いレコードを期限切れにするために、ElasticにはTTL機能が組み込まれています。 Mongoはバージョン2.2の時点で導入したばかりだと思います。
予想されるデータサイズ、トランザクション、精度、またはフィルターがどのように表示されるかなど、他の要件がわからないため、具体的な推奨事項を作成するのは困難です。うまくいけば、ここにはあなたが始めるのに十分なものがあります。