По Адаму Комерфорда , старший инженер решения
Sharding — это популярная функция в MongoDB, в основном используемая для распределения данных по кластерам для горизонтального масштабирования. Преимущества шардинга для масштабируемости хорошо известны, и зачастую это один из основных факторов выбора MongoDB в первую очередь, но по мере того, как вы добавляете сложность в распределенную систему, вы увеличиваете вероятность попадания в проблему.
Хорошей новостью является то, что многие из распространенных проблем, с которыми люди сталкиваются при переходе в изолированную среду, можно избежать, и большинство из них можно смягчить, если вы уже ударили по ним.
Предупрежден — значит вооружен, и поэтому, учитывая это, мы хотим, чтобы пользователи знали о передовых практиках и ситуациях, которых следует избегать при внедрении шардинга в вашей среде. В этой серии из трех частей мы обсудим несколько подводных камней и ошибок, которые, как мы видели, происходят с некоторой регулярностью среди пользователей MongoDB. Мы дадим обзор проблемы, как она возникает, как ее избежать, а затем обсудим некоторые возможные стратегии смягчения последствий, если вы уже столкнулись с этой проблемой.
Следует отметить, что некоторые из этих тем сами по себе достойны полных технических статей, что выходит за рамки сравнительно короткого поста в блоге. Рассматривайте эти посты как хорошую отправную точку и, если вы еще не сталкивались ни с одной из этих проблем, это информативная предостерегающая история для всех, кто работает с кластером сегментированного MongoDB. Для получения дополнительной информации, пожалуйста, смотрите раздел Sharding в руководстве MongoDB.
Многие из этих тем также рассматриваются в рамках классов M102 (MongoDB для администраторов баз данных) и M202 (расширенное развертывание и эксплуатация), которые доступны бесплатно в университете MongoDB .
Для нашего первого набора предостерегающих рассказов мы сосредоточимся на осколках ключей .
1. Использование монотонно увеличивающегося ключа шарда (например, ObjectID)
Хотя это одна из наиболее часто обсуждаемых тем в блогах, учебных материалах, Днях MongoDB и т. Д., Выбор ключа осколка остается трудоемким занятием для начинающего администратора баз данных MongoDB или разработчика.
Наиболее распространенная ошибка, которую мы видим, — это выбор монотонно увеличивающегося ключа шарда при использовании шардинга на основе диапазона, а не хэшированного шардирования , что является причудливым способом сказать, что значение ключа шарда для новых документов только увеличивается. Примерами этого могут быть отметка времени (естественно) или все, что имеет компонент времени в качестве наиболее значимого компонента, например ObjectID (первые 4 байта являются отметкой времени).
Почему это плохая идея?
Краткий ответ — масштабируемость вставки. Если вы выберете такой ключ шарда, все вставки (новые документы) перейдут в один блок — блок с самым высоким диапазоном, и он никогда не изменится. Следовательно, независимо от того, сколько шардов вы добавите, ваша максимальная емкость записи никогда не увеличится — вы будете когда-либо записывать новые документы только в один блок, и этот блок будет когда-либо жить только в одном фрагменте.
Иногда этот тип шард-ключа может быть правильным выбором, но если это так, то вы не сможете масштабировать для емкости записи.
Возможные стратегии смягчения
-
Изменить ключ шарда — это проблематично для больших коллекций, потому что данные должны быть выгружены и повторно импортированы.
-
В частности, используйте ключ хеша на основе хеша , который позволит использовать одно и то же поле, обеспечивая хорошую масштабируемость записи.
2. Попытка изменить значение ключа осколка
Ключи шарда являются неизменяемыми (не могут быть изменены) для существующего документа. Эта проблема обычно возникает только при разбиении ранее незащищенной коллекции. До шардинга возможны определенные обновления, которые больше не возможны после того, как коллекция будет очищена.
Попытка обновить ключ шарда для существующего документа потерпит неудачу со следующей ошибкой:
cannot modify shard key's value fieldid for collection: foo.foo
Возможные стратегии смягчения
- Удалите и заново вставьте документ, чтобы изменить ключ осколка, а не пытаться обновить его на месте. Следует отметить, что это не будет атомарной операцией, поэтому следует делать это с осторожностью.
Теперь у вас есть лучшее понимание того, как выбрать и изменить свой ключ шарда, если это необходимо. В нашем следующем посте мы рассмотрим некоторые потенциальные препятствия, с которыми вы столкнетесь при масштабировании вашего окружения.
Если вы хотите больше узнать о методах масштабирования для MongoDB, просмотрите слайды и видео с нашего недавнего вебинара о том, как добиться масштабирования с MongoDB, в котором рассматриваются три различных способа достижения масштаба с MongoDB.