Сравнение Tarantool с конкурентами в Microsoft Azure
Tarantool — NoSQL СУБД, которая разрабатывается и широко используется в Mail.Ru Group. Об объемах использования можно сделать вывод по публикациям:
Недавно Mail.Ru Group выпустила виртуальную машину с предустановленным Tarantool для Microsoft Azure:
Мы решили проверить, насколько хорошо Tarantool работает в Microsoft Azure в сравнении с другими подобными предложениями — Azure Redis Cache, Bitnami Memcached, Aerospike и VoltDB. Под словом «хорошо» будем понимать «быстро», то есть сравнивать будем число обрабатываемых запросов в секунду (Throughput, RPS).
Нам потребуется инстанс Azure Redis Cache уровня «Базовый C4» (13 Гб), в котором мы включаем не SSL-порт (для честного сравнения SSL нам не требуется). Использовать именно базовый уровень нужно для того, чтобы исключить репликацию. Azure Redis Cache предоставляется как сервис, и доступа к виртуальной машине мы не имеем. Мы не знаем, как он настроен, не можем на это повлиять. Ориентировочная стоимость Redis Cache нашего размера — 9765 рублей в месяц.
Нам потребуется одна виртуальная машина Tarantool VM Standard D11 с 14 Гб с HDD-дисками. Данная конфигурация обойдется нам в 9067 рублей в месяц. Мы будем тестировать Tarantool в двух режимах: с включенным write-ahead logging (для персистентности данных) и с выключенным, так как мы не знаем достоверно, включена ли соответствующая настройка у Redis.
Для смены режима записи в /etc/tarantool/instances.enabled/example.lua меняем настройку wal_mode (none для работы без WAL, write — с WAL, fsync — весьма специфичный режим работы, который тестировать не будем).
Tarantool, в отличие, например, от Redis, имеет TREE-индексы, однако нам нужно сравнивать равное с равным, поэтому использовался HASH-индекс.
Мы взяли для теста образ виртуальной машины Standard D11 с предустановленным Memcached от Bitnami.
В Azure Marketplace есть и другой Memcached — облачный сервис от Redis Labs, однако доступен он только на территории США, и протестировать его не получилось.
После развертывания виртуальной машины мы отключили аутентификацию в конфигурационном файле memcached.conf (опция –S).
Memcached не умеет обеспечивать персистентность данных.
Для Aerospike мы взяли официальный образ из Azure Marketplace (Standard D11).
А вот VoltDB в Azure Marketplace нет. Пришлось брать чистую виртуалку (Ubuntu 14.04 LTS) и устанавливать вручную из исходников. Зато приятно удивила Web-админка «из коробки», которая включала в себя живые графики, в том числе и число запросов в секунду.
Мы попробуем провести «синхронно-асинхронный» тест, то есть интерфейс у нас будет синхронный, но внутри с соединением будем работать асинхронным образом. Этот вид теста позволяет имитировать работу через одно соединение для множества синхронных клиентов. Чтобы исключить сомнения в идентичности теста для Redis Cache, Tarantool VM и Memcached, всю общую логику вынесем в абстрактный класс NoSQLConnection, от которого потом отнаследуем TarantoolConnection, RedisConnection и MemcachedConnection (см. исходник).
В классе есть две очереди (обычные std: list) — OutputQueue (будет отправлено в сокет) и InputQueue (принятое из сокета), а также методы SendThreadFunc и ReceiveThreadFunc, которые запускаются в отдельных потоках и, при наличии соответствующих непустых очередей, отправляют/принимают информацию пачкой с помощью методов Send и Receive (чистые виртуальные, реализованы в наследниках).
Синхронный интерфейс представлен методом DoSyncQuery, который кладет запрос в OutputQueue и ждет ответа в InputQueue. Тестовая виртуалка должна быть достаточно мощной (мы использовали Standard D3) и находиться географически рядом с базой данных (мы использовали расположение «Западный регион США»).
Ввиду особого строения клиентских библиотек Aerospike и VoltDB (встроенный event-loop), тест для них был написан отдельно.
В диапазоне до 10 клиентских потоков с шагом 1 ёмы близки к полностью синхронному режиму работы (а один поток, по сути, им и является). На графике наблюдается более-менее линейный рост. Redis и Memcached дают примерно равную производительность, Tarantool быстрее, Aerospike самый быстрый, а вот VoltDB, наоборот, самый медленный.
Следующий график — до 100 потоков с шагом в 10, для Tarantool, Redis и Memcached линейный рост продолжается, Aerospike и VoltDB «тормозятся», причем на разных значениях.
Далее идем до 1000 с шагом в 100 потоков. Рост замедляется везде, а для Memcached и вовсе останавливается.
И наконец, идем до 8000 потоков с шагом 1000. Рост прекращается. После 4000 клиентов Memcached перестает работать — закрывает соединение, поэтому протестировать его не удается. VoltDB умирает еще раньше — на 3000 клиентах.
В итоге, мы видим лидерство Tarantool на больших нагрузках (на небольших Aerospike все-таки побыстрее).
А тут все просто. Запускаем синхронно-асинхронный тест в один поток, и он очевидным образом становится просто синхронным. Но если клиентов много, то потребуется много соединений… Хорошо, тогда запустим несколько тестов параллельно и просуммируем результаты.
Aerospike и VoltDB в таком режиме не тестировались.
Мы видим, что синхронный тест имеет определенный «потолок», который ниже, чем у синхронно-асинхронного соединения. Этот потолок вызван накладными расходами на сеть.
Сами Tarantool, Memcached, Aerospike и VoltDb бесплатны, оплачивать нужно только виртуальную машину, на которой они запущены. Мы использовали Standard D11 (14 Гб оперативной памяти), который стоит ~9067 рублей в месяц. Azure Redis Cache немного дороже — ~9765 рублей в месяц за базовый C4 инстанс (13 Гб оперативной памяти). Визуализируем.
Согласны, что ничего не понятно? Цены почти равны… Однако, как мы видели ранее, эти базы данных имеют разную производительность. Попробуем выразить стоимость не в месяц, а на миллиард запросов. Сперва посмотрим, сколько стоит миллиард запросов записи при 1000 клиентах.
VoltDB тут явный аутсайдер. Уберем его.
Теперь уберем Aerospike и Memcached, чтобы посмотреть на лидеров вблизи.
А теперь как изменится стоимость, если считать запросы на чтение на 100 клиентах.
Оставляем только лидеров.
В процессе тестирования тестовый процесс в синхронно-асинхронном тесте вызывал нагрузку на процесс Tarantool до 70% CPU, в синхронном режиме — до 100%. На всех графиках Tarantool VM, вне зависимости от режима WAL, показал себя лучше конкурентов. Заметим, что наличие или отсутствие WAL не влияет на скорость чтения из Tarantool (на графиках чтения оранжевая и серая кривые совпадают), так как при чтении из Tarantool диск не используется. Кроме того, Tarantool VM оказался самым дешевым решением как на единицу времени (в месяц), так и на каждый запрос.
