Sharding по ObjectID, это правильный путь?

Question

Я, как и многие другие, думаю о правильном подходе к осколкам моих коллекций в Монго.Главный вопрос - как работает автоматическое разделение?

Официальный документ говорит: «MongoDB масштабируется горизонтально с помощью архитектуры автоматического разделения (разбиения)» и «Чтобы разделить коллекцию, мы задаем шаблон ключа разделения."с пометкой «Важно правильно подобрать ключ шарда для коллекции» :).http://www.mongodb.org/display/DOCS/Sharding+Introduction#ShardingIntroduction-ShardKeyshttp://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key

Теперь вопрос - «это правильный ключ» (sharding от ObjectID)?

db.runCommand({ shardcollection : "test", key : { _id : 1 }})

Что происходит внутри Mongo?Как Монго будет разбивать данные на куски в этом случае?Предполагая, что у меня изначально есть 10 миллионов записей с 2 ​​серверами шардов - что произойдет на стороне Mongo, когда я захочу добавить еще 2 сервера шардов, когда сбор достигнет 20 миллионов записей?Я не смог найти этот уровень детализации нигде в источниках, связанных с Монго.

Учитывая случайный характер автоматически сгенерированного _id и его структуру,

... http://www.mongodb.org/display/DOCS/Object+IDs ...

Я бы осколок младшим значащим байтом (порядок rtl) с чанками, разделенными на значение 2-3 байта - это обеспечитпростой способ шардинга с помощью 2 ^ N серверов шардов - 2, 4, 8, .., 256 серверов шардов с более или менее равномерной нагрузкой на каждый шард и с минимальной необходимой конфигурацией.Насколько я понимаю, Mongo поддерживает только шардинг / чанкинг по явно заданным диапазонам, и моя идея не сработает.Это правда?

Answer 1

Обычно не рекомендуется использовать идентификатор объекта по умолчанию в качестве ключа шарда, поскольку он имеет встроенную временную метку и монотонно увеличивается во времени.Это может хорошо работать, если вы делаете много обновлений, так что это касается старых и новых документов равномерно распределенным способом.Тем не менее, это действительно плохие новости, если ваше приложение сильно загружено, поскольку большинство ваших записей будут идти в один фрагмент.Это связано с тем, что записи будут отправляться в осколок, которому принадлежит чанк [nearCurrentTimestamp -> infinity].

Каждый монг отслеживает запись трафика в осколки и использует очень простую эвристику, чтобы определить, стал ли чанк слишком большимнеобходимо разделить (пороговый размер настраивается через chunkSize).

Когда вы добавляете новый кластер в кластер, балансировщик (http://www.mongodb.org/display/DOCS/Sharding+Administration#ShardingAdministration-Balancing) увидит дисбаланс чанка и начнет миграцию чанков вновые шарды.

Mongo поддерживает шардинг на основе диапазонов, однако это не означает, что диапазоны являются фиксированными, поскольку фрагменты могут быть разбиты на более мелкие диапазоны и перемещаться по кластеру с течением времени.

Answer 2

Новая впечатляющая функция в версии 2.4 заключается в том, что поддерживается хешированный индекс, и его можно использовать в качестве Shard Keys.Таким образом, ответ на ваш главный вопрос «Разделение по ObjectID, это правильный путь?» может быть да, сейчас!

Больше ссылок в официальных документах:

Хэшированные осколочные ключи

http://docs.mongodb.org/manual/core/sharded-cluster-internals/#hashed-shard-keys

Индекс хэширования

http://docs.mongodb.org/manual/core/indexes/#hashed-index