Набор реплик означает, что у вас есть несколько экземпляров MongoDB, каждый из которых отражает все данные друг друга. Набор реплик состоит из одного мастера (также называемого «первичным») и одного или нескольких подчиненных (он же вторичный). Операции чтения могут обслуживаться любым ведомым устройством, поэтому вы можете повысить производительность чтения, добавив дополнительные ведомые устройства в набор реплик (при условии, что ваше клиентское приложение способно фактически использовать различные члены набора). Но операции записи всегда выполняются на главном сервере набора реплик и затем распространяются на ведомые устройства, поэтому запись не будет выполняться быстрее, если вы добавите больше подчиненных устройств.
Наборы реплик также предлагают отказоустойчивость. Когда один из членов набора реплик выходит из строя, другие вступают во владение. Когда мастер выйдет из строя, рабы выберут нового мастера. По этой причине для продуктивного развертывания рекомендуется всегда использовать MongoDB в качестве набора реплик как минимум из трех серверов, два из которых содержат данные (третий - «арбитр» без данных, который необходим для определения нового мастера, когда один из рабов выходит из строя).
Sharded кластера означает , что каждый осколок кластера (который также может быть точной копией-набор) берет на себя часть данных. Каждый запрос, как чтение, так и запись, обслуживается кластером, в котором находятся данные. Это означает, что производительность чтения и записи может быть увеличена путем добавления большего количества сегментов в кластер. Какой документ находится на каком осколке, определяется ключом осколка каждой коллекции. Их следует выбирать таким образом, чтобы данные могли быть равномерно распределены по всем кластерам и чтобы было ясно, для большинства общих запросов, где находится ключ shard (пример: когда вы часто запрашиваете user_name, ваш ключ shard должен включать поле, user_nameпоэтому каждый запрос может быть делегирован только одному фрагменту, который имеет этот документ).
Недостатком является то, что страдает отказоустойчивость. Когда один осколок кластера разрушается, любые данные на нем недоступны. По этой причине каждый член кластера также должен быть набором реплик. Это не обязательно. Если вам не важна высокая доступность, осколок также может быть единственным экземпляром mongod без репликации . Но для производственного использования вы всегда должны использовать репликацию .
Так что это значит для вашего примера?
Sharded Cluster
/ | \
Shard A Shard B Shard C
/ \ / \ / \
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
|Primary| |Secondary| |Primary| |Secondary| |Primary| |Secondary|
| 25GB |=| 25GB | | 25 GB |=| 25 GB | | 25GB |=| 25GB |
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
Если вы хотите разделить данные размером 75 ГБ на 3 фрагмента по 25 ГБ каждый, вам нужно как минимум 6 серверов баз данных, организованных в три набора реплик. Каждый набор реплик состоит из двух серверов, которые имеют одинаковые 25 ГБ данных.
Вам также понадобятся серверы для арбитров трех наборов реплик, а также маршрутизатор mongos и сервер конфигурации для кластера. Арбитры очень легковесны и нужны только тогда, когда член набора репликации выходит из строя, поэтому они обычно могут использовать одно и то же оборудование с чем-то другим. Но маршрутизатор Mongos и config-сервер должны быть избыточными и находиться на своих собственных серверах.
Эти две вещи могут складываться, так как они разные. Использование обоих означает, что вы осколите свой набор данных в нескольких группах реплик. Другими словами, вы копируете осколки; набор данных без осколков - это один «осколок».
Монго кластер с тремя осколками и 3 репликами будет иметь 9 узлов.
источник
По сегментированию , вы разделяете свою коллекцию на несколько частей.
Репликация вашей базы данных означает, что вы делаете зеркала вашего набора данных.
источник
С точки зрения функциональности доставлено. Sharding обеспечивает масштабируемость и параллелизм. Репликация обеспечивает доступность
источник