С ростом сайта или веб-приложения хранение и работа с информацией в базе данных затрудняется.

Ранее я описывал подходы масштабирования фронтэнда и масштабирования бэкенда и теперь настал черед немного поговорить о наиболее важной части - масштабировании базы данных.

Масштабирование базы данных

Прежде всего нужно понять, какие данные требуют масштабирования базы данных, почему они требуют. Единого решения и ответа здесь нет, а все зависит от конкретного проекта.  Все зависит от множества нюансов, например, от того, как и где храняться данные. А ведь хранить разные данные можно по разному.

Давайте кратко вспомним какие основные модели хранения данных обычно используют.

  • Реляционные базы данных - все данные хранятся в виде набора отношений, связанных между собой данных.
  • Иерархические базы данных - данные хранятся в объектах в виде отношений между этими объектами.
  • Сетевые базы данных - данные хранятся в структуре в виде графа.
  • Объектно-ориентированные базы данных - данные храняться в виде моделей объектов.

Выбор и использование модели базы данных зависит от самих данных и все вопросы, которые касаются работы с данными, должны решаться на стадии выбора способа хранения данных.

С ростом количества пользователей, растет и количество данных, а соответственно и количество запросов и действий для работы с этими данными.

При масштабировании базы данных следует учитывать особенности сервера базы данных, какие настройки это сервера используются, правильно ли сервер вообще настроен. Нужно анализировать, какие запросы в приложении используются и какие затрудняют работу с данными, улучшить такие запросы, проверить структура базы в целом: таблицы, индексы полей этих таблиц.

Шардинг базы данных

И конечно же, здесь применимо масштабирование в горизонтальном направлении, разделение данных на несколько баз данных на разных серверах. Но при масштабировании базы данных это не просто горизонтальное масштабирование, а шардинг. Шардинг - это когда вы разделяете данные по базам данных на отдельных серверах, при этом разбиение данных должно производиться с учетом их максимальной связности в одном шарде и минимальной связанности в остальных шардах.

Репликация

Любой сервер, на котором расположена база данных, может выйти из строя и перестать работать. Чтобы не потерять данные используется репликация.

Репликация - это осуществление связи между серверами баз данных, перенос данных между этими серверами в тот момент, когда данные добавляются. При выходе из строя одного сервера базы данных, к работе подключается другой сервер, с точно такими же данными и все продолжает работать. Когда нерабочий сервер восстанавливается в работе, он вновь подключается для репликации и на него копируются данные добавленные в момент выхода из строя.Более подробней о репликации можно почитать в моем посте о репликации данных в MongoDB.

Партиционирование

Еще один метод масштабирования базы данных - партиционирование. Партиционирование - это функциональное разделение базы данных на некие отдельные места хранения: в разных таблицах, в разных типах баз данных (одни данные в MySQL, другие в MongoDB), в разных моделях хранения данных.

Денормализация

В некоторых случаях, разработчики прибегают к использованию денормализации для обеспечения быстрого доступа к данным. Денормализация - это когда данных дублируются при сохранении. Например, при создании поста для сайта, производится добавление тегов к этому посту. Вместо того, чтобы сохранять теги в отдельную таблицу, проверяя каждый  раз тег на существование, чтобы не плодить дубли текста, а связь с постами и тегами во вторую таблицу, при денормализации все добавляет в одну таблицу, дублируя каждый раз текст. В некоторых случаях, денормализация данных приемлема, в остальных от нее лучше отказаться.