MongoDB подойдет, если необходимо:
-
Управлять большим объемом данных с заранее неизвестной структурой (каталоги товаров, пользовательские профили, системы управления контентом).
Пример: интернет-магазин, где продается множество товаров с разными характеристиками. Чтобы выставить товар на сайт, контент-менеджер выбирает характеристики и их значения из набора. Менеджер также может добавить или удалить любое поле и установленные для него значения.
-
Горизонтально масштабироваться.
Пример: создание национальной БД медицинских карт. Реляционная БД здесь — не лучшее решение: ее горизонтальное масштабирование сопряжено с трудностями и плохо автоматизируется.
Шардирование
Шардирование — это горизонтальное масштабирование данных, при котором данные разбиваются на шарды (т. е. части) и размещаются на разных хостах кластера. Нагрузка на БД при этом распределяется по хостам, что позволяет добиться большей производительности системы, чем если бы она была расположена на одном мощном сервере. Это особенно важно, если данных или запросов к ним очень много.
Плюсы шардирования в том, что оно позволяет:
-
Обойти технические ограничения. Если БД работает на пределе производительности — можно разбить её на части и распределить запросы на чтение между ними.
-
**Ускорить доступ к данным для пользователей из конкретного региона.**Например, международные соцсети могут хранить контент на русском языке на серверах ближе к России.
-
Выполнить юридические требования. Например, хранить конфиденциальные данные на шарде, публичный доступ к которому отключен.
-
Повысить доступность. Если БД находится на одном нешардированном хосте, то его выход из строя приведет к потере всех данных. Если же БД шардирована, то при отказе одного шарда все данные на других остаются доступными.
Для шардов можно дополнительно настроить репликацию. Так вы обойдетесь без потерь, если сервер выйдет из строя. А размещение реплик шарда в разных зонах доступности даст вам отказоустойчивую систему.
-
Ускорить запросы. Они могут выполняться медленнее из-за того, что конкурируют за ресурсы сервера. Шардирование устраняет конкуренцию, исполняя запросы параллельно на разных серверах.
Каким бы замечательным ни было шардирование, у него есть и недостатки:
- Правильно шардировать данные, т. е. разбить их на части — непростая задача. Если вы сделаете это неверно, то мощности серверов будут использоваться нерационально. Например, потребуется много межсерверных запросов.
- Из-за несбалансированного распределения данных между шардами появляются горячие точки — разделы БД, к которым идет намного больше обращений по сравнению с остальными. Запросы к горячим точкам обрабатываются заметно медленнее.
Шардирование в MongoDB
В MongoDB шардирование коллекций поддерживается по умолчанию — части коллекций MongoDB размещаются на разных хостах кластера. На какой шард попадет фрагмент данных, определяет ключ шардирования.
От выбора ключа зависит удобство работы с коллекцией и производительность. Следует логично распределить данные коллекции по шардам. Данные на шардах не должны быть связаны между собой.
Шардировать данные имеет смысл, если:
- Данных много (коллекция больше 200 ГБ).
- Данные неоднородны и четко делятся на примерно одинаковые по объему данных категории.
- Требования к скорости чтения и записи данных высоки. Шардирование распределит нагрузку по хостам, чтобы обойти технические ограничения.
📂 YandexCloud | Последнее изменение: 15.08.2024 11:50