0
クエリに使用される列の組み合わせが複数ある場合、MongoDBは適しているため、すべての列のインデックスを作成することは実現不可能ですか? MongoDBは、列にインデックスがなく、その列に何百万ものエントリがあるとしたらどうしますか?MongoDB vs Columnar
クエリに使用される列の組み合わせが複数ある場合、MongoDBは適しているため、すべての列のインデックスを作成することは実現不可能ですか? MongoDBは、列にインデックスがなく、その列に何百万ものエントリがあるとしたらどうしますか?MongoDB vs Columnar
インデックスがない場合は、データベースシステムと同様にテーブルスキャンが実行されます。
ドキュメントがメモリに保存されている場合でも、これは比較的高速ですが、コレクション内のドキュメントの数に基づいて一定の時間がかかります。 O(n)
文書ごとにさまざまなキーの小さなセットや、すべての文書に必要なキーの数が多いという問題がありますか?
カラム指向のデータストアでは、さまざまな属性をモデル化するために大量のカラムを格納する必要がありますが、ドキュメントデータモデルのためにmongodbは柔軟性があります。
属性の数が少ない(大量の属性の中から)文書がある場合、これは索引付け可能であり、O(logn)になります。
あなたの文書は次のようになります。
db.mycollection.ensureIndex({"attrs.n":1, "attrs.v":1})
と、次のように照会可能であること:
{
"name":"some name",
"attrs":[
{"n":"subject","v":"the subject"},
{"n":"description","v":"Some amazing description"},
{"n":"comments","v":"Comments on this thing"},
]
}
は、このような割出して、私が持っているもの
db.mycollection.find({attrs: {$elemMatch: {n: "subject", v: "the subject"}}})
は、スター・スキーマです。私はこれをデノーマル化して、うまく動作するcolumnar dbに格納することができます。私は、各文書(行)に対して同じ数の属性を持っています。私が望むのは、TOP Nタイプのクエリを実行する能力です。私は新しいバージョンでいくつかの作業が行われていることを知っています(2.2私は集計しています)ので、TOP Nを行うことができます。しかし、すべての属性のパフォーマンスが十分に良いかどうかはわかりませんでしたそれぞれの属性ごとにインデックスを作成することはできません。私はMongoDBが私の問題の解決策ではないと思っていますが、私が何か不足しているかどうかを見たいと思っていました! – PrakashT
質問を、あなたがしたいことの種類の具体的な例で更新できますか? (データとクエリ)すべてのインデックスには問題はありませんが、データをモデル化する別の方法があると私は同意します。 –
MongoDBを大量のデータ(および異なるクエリ)でテストする前に、MongoDBに圧縮がないことがわかりました。それは私の大きなボトルネックです。 – PrakashT