Мне даже не столько наличие готовых инструментов интересует, сколько сама алгоритмистика как сделать шард по таким условиям. Написать/переписать алгоритм под наши нужды - не самое страшное
Да не, алгоритм-то я напилю на чем-нибудь более серьезном, чем хранимые процедуры.
Ладно, может будет легче после более предметного описания:
У меня есть тяжелый плательщик, который хочется разделить на несколько подплательщиков, каждый из которых будет жить в отдельной базе и все транзакции проводить внутри базы. Казалось бы, ничего сложного - берем любой алгоритм шардинга, хоть деление по модулю, хоть кетаму и выбираем i-го плательщика. Но есть "но" - в деталях платежа передается ключ, уникальность которого надо контролировать на всех базах, где живут подплательщики. Причем контролировать в момент проведения платежа, внутри транзакции. Проблем нет, если строго зашить число узлов и потом не менять. Но если хочется добавлять узлы или отключать - хрена с два это выйдет, уникальность может поехать. Ну и весовая балансировка в таком случае тоже не вижу, как может работать...
Да, значения ключей я как-то могу менять, если того потребует алгоритм. Лишь бы они и после этого были уникальными.
Ну допустим было у нас 2 узла А и Б. В момент времени T1 платеж с идентификатором 1 мы решили отправить в узел А Получил он айдишник A1 В момент времени T2 у нас уже 3 узла и пришел еще один платеж с этим ID=1. В схеме с одним плательщиком мы этот платеж завернули. В схеме с тремя узлами А, Б и В он получил, к примеру, номер Б1 и прекрасно прошел проверку на уникальность.
Ну то есть, если число узлов заранее известно и не меняется, да, проблем нет - нам даже вшивать ничего не надо, считаем хэш, берем пару-тройку последних байт, делим по модулю на число узлов, пихаем в один и тот же, обеспечиваем уникальность. Это я знаю, умею, более того - на этом уже работаю. Но хочется и пункты 1-2 из исходной задачки :(
Видишь-ли - тебе придется так и эдак распредлять констрейнты, а точнее поддерживать на всех нодах их примерно целиком. Боюсь что без распределенных транзакций тебе это сделать будет крайне не просто, особенно чтобы не встрят при этом в какие-нибудь чудовищные репликационные топологии.
Да, именно этого я и опасался. Тем более, что чистая репликация не получится точно - идентификатор привязан на одной ноде к плательщику с uid=1, на второй - к uid=10 и так далее. То есть, по-любому перелопачивать при бродкастинге по нодам.
Щас уже обдумываю мысль, хватит ли шардинга кетамой с оповещением только лишь соседних нод или не хватит.
В общем, на первом этапе обойдемся кетамой. При изменении весов или добавлении/удалении узла - перенос уникальных идентификаторов с одного узла на соседний с блокировкой узлов на время переноса. В дальнейшем - раздача сестрам по серьгам и передача сообщений с uniq_id на все узлы, чтобы снизить время простоя в момент, когда два соседних узла синхронизируются.
Reply
Мне даже не столько наличие готовых инструментов интересует, сколько сама алгоритмистика как сделать шард по таким условиям. Написать/переписать алгоритм под наши нужды - не самое страшное
Reply
Reply
Ладно, может будет легче после более предметного описания:
У меня есть тяжелый плательщик, который хочется разделить на несколько подплательщиков, каждый из которых будет жить в отдельной базе и все транзакции проводить внутри базы. Казалось бы, ничего сложного - берем любой алгоритм шардинга, хоть деление по модулю, хоть кетаму и выбираем i-го плательщика. Но есть "но" - в деталях платежа передается ключ, уникальность которого надо контролировать на всех базах, где живут подплательщики. Причем контролировать в момент проведения платежа, внутри транзакции. Проблем нет, если строго зашить число узлов и потом не менять. Но если хочется добавлять узлы или отключать - хрена с два это выйдет, уникальность может поехать. Ну и весовая балансировка в таком случае тоже не вижу, как может работать...
Да, значения ключей я как-то могу менять, если того потребует алгоритм. Лишь бы они и после этого были уникальными.
Reply
Reply
Ну допустим было у нас 2 узла А и Б.
В момент времени T1 платеж с идентификатором 1 мы решили отправить в узел А
Получил он айдишник A1
В момент времени T2 у нас уже 3 узла и пришел еще один платеж с этим ID=1.
В схеме с одним плательщиком мы этот платеж завернули.
В схеме с тремя узлами А, Б и В он получил, к примеру, номер Б1 и прекрасно прошел проверку на уникальность.
Reply
Reply
Предлагаю отказаться от хотелки 2)
Reply
Reply
Reply
Тем более, что чистая репликация не получится точно - идентификатор привязан на одной ноде к плательщику с uid=1, на второй - к uid=10 и так далее. То есть, по-любому перелопачивать при бродкастинге по нодам.
Щас уже обдумываю мысль, хватит ли шардинга кетамой с оповещением только лишь соседних нод или не хватит.
Reply
Reply
Leave a comment