Эффективен ли шардинг для небольших коллекций?

11

Похоже, что разделение базы данных отлично, если у меня огромные коллекции. Что если у меня много коллекций довольно больших размеров? Допустим, для 1 коллекции из 100 000 000 документов (не очень больших комментариев) эффективен шардинг. Это также эффективно для 10 000 коллекций с 10 000 документов каждая?

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

mongodb Жоау Пинту Херонимо
источник

Ответы:

5

Это также эффективно для 10 000 коллекций с 10 000 документов каждая?

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

Однако, когда у вас есть 10 000 небольших коллекций, ваша головная боль, вероятно, заключается не в «балансировке данных». С этим множеством небольших коллекций ваша проблема, вероятно, связана с отслеживанием этих коллекций. В зависимости от размера вашего документа, вы можете даже не нарушить нижний предел для шардинга.

Для действительно небольших коллекций вы можете использовать малоизвестную команду movePrimary для управления расположением ваших данных.

Конечно, с другой стороны, почему у вас есть 10 тыс. Коллекций? Коллекция не нуждается в однородных объектах, и с 10 000 коллекциями большинство из них должно быть сгенерировано. Вполне возможно хранить разные «типы» данных в одной и той же коллекции, сокращать количество коллекций, а затем включать тип как часть ключа шарда.

Гейтс В.П.
источник
Спасибо, я точно пытался узнать, смогу ли я лучше всего избавиться от этих тонн коллекций и сделать большую. Раньше у меня были тонны коллекций, потому что я слышал общее убеждение: «Огромные коллекции вредны для вас, потому что индексы не помещаются в ОЗУ, и будет очень медленно запрашивать и обновлять их». Но я думаю, что для решения этой проблемы был создан шард ... Спасибо !!
Жоау Пинту Херонимо
Честно говоря, я нахожу, что вы часто можете «обманывать» и индексы. Если у вас есть две коллекции fooи barс той же структурой данных, вы можете объединить их в bazколлекции и переопределить _ids(в коде): { _id: "foo123" }, { _id: "bar123" }. У вас есть больший индекс, но у вас есть только один индекс, который включает тип. Не требование, просто «пища для размышлений».
Гейтс VP
4

Разделение MongoDB работает, разбивая коллекцию на более мелкие «куски» и равномерно распределяя их по нескольким машинам. Размер порции по умолчанию, который обычно является наиболее эффективным, составляет 200 МБ. Поэтому, если коллекция не станет намного больше 200 МБ, она не будет разбиваться на куски и, следовательно, не будет иметь права на разделение, поэтому никаких преимуществ не будет.

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

Крис Фулстоу
источник
FYI размер блока по умолчанию составляет 64 МБ на 1,8.
Гейтс VP