Разница между Sharding и репликацией на MongoDB
Я просто путаю об осколках и репликации, как они работают..Согласно определению
репликация: набор реплик в MongoDB-это группа процессов mongod, которые поддерживают один и тот же набор данных.
Sharding: Sharding-это метод хранения данных на нескольких машинах.
согласно моему пониманию, если есть данные 75 ГБ, то репликацией (3 сервера), он будет хранить данные 75 ГБ на каждом сервере означает 75 ГБ на Сервер-1, 75GB на сервере-2 и 75GB на сервере-3..(поправьте меня, если я ошибаюсь)..а по шардингу он будет храниться как 25Гб данных на сервере-1, 25Гб данных на сервере-2 и 25Гб данных на сервере-3.(Не так ли?)...но затем я столкнулся с этой строкой в учебнике
осколки хранят данные. Обеспечение высокой доступности и данных согласованность в производственном сегментированном кластере каждый осколок является репликой set
Поскольку набор реплик имеет 75GB, но осколок имеет 25GB, то как они может быть эквивалентно...это приводит меня в замешательство...Мне кажется, я упускаю что-то важное. Пожалуйста, помоги мне в этом.
5 ответов
давайте попробуем с этой аналогией. Вы управляете библиотекой.
Как любой человек, у которого есть библиотека, у вас есть книги в библиотеке. Вы храните все книги, которые у вас есть на полке. Это хорошо, но ваша библиотека стала настолько хорошей, что ваш соперник хочет ее сжечь. Поэтому вы решили сделать много дополнительных полок в других местах. Существует одна самая важная полка, и всякий раз, когда вы добавляете новые книги, вы быстро добавляете те же книги на другие полки. Теперь, если соперник уничтожает полка - это не проблема, вы просто открываете другую и копируете ее вместе с книгами.
Это репликация (просто замените библиотеку приложением, полку с сервером, книгу с документом в коллекции, и ваш соперник просто не смог HDD на сервере). Он просто делает дополнительные копии данных, и если что-то идет не так, он автоматически выбирает другой первичный.
эта концепция может помочь, если вы
- хотите масштабировать чтения (но они могут отставать от основного).
- сделайте некоторые автономные чтения, которые не касаются главного сервера
- обслуживать некоторую часть данных для определенного региона с сервера из этого конкретного региона
- но основной причиной репликации является наличие данных. Итак, здесь вы правы: если у вас есть 75Gb данных и реплицировать его с 2 secondaries - вы получите 75*3 Gb данных.
посмотреть по другому сценарию. Там нет соперника, так что вы не хотите, чтобы сделать копию ваших полок. Но сейчас у тебя другая проблема. Вы стали настолько хороши, что одной полки недостаточно. Вы решаете распределить свои книги между многими полками. Вы решаете распределить их между полками на основе имени автора (это не очень хорошая идея и читать как выберите sharding key здесь). Поэтому все, что начинается с имени меньше, чем K, идет на одну полку, все, что есть K и больше, идет на другой. Это sharding.
эта концепция может помочь вам:
- распределить нагрузку
- иметь возможность сохранять данные, которые гораздо больше, чем может поместиться на одном сервере
- сделать карту-уменьшить вещи
- храните больше данных в ОЗУ для более быстрых запросов
здесь вы частично правы. Если у вас есть 75Gb, то в сумме на всех серверах будет еще 75 Gb, но это не так обязательно разделить поровну.
но вот проблема только с sharding. Прямо сейчас ваш соперник появился, и он просто подошел к одной из ваших полок и сжег ее. Все данные на этой полке потеряны. Таким образом, вы хотите воспроизвести каждый осколок. В основном понятие, что
каждый осколок представляет собой набор реплик
- Это неправда. Но если вы делаете sharding, вам нужно создать репликацию для каждого shard. Потому что чем больше осколки у вас есть, тем больше вероятность того, что по крайней мере один умрет.
ответ на следующий ответ Саада:
также вы можете иметь осколки и реплики вместе на одном сервере,это не рекомендуется делать. Каждый сервер должен иметь одну роль в системе. Если, например, вы решите иметь 2 осколка и повторить его 3 раза, вы получите 6 машин.
Я знаю, что это может показаться слишком дорогостоящим, но вы должны помнить, что это товарное оборудование, и если услуга, которую вы предоставляете, уже так хороша, то, что вы думаете о высокой доступности и не подходит для одной машины, то это довольно дешевая цена (по сравнению с выделенной одной большой машиной).
Я пишу это как ответ, но на самом деле это вопрос к ответу @Salvador Sir.
Как вы сказали, в sharding 75 GB данные "могут быть" сохранены как 25GB данные на сервере-1, 25GB на сервере-2 и 25Gb на сервере-3. (это распределение зависит от ключа сегментирования)...затем, чтобы предотвратить его потерю, нам также нужно воспроизвести осколок. таким образом, это означает, что теперь каждый сервер содержит его осколки, а также репликацию других осколков, присутствующих на другом сервере..значит, сервер-1 будет есть
1) свой собственный осколок.
2) репликация осколка присутствует на сервере-2
3) репликация осколка присутствует на сервере-3
то же самое происходит с сервером-2 и сервером-3. Я прав?..если это так, то каждый сервер снова имеет 75GB данных снова. Правильно это или нет?
Так как мы хотим сделать 3 осколка, а также реплицировать данные, так что следующее решение вышеуказанной проблемы.
r имеет осколок, а также набор реплик, тогда в этом случае сбой этого сервера приведет к потере набора реплик и осколка.
однако вы можете иметь набор осколков 1 и реплик (реплика осколка 2 и осколка 3) на одном сервере, но это не рекомендуется..
Sharding - это как раздел данных. Допустим, у вас есть около 3 ГБ данных, и вы определили 3 осколка, поэтому каждый осколок может занять 1 ГБ данных(и это действительно зависит от ключа осколка) Зачем нужен sharding? Поиск определенных данных из 3GB в 3 раза сложнее, чем поиск в 1GB данных. Так что это почти похоже на раздел. И сегментирования помогает для быстрого доступа к данным.
теперь, перейдя к реплике, скажем, у вас есть те же 3GB данных без какой-либо репликации(это означает только существует одна копия данных), поэтому, если что-то случится с этой машиной или диском, ваши данные исчезнут. Таким образом, репликация входит в картину, чтобы решить эту проблему, скажем, когда вы настраиваете БД, вы дали свою репликацию как 3, Что означает, что те же 3 ГБ данных доступны 3 раза(поэтому общий размер может быть 9 ГБ, разделенный на каждую из копий 3 ГБ). Репликация помогает при сбое.