elasticsearch v.s.フィルタリングアプリケーション用MongoDB

Question

この質問は、実験と実装の詳細を掘り下げる前にアーキテクチャ上の選択肢を作ることについてです。これは、スケーラビリティとパフォーマンスの面で、elasticsearch v。 MongoDBは、やや特殊な目的のために。

暫定的には、フィールドと値を持つデータオブジェクトを格納し、そのオブジェクトの本体を照会できるようにします。おそらく、アドホックで選択されたフィールドに従ってオブジェクトのサブセットをフィルタリングすることは、両方にとって適切なものです。

私のアプリケーションは、基準に従ってオブジェクトを選択することを中心に回ります。 これは、1つ以上のフィールドで同時にフィルタリングしてオブジェクトを選択し、別の言い方をすると、そのクエリフィルタリング基準は通常、1〜5フィールドのいずれかを含み、場合によってはさらに多くなります。一方、フィルタとして選択されたフィールドは、はるかに多くのフィールドのサブセットになります。画像は約20のフィールド名が存在し、それぞれのクエリは、フィールド全体の20フィールドのうちのいくつかのフィールドでオブジェクトをフィルタリングしようとしています。フィールドを離散問合せごとにフィルタとして使用するフィールドに変換します）。フィルタリングは、フィールド値だけでなく、選択されたフィールドの存在によっても可能である。フィールドAを持ち、フィールドBがxとyの間にあり、フィールドCがwに等しいオブジェクトを除外します。

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

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

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

私は、この種のタスクのために、2つのデータストアのそれぞれのパフォーマンスとスケーラビリティに興味があります。これは建築的な質問の一種であり、店舗固有のオプションやクエリーの基礎知識の詳細は、十分に考案された提案のデモンストレーションとして歓迎されます。

ありがとうございます！

Answer 1

まず、ここで重要な区別があります。MongoDBは汎用データベースで、ElasticsearchはLuceneが支援する分散テキスト検索エンジンです。人々はElasticsearchを汎用データベースとして使用することについて話していましたが、そのオリジナルデザインではないことを知っています。私は汎用のNoSQLデータベースと検索エンジンが統合のために進んでいると思いますが、それは2つの非常に異なるキャンプから来ています。

私の会社でMongoDBとElasticsearchの両方を使用しています。私たちはMongoDBにデータを格納し、Elasticsearchをそのフルテキスト検索機能専用に使用します。私たちは、質問する必要があるmongoデータフィールドのサブセットのみをエラスティックに送信します。私たちのユースケースは、Mongoのデータが常に変化するという点で、あなたのレコードとは異なります。レコードのフィールドまたはレコードのサブセットは、1日に数回更新することができ、そのレコードのインデックスを再作成する必要があります。その理由だけで、選択したフィールドを更新することはできないため、単独のデータストアとしてのelasticを使用するのは良い選択肢ではありません。私たちは文書全体を再索引付けする必要があります。これは弾力的な制限ではありませんが、これはLuceneがどのように動作するか、弾性の背後にある基本的な検索エンジンです。あなたのケースでは、一度保存されたレコードが変更されないという事実は、あなたがその選択をしなくて済むことを防ぎます。データの安全性が懸念される場合、Elasticsearchをデータの唯一の記憶メカニズムとして使用することについて2回考えています。それはある時点でそこに着くかもしれないが、私はまだそこにいるのか分からない。

スピードの点では、Elong/LuceneはMongoの検索速度に匹敵するだけでなく、「いつでもフィルタリングに使用されるフィールドが非常に少ない」というあなたのケースでは、特にデータセットが大きくなるにつれて、数桁速くなる可能性があります。差は、基礎となるクエリの実装である：

• 弾性/ Luceneのクエリに対してレコードの類似性を比較する非常に効率的な方法である、Information RetrievalためVector Space Modelとinverted indexesを使用します。 Elastic/Luceneに問​​い合わせると、それはすでに答えを知っています。その仕事の大部分は、あなたの検索条件に一致する最も可能性の高いものによって結果をランキングすることにあります。これは重要なポイントです。データベースとは対照的に、検索エンジンは正確な結果を保証するものではありません。彼らはあなたの質問にどのくらい近づくかによって結果をランク付けします。ほとんどの場合、結果は正確に近いです。
• Mongoのアプローチはより一般的な目的のデータストアのアプローチです。 JSONドキュメントを互いに比較します。あなたは偉大なパフォーマンスを忘れずに得ることができますが、実行するクエリに合わせて索引を慎重に作成する必要があります。具体的には、照会するフィールドが複数ある場合は、できるだけ早く照会されるデータセットを減らすように、慎重にcompound keysを作成する必要があります。例えば。最初のキーはデータセットの大部分をフィルタリングし、2番目のキーはさらに残りのものをフィルタリングする必要があります。クエリがキーと定義されたインデックスのキーの順序と一致しない場合、パフォーマンスはかなり低下します。一方、Mongoは真のデータベースなので、正確さがあなたの必要とするものなら、答えが出てくるでしょう。

古いレコードが期限切れになると、ElasticにはTTL機能が組み込まれています。 Mongoはバージョン2.2のように導入しました。

予想されるデータサイズ、トランザクション、正確さ、フィルタの外観などの他の要件がわからないため、具体的な推奨事項を作成するのは難しいです。うまくいけば、ここにあなたを始めさせるのに十分です。