System Design: Как не "положить" Базу Данных?

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

Эту особенность мы и будем использовать.

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

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

Master (Лидер): Это единственная база данных, в которую разрешено ПИСАТЬ (INSERT, UPDATE, DELETE).

Slave (Ведомые/Реплики): Это точные копии Мастера. Из них можно ТОЛЬКО ЧИТАТЬ (SELECT).

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

1. Пользователь публикует фото. Запрос идет на Master-базу.

2. Master сохраняет фото и мгновенно отправляет новые данные всем своим Slave-копиям (реплицирует).

3. 1000 других пользователей открывают ленту. Их запросы на чтение распределяются между тремя Slave-базами.

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

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

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

Или что делать, если данных стало 10 Терабайт, и они тупо не влезают на один диск?

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

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

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

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

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

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

3. Теорема CAP (Закон распределенных систем)

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

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

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

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

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

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

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

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

Итог

Используйте Репликацию, чтобы масштабировать чтение (Read-heavy).

Используйте Шардирование, чтобы масштабировать запись и объем данных (Write-heavy).

Помните про CAP-теорему: для соцсетей выбираем Доступность (AP), для финансов - Консистентность (CP).

Источник: vk.com

Комментарии: