# Масштабирование БД

## Вертикальное масштабирование <a href="#rt-0" id="rt-0"></a>

Вертикальное масштабирование предполагает наращивание мощностей сервера. Основным преимуществом метода является его простота. Нет необходимости переписывать код при добавлении мощностей, а управлять одним крупным сервером намного проще, чем целой системой. Это же является и основным недостатком — масштабирование ресурсов одного сервера имеет вполне конкретные аппаратные ограничения. Также стоит учесть стоимость такого решения: сервер с кратным объёмом вычислительных ресурсов в большинстве случаев оказывается дороже, чем несколько менее мощных серверов, дающих в сумме такую производительность.

## Горизонтальное масштабирование <a href="#rt-1" id="rt-1"></a>

Горизонтальное масштабирование означает увеличение производительности за счёт разделения данных на множество серверов. Такой способ предполагает увеличение производительности без снижения отказоустойчивости. Существует три основных типа горизонтального масштабирования.

<table data-full-width="true"><thead><tr><th>Область сравнения</th><th>Репликация</th><th>Партицирование</th><th>Шардирование</th></tr></thead><tbody><tr><td>Основная функция</td><td>Повышение стабильности</td><td>Повышение управляемости</td><td>Ускорение обработки</td></tr><tr><td>Метод</td><td>Копирование между серверами</td><td>Разбиение по функциональности</td><td>Разбиение по объему</td></tr><tr><td>Распределение</td><td>По ведущим и ведомым серверам</td><td>Потоковое</td><td>Физическое</td></tr></tbody></table>

### Репликация <a href="#rt-2" id="rt-2"></a>

{% hint style="info" %}
**Репликация** — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие серверы часто называют мастерами (master), а ведомые серверы — слэйвами (slave).&#x20;
{% endhint %}

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

Главное преимущество репликации — большое количество копий данных. Так, если даже головной сервер выходит из строя, любой другой сможет его заменить. Однако как механизм масштабирования репликация не слишком удобна. Причина тому — рассинхронизация и задержки при передаче данных между серверами. Чаще всего репликация используется как средство для обеспечения отказоустойчивости вместе с другими методами масштабирования.

*Например, создание нескольких дополнительных slave‑серверов позволяет снять с основного сервера нагрузку и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет.*

### Партицирование (секционирование) <a href="#rt-3" id="rt-3"></a>

{% hint style="info" %}
**Партиционирование** — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям.&#x20;
{% endhint %}

Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. Для правильного конфигурирования параметров партиционирования необходимо, чтобы в каждом потоке было примерно одинаковое количество записей.

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

### Шардирование (шардинг/сегментирование) <a href="#rt-4" id="rt-4"></a>

{% hint style="info" %}
**Шардинг** — это прием, который позволяет распределять данные между разными физическими серверами.&#x20;
{% endhint %}

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

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

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

Источники:&#x20;

* <https://simpleone.ru/blog/masshtabirovanie-baz-dannyh/>
* <https://web-creator.ru/articles/partitioning_replication_sharding>
* <https://cloud.yandex.ru/ru/docs/glossary/sharding>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.system-analyst-base.ru/hard-skills/bazy-dannykh/masshtabirovanie-bd.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.