VShard — горизонтальное масштабирование в Tarantool

[bolshaaan]

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

…

Второе — lock-free перенос bucket’ов. Уже реализован алгоритм, при помощи которого можно не блокировать bucket’ы на запись даже на время переноса.

Интересно, как lock-free перенос избегают проблему с бесконечными переносимыми апдейтами?

[gerold103]

Есть такой алгоритм: github.com/tarantool/vshard/issues/73#issuecomment-412996678
И есть начатый патч: github.com/tarantool/vshard/commit/3346a02b7ab51a73bc39f2b5e0e94e06a2ce2ff3 Но то, что сейчас реализовано в мастере, пока всех устраивает, и потому этот патч не особо продвигается. Блокировка там будет, но не на все время переноса, а только в самом конце.

[Sherman81]

Напоминает стерильные партиции Стоунбрейкера и voltdb ;-)

[Sherman81]

Привет, а допускается ли в одной транзакции вставка или модификация записей более, чем в одном бакете и если да, то на бакетах, которые физически находятся на разных машинах?

[maxim_ge]

Здравствуйте! Читаю материалы по tarantool и вот дошел до этой статьи.

Благодаря bucket’ам и локальности по bucket id мы всегда можем прочитать данные с одного узла за один запрос, независимо от размера кластера.

Весьма похоже на cassandra, с ее partition key. Вы можете сформулировать, в чем преимущества tarantool перед cassandra?

И еще вопрос — в cassandra я могу поставить consistency level = 2, или даже 5, и данные будут сохранятся на два или пять узлов одновременно, тем самым достигается high availability — выход из строя узла не означает потери данных. Как с этим у tarantool?