Какой Shard Key мне выбрать для моей MongoDB?

В настоящее время у меня работает один сервер MongoDB (в производстве). Самая большая коллекция в нем называется User. Эта коллекция имеет многоключевой (массив) индекс. Доминирующий запрос к коллекции User — это запрос $or к значениям в индексированном поле с несколькими ключами. Другое поле в этой коллекции представляет собой массив PageViews.

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

В различных статьях отмечается, что создание ключа осколка для случайного значения не является хорошей идеей. Это связано с тем, что вы теряете изоляцию запросов. Но, учитывая, что я все равно не могу добиться хорошей изоляции запросов, должен ли я просто сегментировать случайное значение?

Кто-нибудь еще был в такой ситуации? Подумайте о каких-нибудь хороших вариантах?


mongodb
person motormal    schedule 15.01.2013    source источник
comment
Опубликуйте свою структуру коллекции пользователей и критерии запроса для любых предложений.   -  person muruga    schedule 16.01.2013
comment
когда вы говорите запрос $or к значениям в мультиключе, вы имеете в виду запрос $in? Пожалуйста, опубликуйте пример документа и наиболее распространенные запросы, чтобы было понятно, каков вариант использования. Также важно знать, как вы пишете в коллекцию (т.е. как вы обновляете документ пользователя?)   -  person Asya Kamsky    schedule 16.01.2013

Ответы (1)


arrow_upward
0
arrow_downward

У меня есть план, который, я думаю, сработает, поэтому я решил поделиться им с сообществом.

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

Тогда моим решением будет выяснить, какой тип элемента чаще всего запрашивается. В своем сценарии я знаю, что это такое, и я бы сказал, что этот тип элемента запрашивается более чем в 90% случаев. Затем я создам еще одно поле в документе, в котором будет храниться последнее значение элемента этого типа, сохраненное в мультиключе. Затем я буду использовать это новое поле в качестве ключа осколка. Наконец, я изменю прикладной уровень на первый запрос в новом поле. Если этот запрос завершится ошибкой, я сделаю запрос в многоключевом поле. 90%+ моих запросов должны быть изолированы. Остальным придется бегать по всем осколкам. Похоже на хороший компромисс.

person motormal    schedule 16.01.2013
comment
Оказывается, моя идея все-таки не сработала. Я не знал, что значения ключа сегмента неизменяемы. Итак, мое единственное решение сейчас - перестроить мои данные/приложение, чтобы вообще не использовать мультиключ. Болезненно, но когда я закончу, у меня будет идеальная ситуация — мое индексное поле также будет моим ключом осколка. У меня будет изоляция запросов, распределение записи и высокая кардинальность. Для всех, кто находится в моей ситуации, я бы посоветовал вам не отказываться от повторной архитектуры как возможного решения. Используйте инструмент так, как он предназначен для использования, вероятно, лучшая идея. - person motormal; 17.01.2013