Comments 8
Не работал с Тарантулом, спасибо за хорошую статью. Но возник вопрос: каким будет сравнение Тарантула и MariaDb с движком инмемори, если они оба поддерживают sql формат запросов?
Я может не до конца понял сетап теста, но числа у вас получились откровенно странные, нормальное latency операций для in-memory базы данных это RTT + микросекунды на саму операцию, а не сотни миллисекунд, то же касается и rps — снять с локального редиса 500k rps вообще не составляет никаких проблем при использовании пайплайнинга.
Судя по времени - как-будто у них тестировался бекэнд перед бд, хотя даже для того же мускля тайминги в 100+ мс довольно дикие.
Я вот тоже задаюсь тем же вопросом.
Или ошибка в тексте и там указаны ns (но тогда маловато) или использованы какие-то очень странные конфигурации, не связанные с реальной жизнью (где ответ от кэша больше 5ms уже выглядит слишком долгим).
Cпасибо за замечания! В тестах было указано неверное количество пользователей, из-за этого возникала большая нагрузка на сеть, что приводило к задержкам в ответах. Провели повторные тестирования и исправили результаты.
Молодцы, что взялись всё перемерить и выложили статью снова!
Позволю себе немного перефразировать ваши выводы :)
Если вам нужен in memory application server, то смело берите Tarantool — отличная база, хорошо себя зарекомендовавшая в экосистеме Mail.ru, во всех остальных ситуациях используйте Redis — прекрасный продукт для сценариев без высоких требований к консистентности.
Не, лучше не стало.
Тесты с записью мерят что угодно, но не скорость работы с диском. Это следует из-за отсутствия разницы запросов с fsync и без него.
А про то, что в кластере Тарантул заметно снизил производительность, а Редис увеличил как-то в резюме умудрились пропустить (хотя проблемы скорее всего в настройках).
Ну и по результатам кажется, что тестировали не Redis/Tarantool, а особенности сети.
Нагрузочный поединок: Tarantool 2.10 vs Redis 7.0.5