🗄 Как не «положить» базу данных?

В большинстве веб-приложений (например, Instagram или Twitter) соотношение чтения к записи составляет примерно 10 к 1. То есть люди в 10 раз чаще смотрят чужие посты, чем пишут свои. Эту особенность как раз можно использовать.

🔹 Репликация (Master-Slave / Leader-Follower)

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

— Master (Лидер): Это единственная база данных, в которую разрешено ПИСАТЬ (INSERT, UPDATE, DELETE).
— Slave (Ведомые/Реплики): Это точные копии Мастера. Из них можно ТОЛЬКО ЧИТАТЬ (SELECT).

Как это работает:

1. Пользователь публикует фото. Запрос идет на Master-базу.
2. Master сохраняет фото и мгновенно отправляет новые данные всем своим Slave-копиям (реплицирует).
3. 1000 других пользователей открывают ленту. Их запросы на чтение распределяются между тремя Slave-базами.

Итог: нагрузка на чтение размазана, Мастер спокойно занимается только записью.

🔹 Шардирование (Sharding / Горизонтальное партиционирование)

Репликация спасает, когда много читают. Но что делать, если пользователи слишком много пишут (например, это система сбора логов или мессенджер)? Мастер перестает справляться.

Приходит время рубить данные на части - Шардировать.

Мы берем нашу огромную таблицу Users и разбиваем её на несколько независимых баз данных (шардов).

— Шард 1: хранит пользователей с ID от 1 до 1,000,000.
— Шард 2: хранит пользователей с ID от 1,000,001 до 2,000,000.

Каждый шард - это отдельный сервер со своим процессором и диском.

Сложность: теперь вашему приложению (или специальному роутеру) нужно понимать, в какую именно базу отправлять SQL-запрос. А сделать JOIN между таблицами, лежащими на разных серверах, становится практически невозможно.

🔹 Теорема CAP (закон распределенных систем)

Как только ваша база данных перестает жить на одном сервере и разъезжается на несколько (реплики или шарды), вступает в силу закон - теорема CAP.

Она гласит, что в распределенной системе вы можете выбрать только ДВА из ТРЕХ свойств:

1. C (Consistency / Консистентность): все клиенты видят одни и те же данные в один и тот же момент времени. Если я обновил аватарку на Мастере, следующий же запрос к любому Слейву должен вернуть новую аватарку.

2. A (Availability / Доступность): система всегда отвечает на запрос, даже если часть серверов сгорела.

3. P (Partition Tolerance / Устойчивость к разделению): система продолжает работать, даже если между серверами БД пропала сеть (они перестали видеть друг друга).

Суровая реальность: в интернете сеть пропадает всегда. Поэтому свойство P мы обязаны брать по умолчанию. Остается выбор между CP и AP.

🔵 Системы CP (Консистентные): банковские приложения. Если сеть между Мастером и Репликой упала, база откажется отдавать вам баланс, потому что боится отдать устаревшие данные. Лучше выдать ошибку, чем соврать.

🔵 Системы AP (Доступные): соцсети (Instagram, YouTube). Если вы поставили лайк, а сеть внутри дата-центра моргнула, ваш друг может еще пару минут не видеть этот лайк (данные не консистентны). Но сайт при этом не "лежит", лента листается.

══════ Навигация ══════
Вакансии • Задачи • Собесы

🐸 Библиотека джависта

#Enterprise