Redis — де-факто стандарт среди решений для In-memory-хранения данных. В марте 2024 года российские компании, использующие Redis были поставлены перед фактом, что в скором будущем им предстоит отказаться от нативного Redis: вендор Redis объявил о смене схемы лицензирования проекта на Redis Source Available License v2 для Community версии и Server Side Public License v1 для коммерческой версии. Поддержка ветки 7.2 будет полностью прекращена вендором в 2026 году. Документация проекта закрыта для российского пользователя.
В связи с этим для многих компаний стал актуальным вопрос поиска альтернатив Redis.
Коротко о Меркурий
Меркурий (MerQry) — прямой потомок Redis 7.2, резидентная СУБД формата «ключ — значение» класса NoSQL. Инструмент реализует In-memory-хранение, что кратно повышает доступность данных и скорость работы с ними.
Меркурий унаследовал от Redis все существенные для пользователя особенности. Среди них:
- повышенная производительность, которая достигается за счет хранения данных в оперативной памяти;
- использование команд Redis;
- Поддержка протоколов RESP v.2 и RESP v.3
- хранение данных не в табличном виде, а в формате «ключ — значение»;
- возможность гибкого масштабирования и работы с большими объемами данных.
Меркурий можно использовать в качестве:
- хранилища пользовательских сессий и промежуточных данных;
- брокера сообщений;
- кэша;
- хранилища для данных, к которым нужен быстрый доступ.
В версии 8 Меркурия сделана успешная попытка побороть такой недостаток Redis, как однопоточность. Один инстанс может осуществлять одновременно параллельную обработку нескольких запросов на чтение.
При таких условиях можно утверждать, что для drop-in заены Redis Меркурий является предпочтительным решением;
Для создания персистентного In-Memory кэша Меркурий проигрывает Тарантулу.
Коротко о Тарантул (Tarantool DB)
Преимущества Tarantool следующие:
- высокая надежность хранения данных, в том числе поддержка ACID;
- поддерживка как асинхронной, так и синхронной репликации;
- возможность наложения ограничений (constraint) на данные;
- наличие аудита операций с данными.
Теперь посмотрим на недостатки:
- необходимость наличия минимум двух реплик для базовой отказоустойчивости;
- необходимость установки стороннего ПО для развертывания и управления кластером;
- отсутствие механизма вытеснения ключей;
- невозможность прерывания процедуры без остановки кластера;
- менее высокая производительность по сравнению с Redis.
Что это означает на самом деле:
- Начнем с того, что Redis зачастую использовался как наименее затратное решение, в том числе по требуемым ресурсам. Тарантул - решение высокозатратное: для использования решения Redis+Sentinel с целью иметь один поток под запись/чтение и два потока только под чтение, инстансам Тарантул необходимо передать троекратный объем оперативной памяти, требуемой для размещения базы данных; также необходимо предусмотреть ресурсы для ПО управления кластером.
- Ввиду отсутствия механизмов вытеснения ключей, нужно строго следить за использование потребителями корректного времени жизни ключей, поскольку в противном случае произойдет остановка ПО ввду иссчерпания лимитов памяти, либо иметь возможнсть оперативного добавления ресурсов со всеми вытекающими последствиями.
Все это говорит нам о том, что для создания персистентного кэша Тарантул является предпочтительным решением.
Для drop-in замены Redis в произвольном случае Тарантул не подходит.