ハッシュド・インデックスとは（彼らはシンプルであれば申し訳ありません）

のMongoDB 2.4は私の質問があるので、ここで、私は誰もが周りに話している参照新しい機能を持っていますハッシュド・インデックスとは（彼らはシンプルであれば申し訳ありません）

んMongoDBはシャードキーを指定せずに、それらを管理しますか？または管理者がキーを選択していますか？
ハッシュとハッシュという単語がランダムなので、Hostspotの問題やディスクIOの遅延の危険性はありますか？

2013-06-02 Abdelouahab Pp

あなたはまだキーを指定する必要があり、それは内部的に、hashs（MongoDBのが見ているもの）キーを押します。ハッシュインデックスは、ホットスポットの問題を具体的に停止するように設計されています。構築方法はまだありません。 – Sammaye

これから追加のキーMD5（キー）を使用しないでください。スペースの無駄遣い？これは私が読んだように、それはランダム化され、メモリに保持されていないので、ディスクの読み込みには痛いですか？ –

優れたシャードキーを見つけるよりも重いので、ObjectIdのように単調増加するシャードキーよりも良いシャードキーが得られたときにハッシュするだけです。 – Sammaye

考えられるのは、不適切な書き込み分布を起こすような、シャードキーとして使用するフィールドにハッシュインデックスを作成できるということです（たとえば、単調に増加し、最近のエントリでホットスポットを作成するなど）。

ハッシュされたインデックスに格納されたハッシュは、128ビットmd5ハッシュの64ビットです。目的は、アプリケーションがハッシュメカニズムについて知る必要なく、キーのハッシュ値によるシャーディングを可能にすることです。

あなたはこのここでより多くの情報を見つけることができます：http://docs.mongodb.org/manual/core/sharded-cluster-internals/#sharding-hashed-shard-key-internals

出典

2013-06-02 19:04:50

ありがとうございます。「ドキュメントの範囲を広げることが重要な作業負荷（すべてのユーザーからの最近のドキュメントを見つける）の場合、他の選択肢のシャードキーが適しているかもしれません。 http://blog.mongodb.org/post/47633823714/new-hash-based-sharding-feature-in-mongodb-2-4 –

これは、作成するクエリの種類によって異なります。それらの大部分が単一のシャードキー値（idで）であれば、あなたは大丈夫ですか、それらのいくつかまたは十分なものが別の（索引付きの）属性である場合です。問題のあるケースは、常に「このIDからこのIDの範囲のレコード」によって問合せを行い、ハッシュ・インデックスを使用できない場合です。 –

とmongodbが自動的に索引を追加するので、 '_id'については自動的にそれらの索引索引を追加しますか？ –

ハッシュド・インデックスとは（彼らはシンプルであれば申し訳ありません）

答えて

関連する問題