Comments 11
Спасибо, расписано очень доступно и в то же время весьма подробно.
Я пока только присматриваюсь к Tarantool, в связи с чем у меня такой вопрос:
Допустим, есть большой плоский массив, скажем, на 100М штук uint64.
Может ли кластер Tarantool эффективно реплицировать работу с таким массивом — поддерживать консистентное состояние, хранить данные в компактном виде (т.е. именно массив, а не хеш-таблица), и пересылать обновления только для изменяемых элементов массива, а не весь массив целиком при каждой операции?
Я пока только присматриваюсь к Tarantool, в связи с чем у меня такой вопрос:
Допустим, есть большой плоский массив, скажем, на 100М штук uint64.
Может ли кластер Tarantool эффективно реплицировать работу с таким массивом — поддерживать консистентное состояние, хранить данные в компактном виде (т.е. именно массив, а не хеш-таблица), и пересылать обновления только для изменяемых элементов массива, а не весь массив целиком при каждой операции?
0
Добрый день.
Tarantool хранит таплы в msgpack, а для построения индекса используется по умолчанию b+* дерево. Под эту задачу можно оценить количество памяти в несколько гигабайт.
При репликации пересылаются только изменённые строки (row based репликация), весь массив массив будет пересылаться тольео если вы подключаете новый узел.
Tarantool хранит таплы в msgpack, а для построения индекса используется по умолчанию b+* дерево. Под эту задачу можно оценить количество памяти в несколько гигабайт.
При репликации пересылаются только изменённые строки (row based репликация), весь массив массив будет пересылаться тольео если вы подключаете новый узел.
0
UFO just landed and posted this here
А с шардированием из коробки у вас как теперь? Был модуль, помню, но до production-ready он не дотягивал тогда.
0
Спасибо за статью. Очень познавательно.
У меня такой вопрос. Мы сейчас используем Редис. В нем тоже репликация асинхронная. Редис в Azure. Есть подозрение, что всякий раз, когда машина перегружается и нас переключают на новую состояние базы не соответствует действительности, что для нас критично.
Можно ли как-то от этого защититься используя Тарантул?
У меня такой вопрос. Мы сейчас используем Редис. В нем тоже репликация асинхронная. Редис в Azure. Есть подозрение, что всякий раз, когда машина перегружается и нас переключают на новую состояние базы не соответствует действительности, что для нас критично.
Можно ли как-то от этого защититься используя Тарантул?
0
В силу асинхронности, реплика может отстать, отставание мониторится в box.info.replication, параметр lag — время в секундах. Оценить отставание в записях можно сравнивая vclock на мастере и реплике. При этом «битых» данных быть не должно.
После возврата мастера реплика докачает все изменения с мастера.
Если есть возможность немного «подержать» мастер — то можно дождаться когда реплика дозагрузит все данные с мастера, сравнивая vclock самого мастера и реплики в replication.downstream
После возврата мастера реплика докачает все изменения с мастера.
Если есть возможность немного «подержать» мастер — то можно дождаться когда реплика дозагрузит все данные с мастера, сравнивая vclock самого мастера и реплики в replication.downstream
+1
Благодарю. Нам всё таки для полной надёжности нужна синхронная репликация. несмотря на то, что продукт ваш очень привлекателен, надёжность репликации нам оч важна
0
Сейчас можно сделать «как-бы синхронную» репликацию — если код вынести в хранимые функции в которых дожидаться подтверждения от реплики — но это не так быстро как могло бы быть.
Либо подождать до лета, возможно синхронная репликация будет в ядре tarantool к этому времени (тикет 980 в тикетнице на гитхабе)
Либо подождать до лета, возможно синхронная репликация будет в ядре tarantool к этому времени (тикет 980 в тикетнице на гитхабе)
0
Sign up to leave a comment.
Репликация в Tarantool: конфигурирование и использование