フィルタリングアプリケーションに対するelasticsearchとMongoDBの比較[終了]

この質問は、実験と実装の詳細を掘り下げる前に、アーキテクチャを選択することに関するものです。それは、やや特定の目的のための、elasticsearchとMongoDBのスケーラビリティとパフォーマンスの観点での適合性についてです。

仮説的には、どちらもフィールドと値を持つデータオブジェクトを格納し、オブジェクトの本体をクエリできるようにします。したがって、その場限りのフィールドでオブジェクトのサブセットをフィルタリングすることは、両方に適していると考えられます。

私のアプリケーションは、基準に従ってオブジェクトを選択することを中心に展開します。複数のフィールドで同時にフィルタリングすることでオブジェクトを選択します。言い換えると、クエリフィルター条件は通常、1〜5のフィールドで構成されます。一方、フィルターとして選択されたフィールドは、はるかに多くのフィールドのサブセットになります。20のフィールド名が存在することを想像してください。各クエリは、それらの20のフィールド全体から数フィールドでオブジェクトをフィルターする試みです（存在する20のフィールド名全体よりも少ない場合も多い場合もある）、この数値を使用して、フィールドからすべての個別のクエリでフィルターとして使用されるフィールド）。フィルタリングは、選択したフィールドの存在、およびフィールド値によって行うことができます。たとえば、フィールドAを持ち、フィールドBがxとyの間にあるオブジェクトをフィルターで除外します。

私のアプリケーションは継続的にこの種のフィルタリングを実行しますが、どのフィールドがどの時点でフィルタリングに使用されるかに関しては、何もないか、ほとんど一定ではありません。おそらくelasticsearchでインデックスを定義する必要がありますが、おそらくインデックスがなくても、MongoDBの速度と同等です。

ストアに入るデータに従って、それに関する特別な詳細はありません。オブジェクトが挿入された後、オブジェクトが変更されることはほとんどありません。おそらく古いオブジェクトを削除する必要があるでしょう。両方のデータストアが内部的に、またはクエリによって作成されたアプリケーションによって、データの削除が期限切れになると想定したいと思います。（あまり頻繁ではありませんが、特定のクエリに適合するオブジェクトも削除する必要があります）。

どう思いますか？そして、あなたはこの側面を実験しましたか？

この種のタスクについて、2つのデータストアそれぞれのパフォーマンスとスケーラビリティに興味があります。これは一種の建築設計の質問であり、完全に考え抜かれた提案のデモンストレーションとして、店舗固有のオプションの詳細や、それを適切に設計するためのクエリの要点を歓迎します。

ありがとう！

まず、ここで重要な違いがあります。MongoDBは汎用データベースであり、ElasticsearchはLuceneがサポートする分散テキスト検索エンジンです。人々はElasticsearchを汎用データベースとして使用することについて話していましたが、それが元の設計ではなかったことを知っています。汎用のNoSQLデータベースと検索エンジンは統合に向いていると思いますが、現状では2つは非常に異なる2つの陣営に由来しています。

私の会社ではMongoDBとElasticsearchの両方を使用しています。データはMongoDBに保存され、Elasticsearchはその全文検索機能専用に使用されます。クエリする必要があるmongoデータフィールドのサブセットのみをエラスティックに送信します。私たちのユースケースは、Mongoデータが常に変化するという点であなたのものとは異なります。レコード、またはレコードのフィールドのサブセットは、1日に数回更新される可能性があり、これはそのレコードの再インデックス付けをエラスティックに要求する可能性があります。その理由だけで、選択フィールドを更新できないため、エラスティックを唯一のデータストアとして使用することは、私たちにとって良いオプションではありません。ドキュメント全体のインデックスを再作成する必要があります。これはエラスティックな制限ではなく、Elasticの背後にある基本的な検索エンジンであるLuceneの仕組みです。あなたの場合、レコードという事実は 保存後に変更すると、その選択をする必要がなくなります。とは言っても、データの安全性が懸念される場合は、Elasticsearchをデータの唯一のストレージメカニズムとして使用することを2度考えます。ある時点で到達するかもしれませんが、まだそこにあるかどうかはわかりません。

速度に関しては、Elastic / LuceneがMongoのクエリ速度と同等であるだけでなく、「任意の時点でフィルタリングに使用されるフィールドに関してほとんど一定でない」場合、それは次の順序になる可能性があります。特にデータセットが大きくなるにつれて、マグニチュードが速くなります。違いは、基になるクエリの実装にあります。

• Elastic / Luceneは、ベクトル空間モデルと情報検索用の反転インデックスを使用します。これらは、レコードの類似性をクエリと比較する非常に効率的な方法です。Elastic / Luceneをクエリすると、すでに答えがわかっています。その仕事の大部分は、クエリ用語に一致する可能性が最も高いものによって結果をランク付けすることにあります。これは重要なポイントです。データベースとは対照的に、検索エンジンは正確な結果を保証することはできません。彼らはあなたのクエリにどれだけ近づくかによって結果をランク付けします。ほとんどの場合、結果は正確に近いです。
• Mongoのアプローチは、より汎用的なデータストアのアプローチです。JSONドキュメントを相互に比較します。必ずすばらしいパフォーマンスを得ることができますが、実行するクエリに一致するようにインデックスを慎重に作成する必要があります。具体的には、クエリに使用する複数のフィールドがある場合、複合キーを慎重に作成する必要がありますするデータセットをできるだけ速く減らすよう。たとえば、最初のキーはデータセットの大部分をフィルタリングし、2番目のキーは残りのデータをさらにフィルタリングする必要があります。クエリが、定義されたインデックス内のキーおよびそれらのキーの順序と一致しない場合、パフォーマンスはかなり低下します。一方、Mongoは真のデータベースであるため、正確さが必要なものである場合、Mongoが提供する答えは適切です。

古いレコードを期限切れにするために、ElasticにはTTL機能が組み込まれています。Mongoはバージョン2.2で導入したばかりだと思います。

予想されるデータサイズ、トランザクション、精度などのその他の要件や、フィルターの外観がわからないため、具体的な推奨を行うことは困難です。うまくいけば、ここにあなたが始めるのに十分です。