私は、事前計算済みのスコアで注文された何百万ものアイテムを持っています。各項目には多くのブール値の属性があります。 約1万の可能な属性が完全にあり、各項目にはダースが1つあります。タグ検索のデータストアソリューション
をリアルタイムで（数ミリ秒）の間に要求できるようにしたいと思います。
どのような解決策をお勧めしますか？私は非常にスケーラブルなものを探しています。
から
- 私たちは現在、あなたがいかなる制限を参照してください、MongoDBのと配列のインデックスを見ていますか？
- SolRが考えられますが、テキスト検索機能は必要ありません。
あなたはこの
{ score:2131, attributes: ["attr1", "attr2", "attr3"], ... }
のようなあなたのオブジェクトを保存した場合、その後、次のクエリは「ATT1とATTR2
c = db.mycol.find({ attributes: { $all: [ "attr1", "attr2" ] } })
が、このウォンを持っているすべての項目にマッチしますトンと一致すること
c = db.mycol.find({ attributes: { $all: [ "attr1", "attr4" ] } })
あなたはこのカーソルをソートする場合は、クエリは、カーソルを返し、トン鶏はちょうどそう
c = db.mycol.find({ attributes: { $all: [ "attr1", "attr2" ] }}).sort({score:1})
ようなクエリにソートパラメータを追加可能ですか見てAdvanced Queriesを見てください。
db.mycol.ensureIndex({attributes:1, score:1})
を次のように
適切なインデックスを設定することができ、あなたはMongoの操作が や他のさまざまな統計情報をかかった時間、スキャンされたどのように多くのオブジェクトを説明し
db.mycol.find({ attributes: { $all: [ "attr1" ] }}).explain()
を使用してパフォーマンス情報を取得することができます。
これは、Mongoが処理できることとまったく同じです。あなたの属性がブール型であるという事実は、ここで役立ちます。可能なスキーマは以下の通りである：
[
{
true_tags:[attr1, attr2, attr3, ...],
false_tags: [attr4, attr5, attr6, ...]
},
]
そして、私たちすることができますtrue_tagsとfalse_tagsのインデックス。また、$ in、$ all、...クエリ演算子で検索すると効率的です。
申し訳ありませんが、それは非常に明確ではありませんでしたが、ブール値では、どちらかの項目に属性があるかどうかを示しています。あなたの答えはまだありますが、もっと正確な情報を探しています。その種類のインデックスには制限がありますか（キーサイズ、インデックスの最大数などがありますが、多分私の情報は古いです）？シャーディングとはどのように機能しますか？ – log0
のRedisは
Redisのは、あなたができるデータ構造に組み込まれていますから始まる：Sorted Set =>ソートセットのすべてのメンバーはスコアに関連付けられています。例えばどちらがZRANGEBYSCOREとスコアによってランク付けすることができます。
ZRANGEBYSCORE key min max [WITHSCORES] [LIMIT offset count]
私はソートセットcommandsを見て、自分の問題としてのRedis、の感触を取得することをお勧めします（それが記載されているように）を要求します。もちろん、単一のSet要素内に、必要な数の属性を保持することができます。限りMongoDBのよう
あなたは何百万人を言及したので、あなたはあなたの問題のために働くの増分クエリを曲げることができない限り、私はは、サブ秒の応答を期待していません。
@nickdosに言及されているように、Solr Relevancyは非常に強力な機能ですが、属性の数はになります。これはすべての属性をメモリ内にすべて保持する必要があるためです。それぞれについてダースは悪くないかもしれませんが、>試してみるだけです。MongoDBのは、あなたが欲しいものを扱うことができる
「スコア順」と言ったとき、これは既に計算済みであることを意味しますか？もしそうなら、SOLRは何の利益ももたらさないかもしれません。そうでない場合、SOLRは非常に強力でカスタマイズ可能な関連性ランキングを提供します。 – nickdos
数百万のアイテムはSOLRでは問題ありませんが、10,000個の可能な属性_が問題になります。 SOLRはダイナミックフィールドをサポートしているため、すべての属性を定義する必要はありませんが、ワイド/スパースのスキーマでメモリが壊れる可能性はありますか？他の人がこれについてより良いアドバイスをすることができるかもしれません。 – nickdos
@nickdosはいスコアはあらかじめ計算されています。そして、私はあなたが間違っているのは、多くの属性が正しいことだと思います。私はmongodbがこれをどのように処理するのか分かりません。属性ごとに1つのインデックスを作成しますか？多くのインデックスを持つことも可能ですか？とにかく試してみるつもりですが、正しい戦略を見逃さないようにしたいと思います。 – log0