Ответ 1

В контексте масштабирования MongoDB:

• replication создает дополнительные копии данных и позволяет автоматически переуступать другим node. Репликация может помочь с горизонтальным масштабированием чтения, если вы готовы читать данные, которые потенциально не являются последними.

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

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

Replication и sharding обычно объединяются для создания осколочного кластера, где каждый осколок поддерживается набором реплик.

С точки зрения клиентского приложения вы также имеете некоторый контроль в отношении взаимодействия репликации/осколки, в частности:

• Читать настройки
• Написать проблемы

Ответ 2

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

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

Если вы хотите масштабировать Mongo по горизонтали, вы бы оштрафовали. 10gen любит называть автоматическую настройку настройки маршрутизатора/конфигурации сервера. Возможно сделать более гетто формы осколков, где у вас есть приложение, решить, какой БД писать и.

Ответ 3

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

Sharding → Сохранение ваших музыкальных файлов в разных папках

Репликация → Синхронизация вашей коллекции с другими дисками

Ответ 4

Sharding

Sharding - это метод разделения большой коллекции среди нескольких серверов. Когда мы обследуем, мы развертываем несколько серверов mongod. И спереди, mongos, который является маршрутизатором. Приложение обращается к этому маршрутизатору. Затем этот маршрутизатор разговаривает с различными серверами, mongod s. Приложение и mongos обычно размещаются на одном сервере. У нас может быть несколько служб mongos, работающих на одном компьютере. Также рекомендуется сохранить набор из нескольких mongod (вместе именуемых набор реплик) вместо одного mongod на каждом сервере. Набор реплик синхронизирует данные в нескольких разных экземплярах, так что, если один из них опустится, мы не потеряем никаких данных. Логически каждый набор реплик можно рассматривать как осколок. Он прозрачен для приложения, способ MongoDB выбирает осколок, мы выбираем осколочный ключ.

Предположим, что для набора student мы имеем stdt_id как ключ осколка, или он может быть составным ключом. И сервер mongos, это система на основе диапазона. Поэтому, основываясь на stdt_id, который мы отправляем как ключ осколка, он отправит запрос в правильный экземпляр mongod.

Итак, что нам нужно знать в качестве разработчика?

• insert должен содержать ключ осколка, поэтому, если это многораздельный осколочный ключ, мы должны включить весь ключ осколка.
• мы должны понять, что ключ осколка находится в самой коллекции
• для update, remove, find - если mongos не задан ключ осколка - тогда ему придется транслировать запрос на все различные осколки, которые покрывают коллекцию.
• для update - если мы не укажем весь ключ осколка, мы должны сделать его многократным обновлением, чтобы он знал, что ему нужно его транслировать.

Ответ 5

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

С другой стороны, если вы загружаете главным образом обновления/записи, то в какой-то момент вы столкнетесь с узким местом записи. Если запрос на запись приходит, Mongo блокирует другой запрос на запись. Эти блоки запроса на запись до тех пор, пока не будет выполнен первый запрос. Если вы хотите масштабировать эту запись и хотите ее распараллеливать, вам необходимо реализовать очертание.