Комментарии 19
Для нас самое сложное — это объяснить заказчикам, зачем им Tarantool. Это мы тоже научились делать лучше с помощью понятных материалов и готовых презентаций.

А можно пару слов об этом?
Через пару недель на tarantool.io появится раздел, который объясняет для рядового пользователя что такое tarantool, с картинками.

Плюс мы идем от кейсов использования: берем то что сделали для клиентов и их истории и делаем под каждую отдельную страницу. Так можно посмотреть на свою ситуацию и понять, похоже это на то что мы уже делали, или нет. Кейсы тоже очень скоро появятся на сайте.
Большинство наших клиентов нам не платят, а просто берут код с github. Но им тоже нужно понять что у нас за продукт. Так что это касается коммерции только частично.
Подскажите если ли в тарантул «взять все измененные данные по частичному ключу с какого то отрезка времени»?
например:

update videocollection:videoId_1:viewCount +5
update videocollection:videoId_1:likeCount +3

var lastChangesValues = GetAllChangesDataFrom('2020-08-12 18:00', "videocollection:*");
Можно создать TREE индекс по времени изменения, пройтись по этому отрезку с помощью небольшого Lua-скрипта и обновить то, что интересует.

Условно вот так:
for _, tuple in box.space.videocollection.index.timestamp:pairs({'2020-08-12 18:00'}, {iterator = 'GE'}) do
    box.space.videocollection:update({tuple['videoId_1']}, {
        {'+', 'viewCount', 5},
        {'+', 'likeCount', 3},
    })
end
Вопрос был про другое по-моему, как выбрать записи, в которых было update… set viewCount = viewCount + 5 и likeCount = likeCount +3 недавно. Ну как бы обычный select по индексу по полю timestamp изменения, собственно, ничего необычного
Можно сделать поле с таймштампом вторичным индексом. Тогда можно будет сделать запрос типа «SELECT * FROM videocollection WHERE timestamp > ...». Как выполнять SQL запросы, можно посмотреть тут www.tarantool.io/en/doc/2.2/tutorials/sql_tutorial.

В целом запросы по частичному ключу у нас поддерживаются и составные индексы тоже.
Поздравляю) Торт в красный чатик!

PS: Давно используем тарантул в продакшене, в том числе движок vinyl. И до сих пор понимаем, что для некоторых моментов, действительно, не знаем аналогов.

Про синхронную репликацию — хотелось бы уточнить, как происходит процесс. Вставка на мастере — репликация — фиксирование? Или же параллельная вставка во все реплики — фиксирование?

Сейчас синхронная репликация [упрощенно] работает так:

— клиент делает вставку в мастер
— мастер коммитит локально, но ответ не возвращает
— операция едет на реплику и применяется там
— мастер получает уведомление что реплика применила операцию
— мастер возвращает клиенту «ОК»

Там есть много нюансов еще с транзакционным движком чтобы соседние транзакции не видели неподтвержденные еще операции.

В конечном итоге мы будем делать полноценный RAFT (ближе к концу года).
Благодарю, это именно то, что хотелось узнать. А каким образом, если не секрет, при таком механизме latency увеличивается на 5% всего?

Тут же добавляется сеть и операция на втором узле, как минимум в два раза медленнее должно быть.
На 5% уменьшается пропускная способность. Latency увеличивается сильнее (возможно 2x, потому что есть дополнительный сетевой поход). Из-за увеличения latency соответственно увеличивается входная очередь запросов (по закону Литтла). Поэтому нужно больше файловых дескрипторов и памяти на буферы.
Да, тут я попутал. Скопирую свой вопрос по ссылке: «Вроде как поток обработки (а каждый сервер Tarantool работает в один поток?) должен на каждой транзакции останавливаться и ждать окончания репликации, что не может не сказаться на RPS».

Иначе говоря, если требуемое время на транзакцию увеличилось в два раза, каким образом «пропускная способность» уменьшилась всего на 5%?
Благодаря интерактивным транзакциям. Раньше мы были serializable, а теперь read committed. То есть мы не прерываем входящие запросы пока транзакция ждет подтверждения.
С этим понятно. А с выполнением скриптов LUA как обстоят дела? Они параллельно выполняются или таки последовательно?
Они выполняются по модели легковесных потоков. На блокирующих операциях выполняются другие потоки. То есть если вы делаете транзакции из Lua, в которых будет синхронная репликация, то другие Lua операции будут выполняться пока их соседи ожидают подтверждения с реплик.
Не поверил глазам, открыл тот ответ — там написано что througoutput проседает на 5%, а латенси то сильнее, конечно.
Мои поздравления, замечательный продукт,
хочу его использовать в своих новых проектах
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

15 октября 1998 г.

Местоположение

Россия

Численность

5001–10000 человек

Дата регистрации

9 августа 2008