День 2185. #ЗаметкиНаПолях
Масштабируем Монолиты. Продолжение
Начало
3. Масштабирование БД
Производительность БД - то, где большинство монолитов впервые сталкиваются с реальными ограничениями. Рассмотрим подробно стратегии масштабирования.
Реплики чтения
Часто это первый шаг в масштабировании БД. Создаются копии основной БД, которые обслуживают трафик только для чтения. Каждая реплика поддерживает актуальную копию данных посредством репликаций. Изменения передаются в одном направлении: от основной БД к репликам. Т.е. любые данные, записанные в основную БД, в итоге появятся в репликах. «В итоге», т.е. с задержкой. Так вы жертвуете согласованностью данных ради лучшей производительности чтения.
Большинство поставщиков облачных услуг поддерживают реплики чтения с минимальной настройкой, выполняя репликацию, мониторинг и следя за отказоустойчивостью за вас.
Важно:
- Задержка репликации влияет на актуальность данных;
- Объём записи влияет на скорость репликации;
- Географическое местоположение влияет на задержку;
- Каждая реплика увеличивает ваши расходы.
Материализированные представления
Это предварительно вычисленный набор данных, хранящийся в виде таблицы. В отличие от обычных представлений, которые вычисляют результаты для каждого запроса, материализованные представления сохраняют результаты. Это значительно ускоряет их выполнение, но создает новую проблему: поддержание их актуальности.
Сценарии использования:
- Сложные аналитические запросы;
- Данные, которые обновляются по расписанию;
- Агрегации и сводки;
- Денормализация данных для определённых представлений.
Ключевой компромисс — актуальность против производительности. Нужно решить, как часто обновлять материализованные представления. Слишком часто — нагрузка на БД, слишком редко — данные устаревают.
Шардирование БД
Разделяет данные между несколькими экземплярами БД, причём каждый содержит отдельное подмножество данных.
Шардирование по диапазону разделяет данные на основе диапазонов значений ключа. Например, клиенты А-М – в раздел 1, Н-Я — в раздел 2. Подход хорошо работает с данными, имеющими естественное распределение диапазонов: даты или алфавитный порядок, - но может привести к появлению точек перегрузки, если определённые диапазоны будут запрашиваться чаще, чем другие.
Шардирование по хэшу применяет хэш-функцию к ключу, чтобы определить, в какой раздел поместить данные. Выбор функции хэширования имеет решающее значение. Она должна равномерно распределять данные по разделам, чтобы ни один не стал узким местом. Этот подход обеспечивает лучшее распределение данных, но усложняет запросы на основе диапазонов, поскольку связанные данные могут находиться в разных разделах.
Шардирование по клиенту предоставляет каждому клиенту собственную БД. Подход обеспечивает естественную изоляцию и упрощает операции, специфичные для клиента. Хотя он усложняет запросы между клиентами, он часто является самым чистым решением для мультитенантных систем, где важна изоляция данных.
Окончание следует…
Источник: https://www.milanjovanovic.tech/blog/scaling-monoliths-a-practical-guide-for-growing-systems
Post #2638
2.57K
- 👍 17