Pull to refresh

Comments 11

Спасибо, расписано очень доступно и в то же время весьма подробно.

Я пока только присматриваюсь к Tarantool, в связи с чем у меня такой вопрос:

Допустим, есть большой плоский массив, скажем, на 100М штук uint64.
Может ли кластер Tarantool эффективно реплицировать работу с таким массивом — поддерживать консистентное состояние, хранить данные в компактном виде (т.е. именно массив, а не хеш-таблица), и пересылать обновления только для изменяемых элементов массива, а не весь массив целиком при каждой операции?
Добрый день.
Tarantool хранит таплы в msgpack, а для построения индекса используется по умолчанию b+* дерево. Под эту задачу можно оценить количество памяти в несколько гигабайт.
При репликации пересылаются только изменённые строки (row based репликация), весь массив массив будет пересылаться тольео если вы подключаете новый узел.
UFO just landed and posted this here

Простите пожалуйста, а что такое col based репликация?


Я знаю, что сторадж бывает column based. Но про репликацию не слышал.


А вообще, если я правильно помню, тарантул реплицирует операции: т.е. если был update c=c+1 where id=100, то только эта операция и будет реплицирована. Могу ошибаться.

А с шардированием из коробки у вас как теперь? Был модуль, помню, но до production-ready он не дотягивал тогда.
Сейчас у нас есть модуль vshard, он построен на бакетах, умеет балансировать бакеты между узлами, добавлять и удалять шарды, использовать сразу несколько роутеров и поддерживать на всех актуальную таблицу маршрутов до бакетов. Мы уже используем его в нескольких проектах в production.
Спасибо за статью. Очень познавательно.
У меня такой вопрос. Мы сейчас используем Редис. В нем тоже репликация асинхронная. Редис в Azure. Есть подозрение, что всякий раз, когда машина перегружается и нас переключают на новую состояние базы не соответствует действительности, что для нас критично.
Можно ли как-то от этого защититься используя Тарантул?
В силу асинхронности, реплика может отстать, отставание мониторится в box.info.replication, параметр lag — время в секундах. Оценить отставание в записях можно сравнивая vclock на мастере и реплике. При этом «битых» данных быть не должно.
После возврата мастера реплика докачает все изменения с мастера.
Если есть возможность немного «подержать» мастер — то можно дождаться когда реплика дозагрузит все данные с мастера, сравнивая vclock самого мастера и реплики в replication.downstream
Благодарю. Нам всё таки для полной надёжности нужна синхронная репликация. несмотря на то, что продукт ваш очень привлекателен, надёжность репликации нам оч важна
Сейчас можно сделать «как-бы синхронную» репликацию — если код вынести в хранимые функции в которых дожидаться подтверждения от реплики — но это не так быстро как могло бы быть.
Либо подождать до лета, возможно синхронная репликация будет в ядре tarantool к этому времени (тикет 980 в тикетнице на гитхабе)
Хорошие новости. Спасибо
Sign up to leave a comment.