Шардування MongoDB: де кластер впирається в межу навантаження
Поки дані й робочий набір індексів містяться в пам'яті, одна репліка відповідає передбачувано, і запас за навантаженням здається необмеженим.
Межа одного вузла настає не різко: спочатку зростає обсяг колекцій, робочий набір перестає міститися повністю, і частина читань переходить на диск. Час відповіді при цьому зростає нелінійно — подвоєння обсягу дає помітно більше, ніж подвоєння затримки.
Далі починається деградація запису. Журнал реплікації відстає від первинного вузла, вторинні вузли перестають встигати підтверджувати операції, а застосунок отримує зростаючу частку таймаутів.
Повтори запитів замикають зворотний зв'язок: чим більше повторів, тим глибше вузьке місце бази даних.
Пікові години виявляють проблему найвиразніше: пакетне завантаження, звіти й потік користувацьких подій сходяться в одну точку.
Відмова виглядає як деградація, а не як падіння — формально сервіс живий, але час відповіді на читання й запис розходиться в рази, і користуватися ним не можна.
Вертикальне масштабування теж впирається в межу: нарощувати ресурси одного вузла можна лише до певного класу машин, а віддача від кожної наступної сходинки падає.
Шардування MongoDB розносить дані за ключем і знімає прив'язку до одного сервера — але працює тільки тоді, коли ключ вибрано за реальними шаблонами запитів, а не за зручністю схеми.
Нижче розбираємо, як це закривається: як вибрати ключ шардування, у який момент шардувати раніше за реплікацію й за якими метриками видно, що кластер справді розподілив навантаження.
Що дає розподіл даних: пропускна здатність і запас зростання
Шардування ділить колекцію на чанки за шард-ключем і розкладає їх по вузлах; балансувальник переносить чанки, коли розподіл перекошується.
Запити йдуть тільки на потрібні вузли, тому пропускна здатність бази зростає разом із кількістю вузлів, а не впирається в межу одного сервера.
Ключ тут важливіший за обладнання: монотонний ключ на кшталт часу створення запису знову зводить увесь потік в один вузол, і кластер працює як один вузол.
Запас зростання з'являється там, де передбачувано зростають обсяг і частота звернень. Поки дані містяться на одному сервері, вертикальне масштабування простіше, але в нього є межа — і перехід на розподілену схему на піку коштує дорожче, ніж проєктування заздалегідь.
Відкриті вимірювання розподілених кластерів MongoDB показують: за рівномірного ключа пропускна здатність зростає майже лінійно з кількістю вузлів.
Час відновлення скорочується завдяки реплікам усередині кожного вузла: у разі відмови основного роль бере на себе репліка, і кластер не чекає відновлення з резервної копії. Скільки сервіс живе без частини вузлів, визначає саме реплікація, а не саме шардування.
Стійкість до пікового навантаження дає той самий запас: вузли додаються без зупинки сервісу, а перерозподіл чанків іде фоном.
На етапі проєктування перевіряємо розподіл ключа на реальних даних, поведінку балансувальника під навантаженням і сценарій відмови вузла. Ці три речі й вирішують, чи буде зростання пропускної здатності лінійним — чи кластер впирається в перший же перекошений чанк.
Варіанти масштабування: один вузол, реплікація, розподіл даних
Один вузол, реплікація й розподіл даних — не конкуруючі варіанти, а щаблі. Поки робочий набір укладається в ресурси однієї машини, вертикальне масштабування дешевше: додаємо пам'ять, ядра, швидкі накопичувачі — схема й застосунок не змінюються.
Межа настає, коли робочий набір перестає міститися в пам'ять, а запис впирається в межу одного вузла.
Реплікація закриває інший клас задач — відмовостійкість і паралельне читання. Копії приймають запити на читання, але запис іде через один провідний вузол, і його межа залишається незмінною: черга на запис зростає, підтвердження сповільнюються.
Шардування в MongoDB — перехід до горизонтального масштабування — знімає саме це обмеження, ціною ускладнення супроводу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один вузол | Робочий набір у пам'яті вузла, помірний запис, старт проєкту | Немає відмовостійкості, межа за пам'яттю й диском, простій під час збою |
| Реплікація | Потрібні доступність і паралельні читання, запис помірний | Запис лише через провідний вузол, затримка копій під навантаженням |
| Шардування | Дані більші за пам'ять вузла, постійне зростання й високий запис | Складніший супровід, ключ визначає рівномірність, частина запитів іде по всіх шардах |
Де проходять межі застосовності
Реплікація не замінює розподіл даних: вона не розносить дані по машинах, тому межа запису й обсягу залишається. Вертикальне масштабування впирається в доступні конфігурації вузлів і залишає єдину точку відмови.
Шардування виправдане за постійного зростання й ключа, що дає рівномірний розподіл: гарячий шард зводить виграш до нуля.
Впровадження шардування MongoDB: від аудиту до передачі
Шардування рідко ламається на етапі ввімкнення — проблеми спливають пізніше, коли перекошений ключ спрямовує навантаження на один шард, а виправляти це доводиться міграцією даних на живому кластері.
Тому впровадження шардування MongoDB ми ведемо фіксованим порядком робіт: спочатку вимірювання, потім схема розподілу, потім налаштування і лише згодом навантаження. Кожен етап закривається артефактом, який замовник може перевірити.
Підготовка та проєктування
- Збір метрик і профілю навантаження — знімаємо статистику запитів, знаходимо колекції, що найшвидше зростають, дивимося розподіл полів у фільтрах і сортуваннях, впираємося в диск і пам'ять. Без цих даних вибір ключа перетворюється на вгадування.
- Проєктування схеми розподілу — визначаємо ключ (хешований або складений із високою кардинальністю), кількість шардів, розміщення реплік, тегування під георозподіл. Окремо фіксуємо, які колекції залишаються нешардованими і чому.
- Налаштування компонентів — розгортаємо маршрутизатори й конфігураційні сервери з реплікацією, приводимо набори реплік шардів до єдиної конфігурації, вмикаємо балансувальник, створюємо індекси, що підтримують ключ.
Навантажувальна перевірка та передача в експлуатацію
- Навантажувальна перевірка — відтворюємо профіль бойового трафіку на стенді: рівномірність чанків, затримки маршрутизації, поведінку кластера при відмові шарда або вузла конфігурації.
- Перенесення даних і ввімкнення — шардуємо колекції з контролем потоків чанків, стежачи, щоб міграція не забирала ресурси в робочого навантаження.
- Передача в експлуатацію — регламенти обслуговування, панелі моніторингу й алерти за балансом чанків, інструкції з відкату, план розширення кластера.
Що залишається у вас після впровадження: конфігурації, схеми, регламенти
Кластер здано не тоді, коли запити йдуть через роутери, а коли ваша команда може обслуговувати його без нас.
Тому разом із працюючою системою передаємо комплект артефактів, за яким конфігурацію можна відтворити, планові роботи провести, а інцидент розібрати без листування з розробником.
- Конфігурації компонентів кластера — роутерів, шард-серверів і конфігураційних серверів, з коментарями, чому параметр виставлено саме так.
- Схема кластера: топологія, ключі шардування за колекціями, зони розміщення й обґрунтування вибору під ваш профіль запитів.
- Політики доступу: ролі застосунків і адміністраторів, розподіл прав, порядок ротації облікових даних.
- Регламент обслуговування: планові перевірки балансування, контроль розміру чанків, вікна робіт і порядок відкату.
- Документація по кластеру: карта колекцій, історія змін конфігурації, сценарії аварійного відновлення.
- Налаштований збір метрик і оповіщень із порогами, за яких черговий розуміє, що час втручатися.
Навчання команди
Розбираємо з вашими інженерами реальні сценарії на цьому кластері: чому «гарячий» шард частіше є наслідком вибору ключа, а не нестачі ресурсів, як читати поведінку балансувальника, що робити при втраті вузла. Після розбору команда діагностує проблеми й змінює конфігурацію самостійно, не чекаючи на нас.
Передача доступів
Адміністративні облікові записи заводимо на ваші акаунти, наші тимчасові доступи відкликаємо під час здачі. Окремим документом фіксуємо аварійні доступи, порядок їх видачі й точки, де дії логуються.
Кейс: як зросла пропускна здатність після розподілу даних
Проєкт — сервіс із потоковим записом подій від клієнтських застосунків.
Усе працювало на одному вузлі MongoDB з репліками: колекція перевалила за сотні мільйонів документів, запис впирався в межу дискових операцій, а на ранкових і вечірніх піках з'являлася черга й затримки зростали в рази.
Оновлення обладнання давало запас на лічені місяці — дані зростали швидше, ніж можливості одного сервера.
Ми розібрали профіль запитів і розділили дані: складений ключ шардування за ідентифікатором орендаря й часом запису, щоб навантаження лягало на сегменти рівномірно, а вибірки за одним орендарем не розліталися по всьому кластеру.
Колекції розбили на діапазони заздалегідь, щоб балансувальник не займався перетасовуванням уже на бойовому трафіку, а роутери запитів винесли окремим шаром.
Пропускна здатність кластера зросла майже вчетверо за того самого обсягу даних, пік перестав іти в чергу, а частка повільних запитів повернулася до значень позапікового часу.
Додавання сегмента тепер займає години й не потребує зупинки запису: зростання трафіку закривається обладнанням, а не переписуванням логіки доступу до даних.
Головне — зник клас відмов, за якого деградація одного вузла означала відмову запису для всіх. Сегменти ізольовані, репліки всередині кожного тримають читання при втраті вузла, а перевантаження одного діапазону б'є тільки по своїй частці орендарів. Планове обслуговування йде по одному сегменту, без повного простою сервісу.
Чим відрізняється реплікація від розподілу даних і що вибрати?
У MongoDB репліка — це повна копія даних на кількох вузлах: вона закриває відмовостійкість і розподіляє читання, але кожен вузол зберігає весь обсяг і застосовує всі записи.
Запис при цьому йде через один провідний вузол, тому копії не піднімають межу запису й не зменшують розмір робочого набору.
Реплікації достатньо, поки дані містяться в пам'ять вузлів, відставання копій тримається в межах часток секунди, а черга запису не зростає.
Коли робочий набір починає витіснятися на диск, відставання копій стає постійним, а час відповіді перестає вкладатися у вимоги — додавання нових копій тут не рятує, бо кожна з них повторює ту саму роботу над тим самим обсягом.
Шардування ділить колекцію за ключем між вузлами: кожен зберігає свою частину, роутер спрямовує запит у потрібну частину, балансувальник переносить фрагменти при перекосі.
Тут масштабуються і обсяг, і потік запису, але з'являється нова ціна — ключ розподілу визначає, будуть запити точковими, чи розійдуться по всіх вузлах кластера, і помилка в ньому коштує дорожче, ніж нестача ресурсів.
Практичний порядок такий: спочатку репліка, бо вона про доступність і читання, а розподіл додають, коли впирається обсяг або темп запису.
Найчастіша помилка — розподіляти кластер, який не тримав навантаження через неіндексовані запити: після розбиття вони стають тільки повільнішими, а супровід — складнішим.
На етапі вибору архітектури ми рахуємо профіль навантаження: частку запитів за потенційним ключем, обсяг і темп зростання, вимоги до часу відповіді й допустиме відставання копій.
За цими цифрами видно, де закінчується користь копій і чи потрібен перехід на розподіл — і якщо потрібен, який ключ не приведе до перекосу.
Часті технічні сумніви: чанки, ключі та відмовостійкість
Сумніви на цьому етапі зазвичай одні й ті самі: чи не з'являться перекоси при зростанні даних, чи можна перейти на шардування без вікна простою і що станеться з резервними копіями. Нижче — короткі відповіді; деталі під конкретну схему даних розбираємо під час проєктування ключа.
Де з'являються гарячі чанки і як їх прибрати?
Перекіс виникає, коли ключ зав'язаний на монотонно зростаючому полі: нові записи лягають в один шард, і балансувальник не встигає їх розносити. Допомагає складений ключ із хешованою частиною — запис розподіляється заздалегідь, а діапазонні вибірки залишаються за другою частиною.
Як вибрати ключ шарда?
Ключ добирається під шаблон запитів, а не під структуру документа: якщо умова вибірки не містить поля ключа, запит іде на всі шарди. Дивимося кардинальність, рівномірність і зростання ключа — на обсязі, що повторює робочий профіль навантаження.
Чи можна мігрувати без зупинки сервісу?
Так. Піднімаємо кластер поруч, вмикаємо запис в обидва контури, переносимо дані пакетами й перемикаємо застосунок після звірки. Простій — секунди на перемикання маршрутизації, відкат — повернення на попередній контур.
Що змінюється в резервному копіюванні та в застосунку?
Знімок робимо узгоджено по всіх шардах зі спільною точкою відновлення, інакше частини копій не зійдуться за часом; відновлення перевіряємо на стенді, а не за фактом успішного зняття. У застосунку потрібне поле ключа в запитах і коректні повторні спроби під час переїзду чанка.
Обговоримо вашу схему: знімемо метрики й повернемося з планом
Щоб оцінка й план спиралися на вашу схему, а не на середні цифри, починаємо з розбору поточної схеми: скільки шардів, за яким ключем розподіляються дані, де вузьке місце — у записі, читанні або в маршрутизації запитів.
Надішліть конфігурацію кластера, статистику за колекціями і опис пікових навантажень — метрики знімемо самі, а висновки покажемо в цифрах.
Що надсилаєте ви:
- топологію кластера: кількість шардів, реплік і вузлів-маршрутизаторів;
- ключі шардування й колекції, які зростають швидше за інші;
- профіль навантаження: пікові години, частка читань і записів, найважчі запити;
- обмеження: вікно недоступності, вимоги до відкату, регламенти щодо доступів;
- цільовий обсяг даних і кількість одночасних підключень, до яких готуємося.
Що робимо ми: звіряємо топологію з профілем навантаження, перевіряємо вибраний ключ на перекоси між шардами, рахуємо план переходу за етапами й точки відкату.
Повертаємося з оцінкою та планом робіт: послідовність кроків, порядок міграції, критерії готовності на кожному етапі та зона відповідальності. Опишіть задачу у вільній формі — обговоримо й повернемося з оцінкою та планом.
