Как построить шардинг на основе хеша в MongoDB - PullRequest
Новая
       6

Как построить шардинг на основе хеша в MongoDB

3 голосов
/ 27 октября 2011

Я ищу хороший подход для выполнения следующих действий:

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

Вопросы:

  1. Этобезопасный / хороший подход?
  2. Какой хороший способ реализовать его
  3. Есть ли какие-либо ошибки, касающиеся настройки кластера сегментов, о которых мне следует знать.

Спасибо!

Ответы [ 2 ]

1 голос
/ 27 октября 2011

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

Ваши вопросы:

  1. Да, если вы правильно его внедрили.
  2. То, что я делаю на нашем собственном слое ORM, - помечаю определенные поля в документе как заштрихованное поле. Наш ORM затем автоматически сгенерирует хеш-значение для этого значения поля непосредственно перед записью или чтением документа. Исходящие запросы затем украшаются тем значением хеша (в нашем случае всегда называемым «хеш»), которое затем использует монтирование MongoDB для нацеливания на шарды. Очевидно, что в этом сценарии «хеш» всегда является единственным ключом шардинга.
  3. Самым важным на сегодняшний день является создание хороших хэшей. Многие значения полей (чаще всего поле _id на основе ObjectId) являются инкрементными, поэтому ваш алгоритм хеширования должен быть таким, чтобы сгенерированные хэши для инкрементальных значений приводили к хеш-значениям, которые попадают в разные сегменты. Другие проблемы включают выбор подходящего размера куска.

Некоторые недостатки, которые следует учитывать:

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

Удачи.

ОБНОВЛЕНИЕ 25/03/2013: Начиная с версии 2.4 MongoDB изначально поддерживает хэш-индексы.

0 голосов
/ 27 октября 2011

Это хорошая и безопасная идея.

Однако выбор хеш-функции имеет решающее значение:

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

Я успешно выбрал: единообразие, двоичную форму, непротиворечивость и уникальность с помощью функции murmurHash3:

value -> murmurmHash (valueInBinaryForm), за которым следует valueInBinaryForm

...