Построение структуры баз данных

Давайте вкратце рассмотрим основные схемы построения баз данных. Тут не будут рассматриваться принципы работы с кешированием данных - это уже относиться к оптимизации кода, а не к архитектуре БД.

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

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

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

Давайте еще раз повторим. Преимущества:

• Простота реализации
• Простота управления
• Простота обслуживания
• Низкое потребление ресурсов, есть только один полный набор данных

Недостатки:

• Низкая эффективность больших баз данных.
• Низкая безопасность (при отказе сервера БД, работать с системой будет не возможно)

Репликация - это некий механизм синхронизации не скольких объектов. В нашем случаи объектами являются базы данных.

Давайте рассмотрим три базы данных. Одну базу данных мы будем считать основной или мастер базой. На картинке мастер базой является БД0. Остальные базы будут репликами от основной. Будем предполагать, что логика и все БД разнесены по разным серверам (хотя все может быть реализовано и на одном физическом сервере).

Алгоритм работы простой и разбивается на две группы - запись и чтение.

Запись:

1. на сервер с логикой приходит запрос на запись в БД
2. запрос отправляется на БД0, где вноситься запись
3. репликация: сервер БД0 отправляет запросы к остальным база для синхронизации данных (может происходить после каждого обновления БД0, а можно сделать дискретно по расписанию)

Чтение:

1. на сервер с логикой приходит запрос на запись в БД
2. запрос отправляется на одну из реплик (можно добиться равномерного распределения по числу запросов или по нагрузке на сервера баз данных)
3. возвращение результата

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

Как правило издержки на чтения данных на порядок (или даже на несколько порядков) превосходят издержки на запись. Данная структура позволяет снизить именно эти издержки. При этом время выполнения отдельного запроса будет таким же как и при использовании простой структуры.

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

И снова кратко плюсы-минусы репликации БД. Достоинства:

• Высокая надежность системы
• Распределение нагрузки на сервера

Недостатки:

• Усложняется логика работы
• Избыточность хранения данных
• Не ускоряет выборку по отдельно взятому запросу

Шардирование - это некий принцип распределения баз данных (shard - осколок).

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

Для начала нам нужно понять по какому принципу мы сможем разделить однородные данные на группы. При этом каждая из групп должна содержать уникальные данные не повторяющиеся в других группах. И в сумме все группы должны содержать все данные.

Трудно написано, но легко понимаемо на примере. Пусть у нас есть некая огромная база со следующей структурой:

`country` - название страны
`region` - название региона
`city` - название населенного пункта
`street` - название улицы

И в этой базе хранятся все названия улиц мира с привязкой к населенным пунктам, регионам и странам. Для понимания масштаба, только для России это более миллиона записей (в соответствии с КЛАДР). Представьте теперь как долго будет осуществляться поиск по такой базе.

Теперь сгруппируем данные по какому-либо признаку. К примеру по странам. Так в группе «Россия» будут находиться все записи для которых верно `country` = 'Россия'. При этом в этой группе не будет записей относящихся, к примеру, к Китаю. Это и есть наш шард. А процесс группирования называется - шардирование.

В идеале каждый шард можно положить на свой сервер БД. Остается только научить логику определять к какому шарду должен будет пойти запрос и отправить его на соответствующий сервер.

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

В заключении, достоинства:

• Низкое потребление ресурсов, есть только один полный набор распределенных данных
• Быстрые запросы (существенно меньше количество записей по которым нужно делать выборку)
• Чуть более надежны, по сравнению с простой структурой (если какой-либо сервер откажет, то будет доступна по крайней мере часть данных)

Недостатки:

• Огромная проблема или даже невозможность делать выборки по нескольким шардам

Более подробно о шардировании на практике можно прочесть в статье Шардирование баз данных.