MongoDB Шардинг: Покроковий посібник із прикладом
Стівен Твен
⚡ Розумний підсумок
MongoDB Шардінг розділяє великі набори даних на менші підмножини, розподілені по кількох MongoDB екземплярів, зменшуючи навантаження на процесор будь-якого окремого сервера. Шардований кластер поєднує шарди, сервер конфігурації та маршрутизатор для горизонтального масштабування сховища та пропускної здатності запитів.
Що таке шардинг MongoDB?
Шардинг — це концепція в MongoDB, який розбиває великі набори даних на невеликі набори даних між кількома MongoDB екземпляри.
Іноді дані всередині MongoDB буде настільки величезним, що запити до таких великих наборів даних можуть призвести до значного використання процесора сервера. Щоб вирішити цю ситуацію, MongoDB має концепцію шардингу, яка в основному є розділенням наборів даних на кілька MongoDB екземпляри.
Колекція, яка може бути великою за розміром, насправді розділена на кілька колекцій, або, як їх ще називають, шардів. Логічно, всі шарди працюють як одна колекція.
Переваги шардингу в MongoDB
Перш ніж впроваджувати шардований кластер, корисно зрозуміти, чому команди впроваджують шардування. Основні переваги:
- Горизонтальна масштабованість: Дані розподіляються між багатьма звичайними серверами, замість того, щоб змушувати окрему машину зростати дедалі більше.
- Вища пропускна здатність: Операції читання та запису виконуються паралельно між шардами, тому кластер обробляє більше запитів за секунду.
- Більша місткість для зберігання: Об'єднаний диск усіх шардів може зберігати набори даних набагато більші, ніж може зберігати один сервер.
- Висока доступність: Коли кожен шард розгортається як набір реплік, збій одного вузла не призводить до виходу з ладу кластера.
- Збалансоване навантаження: Команда MongoDB балансувальник автоматично перерозподіляє фрагменти даних, щоб запобігти перетворенню будь-якого шарду на гарячу точку.
Разом ці переваги роблять шардінг стандартним підходом до масштабування. MongoDB за межами одного сервера.
Як реалізувати шардинг
Шарди реалізуються за допомогою кластерів, які є не чим іншим, як групою MongoDB екземпляри.
Компоненти шарду включають:
- Осколок – Це основне, а це не що інше, як a MongoDB екземпляр, який містить підмножину даних. У виробничих середовищах усі сегменти мають бути частиною наборів реплік.
- Конфігураційний сервер - Це MongoDB екземпляр, який містить метадані про кластер, по суті інформацію про різні MongoDB екземпляри, які зберігатимуть дані шардів.
- Маршрутизатор - Це MongoDB екземпляр, який по суті відповідає за перенаправлення команд, надісланих клієнтом, на потрібні сервери.
Крок за кроком шардинг Cluster Приклад
Крок 1) Створіть окрему базу даних для конфігураційного сервера.
mkdir /data/configdb
Крок 2) Почніть MongoDB екземпляр у режимі конфігурації. Припустимо, у нас є сервер з назвою Server D, який буде нашим сервером конфігурації. Нам потрібно виконати наведену нижче команду, щоб налаштувати сервер як сервер конфігурації.
mongod --configdb ServerD:27019
Крок 3) Запустіть екземпляр mongos, вказавши сервер конфігурації.
mongos --configdb ServerD:27019
Крок 4) З оболонки mongo підключіться до екземпляра mongos.
mongo --host ServerD --port 27017
Крок 5) Якщо у вас є Сервер A та Сервер B, які потрібно додати до кластера, виконайте наведені нижче команди.
sh.addShard("ServerA:27017") sh.addShard("ServerB:27017")
Крок 6) Увімкніть шардування для бази даних. Тож, якщо нам потрібно шардувати базу даних Employedb, виконайте команду нижче.
sh.enableSharding("Employeedb")
Крок 7) Увімкніть шардування для колекції. Тож, якщо нам потрібно шардувати колекцію Employee, виконайте команду нижче.
sh.shardCollection("Employeedb.Employee", { "Employeeid": 1, "EmployeeName": 1 })
Як вибрати Shard Key у MongoDB
Ключ шарду — це індексоване поле або набір полів, які MongoDB використовується для визначення, який шард зберігає кожен документ. Оскільки ключ визначає розподіл даних, його правильний вибір є найважливішим рішенням у шардованому розгортанні. Поганий ключ концентрує дані та трафік на одному шарді, зводячи нанівець переваги шардування.
Сильний шард-ключ зазвичай має такі характеристики:
- Висока кардинальність: Поле повинно мати багато можливих значень, щоб дані можна було розділити на багато дрібних фрагментів.
- Низька частота: Жодне окреме значення не повинно домінувати, інакше документи, що поділяють це значення, накопичуються в одному фрагменті.
- Немонотонна зміна: Ключі, які завжди збільшуються, такі як позначки часу, надсилають кожен новий запис до одного й того ж шарду, створюючи гарячу точку.
MongoDB Підтримує дві стратегії шардування на основі ключа. Діапазонне шардування розділяє дані на суміжні діапазони та підходить для діапазонних запитів, тоді як хешоване шардування застосовує хеш-функцію для рівномірного розподілу записів по шардах. Команди часто починають з хешованого шардування, коли записів багато, і переходять на діапазонне шардування, коли домінує читання на основі діапазону. Яку б стратегію ви не обрали, перевірте ключ на реальних шаблонах запитів перед фіксацією, оскільки ключ шарду не можна легко змінити після завантаження даних.
Шардінг проти реплікації в MongoDB
Шардінг та реплікація — це взаємодоповнюючі, але різні функції. У таблиці нижче виділено відмінності, щоб ви могли правильно застосовувати кожну з них, а на практиці виробничі кластери використовують обидві разом.
| Аспект | Sharding | Реплікація |
|---|---|---|
| Мета | Масштабування по горизонталі шляхом розділення даних | Захистіть дані та забезпечте їх доступність |
| Дані про кожен вузол | Підмножина (один шард) даних | Повна копія даних |
| Основна перевага | Більше пам'яті та пропускної здатності | Відмовостійкість та масштабування читання |
| Основні компоненти | Шарди, сервер конфігурації, маршрутизатор Mongos | Основні та другорядні члени |
Коротше кажучи, шардінг відповідає на потребу масштабування, тоді як реплікація відповідає на потребу доступності, а надійне розгортання поєднує обидва ці аспекти.
