При шардинге неизбежно возникает необходимость перебалансировать данные. Точно предсказать рост объема и формы данных практически невозможно. Поэтому ребалансировка данных — такая же систематическая операция, как и хранение данных. Ее нужно планировать на этапе проектирования, а не на этапе администрирования.

Пусть данные распределены между 5 серверами. Например, это таблица личных сообщений: 

messages: id | user_id | time | message | sender

Данные в этой таблице распределяются путем проверки user_id (остаток от деления на 5):

Остаток от деления user_id % 5 == 1 user_id % 5 == 2 user_id % 5 == 3 user_id % 5 == 4 user_id % 5 == 0
Номер сервера с данными 1 2 3 4 5

Т.е. для получения списка личных сообщений пользователя с id = 47, необходимо выполнить такие операции: 

<?

$user_id = 47;
$server = $user_id % 5 ? : 5;


# подключаемся к нужному серверу
$connection = connect($server);


# выполняем обычный запрос (в рамках подключения)
$messages = query($connection, "SELECT * FROM messages WHERE user_id = {$user_id}"); # без инъекций

# Выбор сервера БД под конкретного пользователя при шардинге

Подготовка к ребалансированию

Если текущие сервера заняты на 70...80% это признак того, что пора расширять их количество. Сколько ставить новых серверов? Прикинуть можно очень просто:

  • Количество занятого места на диске (на всех серверах) не должно быть более 50%, иначе готовность к взрывным нагрузкам очень низкая.
  • Скорость роста данных не должна приводить к повторной ребалансировке быстрее, чем вы успеете подготовить новое железо. От нескольких дней до недели обычно. Но тут ясно, что лучше обеспечить запас (например, месяц).

Допустим мы поставили еще 5 серверов и теперь их у нас 10. Если говорим о записи новых данных, то тут ничего делать не нужно — просто изменить логику шардинга (остаток от деления нужно теперь считать от 10). Но для правильного получения ранее сохраненных данных, необходимо выполнить ребелансировку данных со старых серверов на новые.

Например, в старой схеме с 5 серверами сообщения пользователя с id = 47 лежали на сервере: 

[5 серверов]: user_id = 47, server_id = 2

# остаток от деления 47 на 5 = 2

В новой схеме с 10 серверами, данные должны лежать тут: 

[10 серверов]: user_id = 47, server_id = 7

# остаток от деления 47 на 10 = 7

Проведение ребалансировки

Есть две стратегии. Синхронная и асинхронная.

Асинхронная ребалансировка

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

<?

foreach ( $users as $id )
{
	# вычисляем номера серверов в старой и новой схеме
	$old_server = $id % 5 ? : 5;
	$new_server = $id % 10 ? : 10;

	if ( $old_server != $new_server )
	{
		# получаем все сообщения со старого сервера
		$all_messages = get_messages($old_server, $id);

		# сохраняем все сообщения на новый сервер
		save_messages($new_server, $id, $all_messages);
	}
}

После перемещения всех данных, приложение начнет работать с новым набором серверов.

Ясно, что на время перемещения необходимо как-то знать, кто из пользователей уже обработан, а кто еще нет. Это можно сделать путем добавления флага в табличку пользователей и сброса его перед началом перебалансирования: 

users: id | email | ... | messages_rebalanced

Тогда, при перабалансировке необходимо будет обновлять этот флажок: 

<?

foreach ( $users as $id )
{
	# перемещаем данные со старого на новый сервер
	# ...
	
	# сохраняем статус пользователя
	save_user($id, ['messages_rebalanced' => 1]);
}

В приложении это позволит обеспечить нормальную работу прямо во время перемещения данных: 

<?

$user_id = 47;

if ( $user['messages_rebalanced'] )
{
	# данные уже перемещены, читаем с нового сервера
	$server = $user_id % 10 ? : 10;
}
else
{
	# данные еще не перемещены, читаем со старого сервера
	$server = $user_id % 5 ? : 5;
}

# по флажку мы узнаем, с какого сервера стоит читать данные для пользователя

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

Синхронная ребалансировка

Синхронная ребалансировка подразумевает, что мы ничего не делаем с данными, пока к ним не прийдет запрос. Например, данные пользователя c id = 47 будут лежать на 2м сервере, хотя серверов уже будет 10.

Итак, добавляем новые сервера и сразу же включаем их в работу.

Если приходит запрос на запись, мы записываем данные на нужный сервер в новой схеме.

Однако, как только приходит запрос на чтение, мы проверяем старую схему и перемещаем данные со старого сервера на новый:

Допустим мы хотим прочитать данные пользователя с user_id = 47, данные которого пока еще лежат на старом сервере (это мы тоже узнаем по флажку messages_rebalanced). Тогда перед получением данных, мы выполним их перемещение: 

<?

$user_id = 47;

if ( !$user['messages_rebalanced'] )
{
	# перемещаем сообщения перед их чтением
	$old_server = $user_id % 5 ? : 5;
	$messages = get_messages($server, $user_id);

	$new_server = $user_id % 10 ? : 10;
	save_messages($new_server, $user_id, $messages);

	save_user($user_id, ['messages_rebalanced' => 1]);
}


# читаем все сообщения с нового сервера
$server = $user_id % 10 ? : 10;
$messages = get_messages($server, $user_id);

# перед первым чтением в новой схеме, данные будут перемещены со старого на новый сервер

Этот метод очевидно удобнее и эффективнее, чем асинхронный. Будут перемещаться только актуальные данные, кроме этого весь процесс распределится во времени.

Однако, будьте внимательны! При перемещении больших объемов данных (например, если сообщения хранятся годами и могут заниматься сотни мегабайт), лучше использовать асинхронную ребалансировку. Иначе, приложение может крайне медленно работать для пользователя во время операций перемещения.

TL;DR

Ребалансировка — часть проектирования. Ее придется делать. Готовьтесь к тому, чтобы иметь удобный механизм ребалансировки до первой необходимости. Проще использовать синхронный метод. Однако, при больших объемах перемещаемых данных стоит выбрать асинхронный.

#шардинг ID: 336