company_banner

Сравниваем Tarantool с Redis и Memcached

https://dzone.com/articles/tarantool-v-redis-in-memory-databases-face-off
  • Перевод

image


Выбираете между Tarantool и Redis или между Tarantool и Memcached? Давайте рассмотрим основные различия, чтобы вам легче было определиться.


Tarantool и Redis


Что касается in-memory баз данных, то у Redis по сравнению с Memcached улучшились возможности хранения кешированных данных, использования не только строковых, но и других типов данных, а также выполнения сложных операций с данными [1]. В Tarantool операции над группами данных вышли на ещё более высокий уровень сложности, причём с точки зрения надежности хранения (persistence) и индексирования Tarantool превосходит Redis, не говоря уж о скорости работы и поддержке пользователей [2]. Учитывая развитость средств хранения, а также возможность работы с транзакциями и большими объёмами данных, Tarantool можно эффективно использовать в качестве основной базы данных приложения — честно говоря, такой подвиг Redis не всегда по плечу [3].


Главный недостаток Redis — невозможность обрабатывать объёмы данных больше, чем объём оперативной памяти сервера. В Tarantool же можно выбирать движки хранения:


  • Memtx, работающий как традиционная in-memory БД,
  • или Vinyl/Disk, позволяющий использовать диски в сочетании с оперативной памятью.

Vinyl позволяет работать с данными, чей объём в 10—100 раз больше доступного объёма оперативной памяти [4]. Это достигнуто за счёт использования LSM-дерева (log-structured merge tree) вместо более распространённого B-дерева, что в итоге привело к устранению случайных операций записи — самого узкого места дисковых движков [5].


Redis и Tarantool поддерживают скрипты на Lua, т. е. позволяют применять к данным сложные функции. Кроме того, обе БД могут быть дополнены определёнными пакетами из экосистемы LuaRocks. Но прямо из коробки Tarantool использует более быстрый LuaJIT, в отличие от ванильной Lua-реализации в Redis. Также Tarantool оснащён полноценным, неблокирующим Lua-сервером приложений, у которого есть доступ к сети и внешним сервисам. При этом в Redis реализация Lua помещена в «песочницу», а скрипты блокируются [6]. То есть ожидание завершения Lua-процессов в Redis может снизить производительность, а в Tarantool такой проблемы нет: пока один вызов заблокирован на внешнем ресурсе, другой активный вызов, параллельно выполняющийся, продолжает работать.


Конечно, сравнение Tarantool с Redis было бы неполным без хотя бы краткого упоминания об их относительной пропускной способности и уровнях задержки. Тестирование на одной ноде с помощью бенчмарка Yahoo! Cloud Server Benchmark (YCSB) с прогоном шести основных типов нагрузки — update heavy, read mostly, read only, read latest, short ranges и read-modify-write — показало, что применительно к индексам Hash и Tree Tarantool опережает Redis при всех типах нагрузок. Также в большинстве случаев у Tarantool меньше latency. Это относится к нагрузкам с упреждающей записью в журнал и без неё.


Преимущество Tarantool объясняется работой в тандеме системы управления базами данных (DBMS) и полноценного сервера приложений [7]. У этого сервера, который может применяться и отдельно, целый набор дополнительных инструментов, а в Redis их нет. Одна из интересных фич сервера приложений Tarantool — возможность взаимодействовать с другими, более медленными базами данных с целью кеширования информации, хранящейся в них, и тем самым ускорять их работу: это относится к Oracle, IBM DB2, MySQL, MS SQL Server и PostgreSQL.


Tarantool оркестрирует и виртуализирует данные, ускоряя доступ к ним. Использование Tarantool в архитектуре почти любых энтерпрайз-приложений и сервисов позволяет уменьшить кодовые базы интеграции и масштабирования, а также снижает требования к серверам и оборудованию. К примеру, один сервер Tarantool может заменить десятки серверов, на которых крутится традиционная DBMS, поэтому вы сможете быстрее масштабировать свои микросервисы и приложения [8].


Tarantool и Memcached


Memcached (2003) и Tarantool (2009) относятся к двум разным поколениям in-memory баз данных на основе кеширования. Так что в некотором смысле сравнивать их не слишком честно, поскольку более свежие технологии обычно превосходят более ранние. Но если технология появилась позже, это ещё не значит, что она лучше годится для какой-то задачи. Иногда менее продвинутые инструменты предпочтительнее для определённых нужд. Будем исходить из предположения, что вы выбираете между Memcached и Tarantool для своего нового приложения или, возможно, раздумываете, продолжать ли поддерживать легаси-установку Memcached.


Кеширование против «умного» кеширования


Подход Memcached прост и хорош. Использующие его приложения проверяют, есть ли запрошенные данные в Memcached, прежде чем вызывать сопряжённую с ним более медленную базу. Однако Memcached и сопряжённая БД могут оказаться рассинхронизированы из-за сбоя обновления одного из них, поскольку оба они не реплицируются, а приложение взаимодействует с ними по отдельности. В Tarantool эта проблема решается с помощью «умного» кеширования: обновление завершится только после успешного обновления сопряжённой БД. То есть вместо взаимодействия с двумя уровнями приложение взаимодействует только с Tarantool, который отвечает за обновление сопряжённой БД. Кроме того, в любой момент к обработке данных можно подключить Lua-сервер приложений, работающий одновременно с сервером базы данных.


Чтение и запись


Основное различие между двумя способами кеширования заключается в их возможностях по обработке операций чтения и записи в сопряжённых базах данных. Memcached предназначен для уменьшения нагрузки на чтение, но не на запись. В Tarantool тоже реализована хорошая обработка операций чтения. Его высокая эффективность использования CPU может помочь уменьшить объём дорогостоящих реплик для медленных СУБД. При этом у Tarantool развитые возможности обработки операций записи. Он записывает на диск синхронно и поэтому может заменять собой дисковые СУБД. Кроме того, операции записи в Tarantool полностью соответствуют принципам ACID.


Холодный запуск


При запуске Memcached в нём нет данных, так что все операции выбора (select) должны передаваться напрямую в сопряжённую базу данных. В Tarantool это решается с помощью восстановления данных из сохранённых файлов.


Простота использования


Memcached прост в установке и позволяет быстро выполнять запросы GET и SET, чего в каких-то ситуациях вполне достаточно. Tarantool тоже легко устанавливается, но из-за более развитой функциональности имеет более обширный синтаксис. Однако если вы его освоите, то сможете применять Tarantool в самых разных сферах — от микросервисов до вышеупомянутой высоконагруженной транзакционной обработки данных, соответствующей ACID.


Независимость


Memcached был создан для поддержки других баз данных. Tarantool тоже работает в связке с другими базами, но может функционировать полностью независимо, что нехарактерно для кешевых решений. Это достигается с помощью надёжного хранения данных, полноценного сервера приложений, ACID-транзакций, возможности работать с данными, чей объём больше оперативной памяти. По сути, Tarantool не просто может работать независимо от реляционной СУБД, он способен вообще обходиться без дополнительного бэкенда в виде реляционной СУБД. Вы можете запрограммировать на Lua полноценную программу точно так же, как с помощью традиционных хранимых процедур.


Масштабирование


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


✽✽✽


Как видите, при выборе между Memcached и Tarantool придётся учесть много моментов, от проблем синхронизации до масштабирования. Если у вас есть какие-то вопросы о Tarantool, пишите в комментариях.


Ссылки


  1. http://www.infoworld.com/article/3063161/application-development/why-redis-beats-memcached-for-caching.html
  2. https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc
  3. https://news.ycombinator.com/item?id=3010345
  4. https://medium.com/@denisanikin/tarantool-vinyl-200k-transactions-per-second-on-a-disk-based-database-c5f3cbba6543
  5. https://medium.com/@denisanikin/when-and-why-i-use-an-in-memory-database-or-a-traditional-database-management-system-5737f6d406b5
  6. https://hackernoon.com/tarantool-vs-redis-38a4041cc4bc
  7. https://medium.com/tarantool-database/dbms-as-an-application-server-779402dbf485
  8. https://medium.com/@denisanikin/how-to-save-one-million-dollars-on-databases-with-tarantool-5eb1596ec628
  9. https://github.com/tarantool/vshard

Mail.Ru Group

782,07

Строим Интернет

Поделиться публикацией

Похожие публикации

Комментарии 47
    +2
    У редиса есть шардирование из коробки. Позволяет хранить там много данных с равномерной производительностью. А у тарантула как с горизонтальным ростом?
        0
        У вас новый шардинг уже в публичном доступе. Вот об этом была бы интересна статься. Почему от старого отказались? Какие вкусности будут в новом?
        За ссылку спасибо!
          0
          А вот по ссылке выше жеж все расписано
      0
      Почему бы не добавить Hazelcast
        –1
        Наверное потому, что он не совсем БД.
          +3
          а остальные совсем БД что ли?
            –1
            Хазелькаст предоставляет доступ к хранимой информации через объекты, реализующие стандартные интерфейсы, такие как List или Map, а не через запросы. В этой проекции любой HashMap можно назвать «базой данных», что будет очевидно не верным.
              +1
              redis/memcached умеют предоставлять доступ через запросы?
                0
                В спринге вы через redisTemplate что по сути дела делаете? Фактически запрос данных. Это несколько отличается от хазелькаста, где вы работаете с переменной в которой лежат значения. По-моему разница очевидна.
                  0
                  Можно привести пример на C#, Python?
                  Спасибо.
                    0
                    Не пишу на С# или Python, попробуйте спросить у гугла.
                      0
                      Способ доступа к ПО через фреймворк языка не является характеристикой этого ПО.
                      Поэтому redis такая же БД, как и file.txt :)
                        0
                        Побенчим редиску против файла? Хотя стоп, бенчат же как раз эффективность работы с данными, так что без ПО обеспечивающего доступ не обойтись. ч0рт, как же быть?
                          0
                          В общем приходим к выводу: питонщик джависта не разумеет :)
                          И прекращаем тред.
        0
        В tarantool есть блокирование ключей? Aka cache stampede protection
          0
          Оно не требуется, поскольку база и кеш находятся в одном инстансе и, более того, работает это всё в один поток :).
            0
            Ну если я хочу использовать Tarantool как кеш сервер, а как БД есть чтото другое? Или использовать Tarantool-а только как кеш сервера не рекоменуется?
              0
              Я бы не стал использовать тарантул просто как кеш :). Он умеет намного больше, и странно этим не пользоваться.
                +2
                Смена системы кеширования относительно не сложна обычна, а вот смена основной СУБД может означать переписывания большей части приложения.
          0

          Tarantool нету в AWS. Это сильно ограничивает возможность применения для многих проектов

              0

              Денис есть бесплатные сервисы у Mail.ru по типу AWS. Если их нет, то почему?

              +1

              Это просто кастомная AMIшка. Точно так же можно посоветовать apt-get install tarantool. Никакой интеграции с инфраструктурой AWS тут нет. Шардинг, репликация, метрики, alarms, autoscaling — все нужно будет настраивать самому. Сравните с тем, как организовано взаимодействие в ElasticSearch, например.


              Redis/Memcached кластер на 10 инстансов внутри VPC можно поднять при помощи простого CFN темплейта за 10 минут. По этому показателю Тарантул и рядом не валялся.

                0

                Что ограничивает применение Тарантула аналогичным образом? Об этом разрабочики умалчивают.

            +1
            Можно добавить сравнение с Apache Ignite?
            Спасибо.
              0
              Да, скоро появится
              0
              то, что скрипты Lua в Редисе вызываются синхронно, атомарно и не имеют доступа к внешнему миру — очень нужная фича, и позиционируется как средство для расширения набора команд Редис (которые атомарны), для которого будет автоматически поддержана репликация.

              > показало, что применительно к индексам Hash и Tree Tarantool опережает Redis при всех типах нагрузок.
              Вообще-то на больших перцентилях задержка у редиса лучше. Это значит, что у тарантула есть какие-то очень редкие, но плохие выбросы.
                0

                Денис, по поводу Reindexer что скажешь?

                  0
                  Не слышал. Гугл показывать только гитхаб. Исходники читать лень :) Там что-то интересное должно быть?
                    0

                    Зачем исходники, вот статья целая была https://habrahabr.ru/post/346884/ :)

                      0

                      А что с комьюнити у Reindexer. Просто сделать что-то своё, оставив только себе же нужное, пробовали многие, но потом все равно добавляется то, что нужно людям, и без поддержки со стороны сообщества (как идейной, так и технической) редкий автор оригинальной разработки не забрасывает ее поддержку "для людей".

                        0

                        Я сочуствующий комьюнист если что:)

                          0
                          Дайте ссылку на телеграм-чат коммьюнити (или слак или еще куда-то)
                            0

                            Мне тоже:)

                              0

                              Не завели еще таких. Но скоро заведем — под какой нибуть подходящий инфоповод :)

                    +2
                    Редис хорош тем, что установил — и можешь работать без шаманства.
                    Tarantul, как обычную базу, нужно конфигурировать — создавать таблицы, писать скрипты
                      0
                      Nobody is perfect
                      0
                      PHP умеет с ним работать?
                        0
                        Да, конечно — официальный драйвер — github.com/tarantool/tarantool-php
                        На хабре было — habrahabr.ru/post/122054
                        И есть на чистом РНР — github.com/tarantool-php/client
                          0
                          Обратите внимание на объектную обёртку — можно описывать схему данных, работать с базой в стиле ООП, есть поддержка миграций, синхронизация хранимок с исходным кодом и многое другое.
                          Например, можно просто писать классы, через аннотации указывать типы и связи сущностей.
                          Про эту фичу можно посмотреть в ридми: github.com/tarantool-php/mapper#annotation-plugin
                          0
                          Одна из интересных фич сервера приложений Tarantool — возможность взаимодействовать с другими, более медленными базами данных с целью кеширования информации, хранящейся в них, и тем самым ускорять их работу: это относится к Oracle, IBM DB2, MySQL, MS SQL Server и PostgreSQL.

                          В Tarantool эта проблема решается с помощью «умного» кеширования: обновление завершится только после успешного обновления сопряжённой БД. То есть вместо взаимодействия с двумя уровнями приложение взаимодействует только с Tarantool, который отвечает за обновление сопряжённой БД.

                          А можно подробнее об этом кейсе? Вот есть приложение на PHP с MySQL в качестве основного хранилища и Redis в качестве кеша. В приложении порядка 10000 разных SQL-запросов по сотне таблиц, треть из них — это чистый CRUD сущностей для бизнес-логики выбором по id и связями (джойнами) по ним же, треть — UI запросы (фильтры, сортировки, поиск по разнообразным критериям), а треть — аналитика. Основное использование Redis — кеш для CRUD операций и базовых UI-запросов по обычной схеме: для селект-запросов по id проверили запись в кеше, если есть отдали её, если нет, полезли в базу. По CUD — просто очистка кеша в основном по успешному выполнению запросов.


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


                          Как видится, Tarantool мог бы помочь в качестве умного кеша хотя бы для CRUD (UI и аналитику почти всегда можно на реплики пускать), но каков будет объём работы примерно? Перенести ~3000 запросов из приложения куда-то в Tarantool с обвязкой в несколько строк Lua, а на их месте написать ~3000 запросов на языке запросов Tarantool (или каких-то RPC сервера, типа как ISAM работала)?

                            0
                            Давайте мы оценим этот объем. Можете прислать детальное описание? Лучше на email — anikin@corp.mail.ru
                            +1
                            Неплохая статья
                              –1
                              Из всех in-memory дб лучше переменная массива или объекта на том языке на котором пишешь, быстрее в 2-5 раз любой другой, простата и независимость точно, с остальными да если нужно масштабирование луче юзать готовые решения.
                                +2
                                Вопросы проблем с простатой на этом ресурсе, наверное, не рассматриваются )

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое