Информация

Дата основания
Местоположение
Россия
Сайт
team.mail.ru
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре

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


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


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

Есть такой алгоритм: github.com/tarantool/vshard/issues/73#issuecomment-412996678
И есть начатый патч: github.com/tarantool/vshard/commit/3346a02b7ab51a73bc39f2b5e0e94e06a2ce2ff3 Но то, что сейчас реализовано в мастере, пока всех устраивает, и потому этот патч не особо продвигается. Блокировка там будет, но не на все время переноса, а только в самом конце.
Напоминает стерильные партиции Стоунбрейкера и voltdb ;-)
Привет, а допускается ли в одной транзакции вставка или модификация записей более, чем в одном бакете и если да, то на бакетах, которые физически находятся на разных машинах?
Здравствуйте! Читаю материалы по tarantool и вот дошел до этой статьи.

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


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

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