Техника ручного шардирования данных. Spot’s

Всем привет. Сегодня я хочу рассказать о данных, точнее об одном из вариантов работы с ними. И так, приступим..

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

Начнем с того что вы решили создать (улучшить) сайт (сервис). Возможно у вас уже есть некоторая схема таблиц для базы данных, возможно даже частично наполненная. И вроде бы всё отлично смотрится, но в душе скребут кошки (закралось сомнение). Обычно эти сомнения начинают проявлять себя в тот момент, когда данных уже много (битком) и движок базы начинает тупить (проседать). И мы (вы) начинаете изучать информацию в интернете по оптимизации работы базы данных. Обычно в этот момент вы наталкиваетесь на такой термин как —  Масштабирование баз данных. Узнаете об основных вариантах масштабирования:

• Пар­ти­ци­о­ни­ро­ва­ние — дробление больших таблиц на более мелкие, по какому либо признаку.
• Репликация — дублирование всех данных таблиц на резервные сервера, для разделения операций чтения/записи и возможной горячей замены пишущего.
• Шардинг — смесь первых двух вариантов. Размазывание больших таблиц на дополнительные сервера.

Все три способа имеют свои минусы ( плюсы ) и могут (не) помочь вам в сложившейся ситуации. Например:

• на новост­ных сай­тах имеет смысл пар­ти­ци­о­ни­ро­вать записи по дате пуб­ли­ка­ции, так как свежие новости более востребованы и чаще требуется работа именно они, а не весь архив за всё время
• возможно на какую-либо таблицу у вас повышенное количество запросов чтения , либо время их выполнения слишком большое, логично было бы реплицировать их на слейв и делать чтение там, чтоб лишний раз не нагружать мастера (основную базу)
• в системах типа социальных сетей ключом для шардинга может быть ID пользователя, таким образом все данные пользователя будут храниться и обрабатываться на одном сервере, а не собираться по частям с нескольких

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

Техника Spot’s

Итак, у нас есть набор таблиц связанный чем-то общим в одной из таблиц. Например пользователи ( user ) , их статусы ( tweet ), подписки на статусы ( subscribe ) и «нравится» к статусам ( like ). Немного подумав мы видим user_id во всех указанных таблицах, берем и партиционируем пользователей, например блоками по 1000 , причем делаем это не только user.id , но и все остальные таблицы по *.user_id.

Исходная база user tweet subscribe like

Шардируем пользователей по user.id user_shard_1 user_shard_2 user_shard_N

Шардируем остальные таблицы по user.id user_shard_1 user_shard_2 user_shard_N user user user tweet tweet tweet subscribe subscribe subscribe like like like

Получаем набор баз  — Spot’s: user_shard_N user tweet subscribe like

^{* user_shard_N — фиктивное поле , в реальности его делать не нужно}

То есть spot — это партиционированный вместе со своими связями набор данных. Это небольшая база данных с определённым количеством записей в определённой таблице. Следующим шагом для вас станет необходимость завести карту spot’s с помощью которой вы сможете ориентироваться где какие данные у вас находятся и выполнять с ними необходимые операции, например перемещения с одного сервера на другой.  Для примера:

shard_name	spot_id	server_id	from_idx	to_idx
user	1	1	1	1000
user	2	1	1001	2000
user	3	2	2001	3000

Легенда к таблице:

• shard_name — название таблицы данных по которым выполнялось партиционирование
• spot_id — номер шарда партиционированных данных
• server_id — номер сервера где размещены данные
• form_idx — номер начала среза данных
• to_idx — номер окончания среза данных

Статистика spot:

Определение нагрузки спота, можно определить по формуле: MAU*K+Shard/100 — где:
 — MAU — кол-во активных записей шарда (user)
— K — коэффициент сервера от 0 (хороший) к 1 (плохой)
 — Shard — количество строк шарда в Spot
До релиза задачи схема должна быть изменена, следовательно изменения не должны ломать существующий код.
Внедрение новых схем на Spot’s через DBA (DataBaseArchitect).

Profit.

Данные больше не зависят от места хранения. Данными можно манипулировать в том числе добавлять, перемещать, объединять, разбивать и т.д. и т.п.

• Badoo — 360к спотов, 80 таблиц в каждом, 190Тб