Нагрузочный поединок между Tarantool 2.10 и Redis 7.0.5

Привет! Меня зовут Денис, я бэкенд-тимлид в KTS.

Tarantool и Redis по большей части — два очень разных продукта. Начиная от заложенной в них функциональности и заканчивая протоколом, репликацией и кластерными решениями. 

Тем не менее в них много схожего. И Tarantool, и Redis — «однопоточные» базы данных. Однопоточные взято в кавычки, потому что имеется в виду только транзакционный поток, работающий непосредственно с хранилищем. Конечно, есть и сетевые потоки, и потоки репликации, и потоки работы с диском. Также оба эти продукта — in-memory решения, если не брать в расчёт отдельный дисковый vinyl движок в Tarantool. 

В статье мы хотим рассмотреть: что, если взять Tarantool как замену Redis? Просядет ли производительность из-за всех «дополнительных» фичей в Tarantool? Насколько хорошо или плохо справится дисковая подсистема с нагрузкой?

Мы взяли типичные кейсы работы с Redis и реализовали такие же механики на Tarantool, начиная от простых K-V операций и заканчивая вторичными ключами и производительностью кластерных решений: для Tarantool это Tarantool Cartridge, для Redis — Redis Cluster.

Выводы из нашего исследования можно прочесть в конце статьи.

Для тестирования использовали Grafana K6 — инструмент для нагрузочного тестирования, который позволяет создавать и запускать тестовые сценарии на JavaScript и анализировать результаты тестирования. Он имеет широкий набор функций для создания тестовых сценариев и может работать с различными протоколами, такими как HTTP, WebSocket, gRPC и т.д. 

Grafana K6 можно использовать как в командной строке, так и в интерфейсе Grafana. Удобной особенностью K6 является возможность подключать сторонние расширения для работы с протоколами, которые изначально не поддерживаются К6.  Так, из коробки К6 не умеет работать с Тарантулом, поэтому мы использовали следующее расширение. Для подключения необходимо пересобрать исполняемый файл К6 с использованием исходного кода нужного дополнения.

За время тестирования мы рассмотрели 7 сценариев:

• Сценарий 1: key-value c операциями set/get/delete

  • Redis

  • Tarantool

  • Сравнительные таблицы

  • Вывод

• Сценарий 2: счетчик c операциями incr/decr

  • Redis

  • Tarantool

  • Сравнительные таблицы

  • Вывод

• Сценарий 3: работа со множествами

  • Redis

  • Tarantool

  • Сравнительные таблицы

  • Вывод

• Сценарий 4: работа с диском

  • Redis appendfsync: everysec

  • Redis appendfsync: Always

  • Redis appendfsync: No

  • Tarantool wal_mode Write

  • Tarantool wal_mode: None

  • Tarantool wal_mode: Fsync

  • Сравнительные таблицы

  • Вывод

• Сценарий 5: вторичные индексы

  • Redis

  • Tarantool

  • Сравнительные таблицы

  • Вывод

• Сценарий 6: влияние репликации на производительность

  • Redis master-slave

  • Tnt master-slave

  • Tnt master-master

  • Сравнительные таблицы

  • Вывод

• Сценарий 7: кластер

  • Redis

  • Tarantool

  • Сравнительные таблицы

  • Вывод

• Общие выводы из сравнительного нагрузочного тестирования

Сценарии 1-5 выполнялись на виртуальной машине со следующими характеристиками: Ubuntu, 4 cpu, 16 gb RAM, 30 gb ssd.
Сценарий 6 выполнялся на двух виртуальных машинах Ubuntu, 4 cpu, 16 gb RAM, 30 gb ssd.
Все сценарии выполнялись с профилем нагрузки в 3500 виртуальных пользователей, длительностью 120 секунд.

Сценарий 1. Простой Key-Value 

Берем 3 операции: установка значения по ключу, чтение и удаление. Создаем 3500 пользователей, которые начинают слать запросы. Ключом является id пользователя + номер его запроса, значение сохраняем равное ключу.

Используем SET/GET/DEL команды в редисе и аналоги в Tarantool.

Redis:
Дефолтная конфигурация

Tarantool:
Дефолтная конфигурация
Спейс с полями (key string, value string)