Привет! Меня зовут Денис, я бэкенд-тимлид в 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 не умеет работать с Tarantool, поэтому мы использовали следующее расширение. Для подключения необходимо пересобрать исполняемый файл К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

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

  • Вывод

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

  • Redis

  • Tarantool

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

  • Вывод

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

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

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

Берем 3 операции:

• установка значения по ключу

• чтение

• удаление

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

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: 100,
            duration: '120s',
        },
        test: {
            executor: 'constant-vus',
            exec: 'get_keys',
            vus: 100,
            duration: '120s',
        },
        test: {
            executor: 'constant-vus',
            exec: 'del_keys',
            vus: 100,
            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 запускались последовательно. 

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

Среднее 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: 100,
            duration: '120s',
        },
        get: {
            executor: 'constant-vus',
            exec: 'get',
            vus: 100,
            duration: '120s',
        },
        del: {
            executor: 'constant-vus',
            exec: 'del',
            vus: 100,
            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 запускались последовательно. 

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

Среднее RPS

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

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

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

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

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

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

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

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

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

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

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

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

? 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: 50,
           duration: "120s",
       },
       test_decr: {
           executor: "constant-vus",
           exec: "decr",
           vus: 50,
           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);
}

Среднее 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: 50,
           duration: '120s',
       },
       decr: {
           executor: 'constant-vus',
           exec: 'decr',
           vus: 50,
           duration: '120s',
       },
   },
};
export function setup() {
   for (let i = 1; i < 51; 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]]])
   }

Средний RPS

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

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

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

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

По результатам теста Tarantool незначительно уступил Redis.

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

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

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

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

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

? 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: 100,
            duration: '120s',
        },
        test_mem: {
            executor: 'constant-vus',
            exec: 'members',
            vus: 100,
            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);
}

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

Среднее 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: 100,
            duration: '120s',
        },
        members: {
            executor: 'constant-vus',
            exec: 'members',
            vus: 100,
            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()])
}

Среднее RPS

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

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

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

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

При работе со множествами Tarantool и Redis показали себя одинаково.

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

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

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

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

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

? Redis appendfsync: everysec

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

Среднее RPS

? Redis appendfsync: Always

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

Среднее RPS

? Redis appendfsync: No

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

Среднее RPS

? Tarantool wal_mode Write

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

Среднее RPS

? Tarantool wal_mode: None

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

Среднее RPS

? Tarantool wal_mode: Fsync

Среднее 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"}})

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

Среднее RPS

? Redis

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

Среднее RPS

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

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

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

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

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

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

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

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

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

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

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

Среднее RPS

? 6.2 Tnt-master-slave

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

Среднее RPS

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

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

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

По результатам теста при репликации master-slave Redis с минимальным перевесом обошёл Tarantool в операциях чтения и удаления.

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

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

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

? Кластер Redis

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

Среднее 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.

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

Среднее RPS

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

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

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

При запуске в режиме кластера Redis выигрывает.

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

Redis

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

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

Tarantool

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

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

В результате 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. Это дает возможность выдерживать большую нагрузку при максимальной сохранности данных.

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

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

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