Мне даже не столько наличие готовых инструментов интересует, сколько сама алгоритмистика как сделать шард по таким условиям. Написать/переписать алгоритм под наши нужды - не самое страшное
Да не, алгоритм-то я напилю на чем-нибудь более серьезном, чем хранимые процедуры.
Ладно, может будет легче после более предметного описания:
У меня есть тяжелый плательщик, который хочется разделить на несколько подплательщиков, каждый из которых будет жить в отдельной базе и все транзакции проводить внутри базы. Казалось бы, ничего сложного - берем любой алгоритм шардинга, хоть деление по модулю, хоть кетаму и выбираем i-го плательщика. Но есть "но" - в деталях платежа передается ключ, уникальность которого надо контролировать на всех базах, где живут подплательщики. Причем контролировать в момент проведения платежа, внутри транзакции. Проблем нет, если строго зашить число узлов и потом не менять. Но если хочется добавлять узлы или отключать - хрена с два это выйдет, уникальность может поехать. Ну и весовая балансировка в таком случае тоже не вижу, как может работать...
Да, значения ключей я как-то могу менять, если того потребует алгоритм. Лишь бы они и после этого были уникальными.
Так. Если у нас транзакция с ID=1 изначально пришла на шард А, теперь всё, этот ID всегда должен приходить на А? Или после решардирования она может прийти на другой шард Б, но уникальность надо все равно проверить на А? (то есть сначала по Б, видимо, потом по А, если в Б такой записи нет)
От балды - айдишники могут быть, к примеру, UUID. То есть, необязательно монотонно-возрастающей числовой функцией.
Если у нас транзакция с ID=1 изначально пришла на шард А, теперь всё, этот ID всегда должен приходить на А? В идеале - да.
Или после решардирования она может прийти на другой шард Б, но уникальность надо все равно проверить на А? А как ты проверишь уникальность в рамках другой базы в пределах одной транзакции. Я ж написал - никаких XA
Comments 16
Reply
Мне даже не столько наличие готовых инструментов интересует, сколько сама алгоритмистика как сделать шард по таким условиям. Написать/переписать алгоритм под наши нужды - не самое страшное
Reply
Reply
Ладно, может будет легче после более предметного описания:
У меня есть тяжелый плательщик, который хочется разделить на несколько подплательщиков, каждый из которых будет жить в отдельной базе и все транзакции проводить внутри базы. Казалось бы, ничего сложного - берем любой алгоритм шардинга, хоть деление по модулю, хоть кетаму и выбираем i-го плательщика. Но есть "но" - в деталях платежа передается ключ, уникальность которого надо контролировать на всех базах, где живут подплательщики. Причем контролировать в момент проведения платежа, внутри транзакции. Проблем нет, если строго зашить число узлов и потом не менять. Но если хочется добавлять узлы или отключать - хрена с два это выйдет, уникальность может поехать. Ну и весовая балансировка в таком случае тоже не вижу, как может работать...
Да, значения ключей я как-то могу менять, если того потребует алгоритм. Лишь бы они и после этого были уникальными.
Reply
Reply
Reply
То есть, необязательно монотонно-возрастающей числовой функцией.
Если у нас транзакция с ID=1 изначально пришла на шард А, теперь всё, этот ID всегда должен приходить на А?
В идеале - да.
Или после решардирования она может прийти на другой шард Б, но уникальность надо все равно проверить на А?
А как ты проверишь уникальность в рамках другой базы в пределах одной транзакции. Я ж написал - никаких XA
Reply
Reply
Leave a comment