Привет! Меня зовут Денис, я бэкенд-тимлид в 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)

???? Redis

import redis from 'k6/experimental/redis';
import exec from 'k6/execution';


export const options = {
    discardResponseBodies: true,
    scenarios: {
        test: {
            executor: 'constant-vus',
            exec: 'set_keys',
            vus: 3500,
            duration: '120s',
        },
        test: {
            executor: 'constant-vus',
            exec: 'get_keys',
            vus: 3500,
            duration: '120s',
        },
        test: {
            executor: 'constant-vus',
            exec: 'del_keys',
            vus: 3500,
            duration: '120s',
        },
    },
};
const client = new redis.Client({
    addrs: new Array('host:port’),
    password: '',
    db: 0,
});


export function set_keys() {
    client.set(exec.vu.iterationInInstance + exec.vu.idInInstance * 100, exec.vu.iterationInInstance + exec.vu.idInInstance * 100);
}
export function get_keys() {
    client.get(exec.vu.iterationInInstance + exec.vu.idInInstance * 100);
}
export function del_keys() {
    client.del(exec.vu.iterationInInstance + exec.vu.idInInstance * 100);
}

Сценарии set_keys, get_keys, del_keys запускались последовательно. 

Результаты выполнения сценариев

Set_keys

Get_keys

Del_keys

Среднее RPS

Время выполнения запросов

???? Tarantool

Для проведения сценария создадим таблицу в Тарантуле вида ключ-значение, где ключ – это число, а значение – строка. Для поиска по ключу нам понадобится первичный индекс:

box.cfg{listen="127.0.0.1:3301"}
box.schema.space.create("test")
box.space.test:format({{name="name", type="unsigned"}, {name="value", type="string"}})
box.space.test:create_index("primary", {parts={"name"}})

import tarantool from "k6/x/tarantool";
import exec from 'k6/execution';


const conn = tarantool.connect(“host:port”);
export const options = {
    discardResponseBodies: true,
    scenarios: {
        set: {
            executor: 'constant-vus',
            exec: 'set',
            vus: 3500,
            duration: '120s',
        },
        get: {
            executor: 'constant-vus',
            exec: 'get',
            vus: 3500,
            duration: '120s',
        },
        del: {
            executor: 'constant-vus',
            exec: 'del',
            vus: 3500,
            duration: '120s',
        },
    },
};

export function set() {
    tarantool.replace(conn, "test", [exec.vu.iterationInInstance + exec.vu.idInInstance * 100, (exec.vu.iterationInInstance + exec.vu.idInInstance * 100).toString()])
};
export function get() {
    tarantool.call(conn, "box.space.test:select", [exec.vu.iterationInInstance + exec.vu.idInInstance * 100])
};
export function del() {
    tarantool.call(conn, "box.space.test:delete", [exec.vu.iterationInInstance + exec.vu.idInInstance * 100])
};

Сценарии set_keys, get_keys, del_keys запускались последовательно. 

Результаты выполнения сценариев

Set_keys

Get_keys

Del_keys

Среднее RPS

Время выполнения запросов

Сравнительная таблица по RPS

Сравнительная таблица по медиане и перцентилям времени выполнения запросов

Вывод по сценарию 1

Tarantool чуть быстрее в операциях записи и чтения, а Redis — в удалении.

Сценарий 2. Счетчик

Создаем 100 пользователей, которые отправляют запросы на увеличение или уменьшение счетчика. Для каждого пользователя используется свой счетчик.

Используем INCR/DECR в Redis и аналогичные update операции в Tarantool.

Сценарии incr и decr выполняются параллельно. 

Создаем спейс с полями (key string, value integer).

Конфигурация

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

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

???? Redis

import redis from "k6/experimental/redis";
import exec from "k6/execution";


export const options = {
   discardResponseBodies: true,
   scenarios: {
       test_incr: {
           executor: "constant-vus",
           exec: "incr",
           vus: 1750,
           duration: "120s",
       },
       test_decr: {
           executor: "constant-vus",
           exec: "decr",
           vus: 1750,
           duration: "120s",
       },
   },
};
const client = new redis.Client({
   addrs: new Array("host:port"),
   password: "",
   db: 0,
});

export function incr() {
   client.incr("id" + exec.vu.idInInstance);
}
export function decr() {
   client.decr("id" + exec.vu.idInInstance);
}

INCR/DECR

Среднее RPS

Время выполнения запросов

???? Tarantool

box.cfg{listen="127.0.0.1:3301"}
box.schema.space.create("test")
box.space.test:format({{name="name", type="string"}, {name="value", type="integer"}})
box.space.test:create_index("primary", {parts={"name"}})

import tarantool from "k6/x/tarantool";
import exec from 'k6/execution';


const conn = tarantool.connect("host:port");
export const options = {
   discardResponseBodies: true,
   scenarios: {
       incr: {
           executor: 'constant-vus',
           exec: 'decr',
           vus: 3500,
           duration: '120s',
       },
       decr: {
           executor: 'constant-vus',
           exec: 'decr',
           vus: 3500,
           duration: '120s',
       },
   },
};

export function setup() {
   for (let i = 1; i < 1751; i++) {
       tarantool.replace(conn, "test", [i.toString(), 0]);
   }
};
export function incr() {
   tarantool.call(conn, "box.space.test:update", [exec.vu.idInInstance.toString(), [["+", 2, 1]]])
}
export function decr() {
   tarantool.call(conn, "box.space.test:update", [exec.vu.idInInstance.toString(), [["-", 2, 1]]])
}

INCR/DECR

Средний RPS

Время выполнения запросов

Сравнительная  таблица по RPS

Сравнительная таблица по медиане и перцентилям времени выполнения запросов

Вывод по сценарию 2

Результаты по rps практически одинаковые.

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

Добавляем и получаем значения из множества, используя команды SADD/SMEMBERS в Redis и реализовываем аналогичные возможности в Tarantool.

Создаем спейс kv с полями (key string, element string)/

Конфигурация

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

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

???? Redis

import redis from 'k6/experimental/redis';
import exec from 'k6/execution';


export const options = {
    discardResponseBodies: true,
    scenarios: {
        test_add: {
            executor: 'constant-vus',
            exec: 'add',
            vus: 3500,
            duration: '120s',
        },
        test_mem: {
            executor: 'constant-vus',
            exec: 'members',
            vus: 3500,
            duration: '120s',
        },
    },
};
const client = new redis.Client({
    addrs: new Array('host:port'),
    password: '',
    db: 0,
});


export function add() {
    client.sadd('test' + exec.vu.idInInstance*1000, (exec.vu.iterationInInstance + exec.vu.idInInstance * 100).toString());
}
export function members() {
    client.smembers('test' + exec.vu.idInInstance*1000);
}

SADD

SMEMBERS

Время выполнения запросов

Среднее RPS

???? Tarantool

box.cfg{listen="127.0.0.1:3301"}
box.schema.space.create("test")
box.schema.sequence.create('S', {min=1, start=1})
box.space.test:format({{name="id", type="unsigned"}, {name="name", type="string"}, {name="value", type="string"}})
box.space.test:create_index("primary", {sequence='S', parts={"id"}})
box.space.test:create_index("name", {unique=false, parts={"name"}})

import tarantool from "k6/x/tarantool";
import exec from 'k6/execution';


const conn = tarantool.connect(“host:port”);
export const options = {
    discardResponseBodies: true,
    scenarios: {
        add: {
            executor: 'constant-vus',
            exec: 'add',
            vus: 3500,
            duration: '120s',
        },
        members: {
            executor: 'constant-vus',
            exec: 'members',
            vus: 3500,
            duration: '120s',
        },
    },
};

export function add() {
    tarantool.insert(conn, "test", [null, (exec.vu.idInInstance*1000).toString(), (exec.vu.iterationInInstance + exec.vu.idInInstance * 100).toString()])
}
export function members() {
    tarantool.call(conn, "box.space.test.index.name:select", [(exec.vu.idInInstance*1000).toString()])
}

ADD

MEMBERS

Среднее RPS

Время выполнения запросов

Сравнительная  таблица по RPS

Сравнительная таблица по медиане и перцентилям iterations_duration

Вывод по сценарию 3

При работе со множествами Redis быстрее.

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

Тестируем Сценарий 1, меняя конфигурацию БД. Цель теста - определить производительность работы с диском Redis vs Tarantool.

Конфигурация

Redis:
Для тестов меняем параметр appendfsync (no, everysecond, always)

Tarantool:
Для тестов меняем параметр wal_mode (none, write, fsync)

???? Redis appendfsync: everysec

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

???? Redis appendfsync: Always

Set_keys

Get_keys

Delete_keys

Время выполнения запросов

Среднее RPS

???? Redis appendfsync: No

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

???? Tarantool wal_mode Write

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

???? Tarantool wal_mode: None

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

???? Tarantool wal_mode: Fsync

Set_keys

Get_keys

Delete_keys

Среднее RPS

Время выполнения запросов

Сравнительная  таблица по RPS

Сравнительная таблица по медиане и перцентилям iterations_duration

Вывод по сценарию

При логировании каждой записи (appendfsync always в redis и wal_mode fsync в tarantool) tarantool показал лучший результат.

Сценарий 5. Вторичные индексы

Kv в tarantool (id, value) со вторичным индексом на value.

Для добавления вторичных индексов в Redis использовался модуль Redisearch, скомпилированный под Ubuntu и запущенный через loadmodule

???? Tarantool

box.cfg{listen="127.0.0.1:3301"}
box.schema.space.create("test")
box.space.test:format({{name="id", type="unsigned"}, {name="value", type="string"}})
box.space.test:create_index("primary", {parts={"id"}})
box.space.test:create_index("secondary", {parts={"value"}})

Set_keys

Get_keys

Время выполнения запросов

Среднее RPS

???? Redis

Set_keys    

Get_keys

Время выполнения запросов

Среднее RPS

Сравнительная  таблица по RPS

Сравнительная таблица по медиане и перцентилям iterations_duration

Вывод по сценарию 5

tarantool производительнее на несколько тысяч rps при работе со вторичными индексами.

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

Тестируем Сценарий 1, меняя конфигурацию репликации. Цель теста - определить влияние репликации на производительность БД.

Проводим 3 теста:

• Сценарий 6.1 Redis с репликацией на 1 узел

• Сценарий 6.2 Tarantool с master-slave репликацией на 1 узел

• Сценарий 6.3 Tarantool с master-master репликацией на 1 узел

???? Сценарий 6.1 Redis master-slave

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

???? 6.2 Tnt-master-slave

Set_keys

Get_keys    

Del_keys    

Время выполнения запросов

Среднее RPS

???? 6.3 tnt master-master

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

Сравнительная  таблица по RPS

Сравнительная таблица по медиане и перцентилям iterations_duration

Вывод по сценарию 6

При репликациях master-slave и master-master tarantool быстрее в get/set сценариях, чем redis в режиме master-slave.

Сценарий 7. Кластер

В данном сценарии были развернуты кластеры Redis и Tarantool в следующей конфигурации: 3 шарда, в каждом шарде 1 мастер и 2 реплики. 

Характеристики виртуальных машин: Ubuntu, 4 cpu, 8 gb RAM, 10 gb ssd. Запускались тесты из сценария 1.

???? Кластер Redis

Set_keys

Get_keys

Del_keys

Время выполнения запросов

Среднее RPS

???? Кластер Tarantool

Топология кластера

Реализована пользовательская роль, реализующая следующие функции:

function del(id)
   local result, err = crud.delete('test', id)
   if err ~= nil then
       return err
   end
   return result
end
function add(id, value)
   local result, err = crud.insert('test', {id, value})
   if err ~= nil then
       return err
   end
   return result
end
  
function get(id)
   local result, err = crud.get('test', id)
   if err ~= nil then
       return err
   end
   return result
end

Для операций с данными использовался модуль crud.

Set_keys

Get_keys 

Del_keys

Время выполнения запросов

Среднее RPS

Сравнительная  таблица по RPS

Сравнительная таблица по медиане и перцентилям iterations_duration

Вывод по сценарию 7

при запуске в кластере Tarantool проигрывает Redis при операциях записи, производительности при получении и удалении данных почти не отличается.

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

Redis

Имеет важные преимущества. Он популярнее и как следствие, имеет большее комьюнити. В интернете представлено больше информации по вопросам использования Redis, следовательно, у технологии более низкий порог входа.

В основном Redis используется для реализации кеширования, и он хорошо подходит для этой роли: например, в первом сценарии он лишь незначительно уступил Tarantool. 

Tarantool

Если требуется полноценное решение для хранения данных и взаимодействия с ними, которое можно использовать в качестве основной БД, лучше присмотреться к Tarantool. Он ближе к привычной табличной организации данных, т.к поддерживает реляционную модель и запросы на SQL. При этом он способен выдерживать нагрузку, сравнимую с K-V БД вроде Redis.

Tarantool показал себя лучше под нагрузкой в сценариях 1, 4, 5, 6: у него меньше время ответа, он держит большее количество RPS, в нем из коробки реализованы вторичные индексы.

В результате Tarantool:

• Немного быстрее работает в режиме key-value

• Быстрее работает в режиме полной персистентности

• Быстрее работает в различных режимах репликации

Рассмотрим эти преимущества подробнее.

1. Tarantool немного быстрее работает в режиме key-value

Вторичные индексы часто используются при проектировании структуры базы данных. В случае Tarantool это позволяет производить поиск  не только по ключам, но и по значениям. 

Например: у нас имеется таблица вида «табельный номер — ФИО сотрудника», где табельный номер является ключом. 

• В Tarantool при создании вторичного индекса появляется возможность производить поиск не только по табельному номеру, но и по ФИО, что даёт возможность узнать табельный номер конкретного сотрудника

• В Redis тоже есть такая возможность, но для этого необходимо устанавливать модуль RediSearch. При этом производительность решения будет уступать Tarantool

2. Tarantool быстрее работает в режиме полной персистентности в in-memory базах

Tarantool показывает большую производительность при сбросе данных на диск в режимах wal_mode=write и wal_mode=fsync — в сравнении с Redis с параметром appendfsync=everysec и appendfsync=always соответственно.

Почему это важно: эти режимы нужны для возможности восстановления данных в случае сбоя. Все операции сохраняются в специальный файл, и в случае неисправности их можно воспроизвести и не потерять данные.

Разница между режимами выше — в частоте записи в файл. В режиме полной персистентности, когда операции записываются в файл сразу после их выполнения  с wal_mode=fsync, Tarantool выигрывает у Redis. Это дает возможность выдерживать большую нагрузку при максимальной сохранности данных.

3. Tarantool показывает большее быстродействие в различных режимах репликации по сравнению с Redis

Tarantool выигрывает режимах репликации master-slave и master-master.

Почему это важно: репликация необходима для масштабирования баз данных. Данные с одного сервера постоянно копируются на другие сервера, называемые репликами. Это дает возможность приложениям использовать не один сервер для обработки запросов, а сразу несколько.

Также репликация обеспечивает отказоустойчивость: в случае выхода из строя одного сервера его роль возьмет на себя одна из реплик. В случае репликации master-slave запросы на запись идут только на главный сервер, на slave данные дублируются. При master-master репликации запросы идут на оба сервера.

Совсем кратко

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

Исходный код тестов для К6 можно посмотреть в репозитории.