Тестирование «быстрой MongoDB» – TokuMX в условиях, близких к реальности

    В последнем выпуске Радио-Т мы упоминали TokuMX — High-Performance MongoDB Distribution. Продукт этот звучит интересно — 9ти кратное сжатие данных в комплекте с 20ти кратным приростом скорости и поддержкой транзакций. При этом переход с mongo на tokumx весьма прост и с точки зрения внешнего наблюдателя — полностью прозрачен. Такое волшебство показалось мне более чем привлекательным и я решил проверить насколько все хорошо на практике.

    Сейчас я использую несколько mongodb систем разного размера, как в AWS так и в частных дата центрах. Мой паттерн использования в основном ориентирован на редкую, но массивную запись данных (раз в день), несколько более частые массивные операции чтения (набор разнообразных анализов) и постоянное чтения в режиме обеспечения данными фронтэнды. Никаких особых проблем с монгой у меня нет, за исключением подступающей (по расчетом через 6 месяцев) проблемы диска. Данные из нашей системы никогда не удаляются и в конце концов перестанут влезать на диски. В AWS монга бежит на относительно дорогих EBS томах с гарантированным IOPS. Я уже планировал конвенциональное решение проблемы отсутствия места на диске (перенос старых данных на отдельную монгу в дешевой конфигурации), но тут попалась на глаза TokuMX с обещанием сжатия в 9 раз, что отложило бы мою проблему на следующие 4 года. Кроме того, откат записи в монге делается только со стороны клиента, и было бы неплохо обойтись без этого, но перенести на уровень сервера.

    Если вам интересно, как именно работает магия TokuMX, то добро пожаловать на их сайт. Здесь я не буду рассказывать что это такое и как его настроить, но поделюсь результатами поверхностного тестирования. Мои тесты не претендуют на научную аккуратность и основной целью имеют показать, что будет в моих реальных системах если перейти с монги на току.

    Прозрачность перехода:

    С этим все прекрасно. Ни в одном из моих тестов, покрывающих работу с монгой (около 200), никаких проблем не возникло. Все, что работало с монгой работает и с току. Интеграционные тесты тоже не выявили никаких проблем, т.е. в моем случае можно перенаправить клиентские системы на адреса TokuMX и они продолжат работу не заметив подмены. Режим гибридной работы монги с току в одном replica set я не тестировал, но подозреваю что и это будет работать.

    Тестирование записи :

    Тесты производились на 2х идентичных виртуальных машинках с 2мя процессорами на каждую, 20G диска и 1G RAM. Хостовый компьютер — MBPR i7, SSD, 16G RAM. Встявляись записи (trade candles) за один день, всего 1.4М свечек. Средний размер записи 270 байт. 3 дополнительных индекса (один простой, 2 композитных).

    image
    Как видим, разница есть и TokuMX реально быстрее. Конечно не в обещанные 20 раз, но тоже неплохо. Хотя при этом и наблюдается значительно большая нагрузка на процессор, но подобное можно ожидать в связи с компрессией.

    Размер данных + индексы в TokuMX тоже оказался меньше, чем у монги, но всего в 1.6 раза.

    Тестирование чтения:

    Чтение тестировалось в режиме близком к реальному использованию. Все быстрые запросы (по тикеру) проводились многократно для случайной выборки из 200 тикеров, всего 10000 запросов, результат усреднялся. Интервальные (по времени) запросы проводились для 10-ти случайных интервалов и тоже многократно. В монгу и току посылались одни и те же запросы в одинаковом порядке. Основная цель этого теста была создать активность, максимально близкую к реальной. Время приведено в микросекундах.

    image
    Не поверив своим глазам, я провел эти тесты многократно и подобный результат (с небольшими флуктуациями) повторялся стабильно. Во всех моих тестах подобная разница, где монго обгоняет tokumx в полтора — три раза, неизменно воспроизводилась.

    Решив, что возможно дело в том, что для TokuMX надо больше CPU, я провел неравный бой где виртуалка с toku с 4мя процессорами соревновалась с монгой на двух. Результат несколько лучше, но все равно монго остается быстрее даже в этих, неравных условиях (разница в среднем в 1.4 раза). Единственный тест, в котором току обошла монгу (почти в 2 раза) это последний — все свечки за день.

    Подумав, как бы все это потестировать еще, я уменьшил объем RAM для обоих конкурсантов, чтоб набор данных не помещался в памяти. Получил вот такие результаты:
    image
    В целом этот результат выглядит еще хуже и разница в 12 раз не вызывает особого оптимизма. Однако первые два теста заметно ближе к монге, и в моем случае общий результат видимо будет сравним, т.к. подобных “улучшенных” запросов у меня многократно больше, чем сильно просевших.

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

    И еще одно — во всех этих тестах была монго “из коробки”. Для TokuMX я сделал послабление в последнем тесте — активировал direct IO и задал размер кэша как рекомендовано у них в руководстве.

    Выводы:
    Мой предварительный вывод такой: то, что TokuMX пишет про себя, а именно “в 20 раз быстрее и в 9 раз компактнее из коробки”, в моем случае не совсем правда. Практически все операции чтения были медленнее (иногда значительно медленнее) в TokuMX и пугающе тихое обрезание ответа тоже не радует. Для меня поддержка транзакций, ускорение записи в 1.4 раза (при этом нет лока на базу, но только на документ) и выигрыш в размере данных в 1.6 раза, не стоят значительного проседания производительности всех операций чтения.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 16
    • +2
      Не удивительно, ведь расчеты-то у них по формуле: best case у нас против worst case у вас = получается 20x раз :)
      А вообще, разница-то, изнутря у них вот в чем:
      From a theoretical perspective, if B is the block-transfer size, the B-tree performs O(log_B N) block transfers per insert in the worst case. In contrast, the Fractal Tree structure performs O((log_B N)/B) memory transfers per insert, which translates to run-time improvements of two orders of magnitude.
      Что определенно наводит на мысль, что если бы вы писали свечки реалтайм и засуммировали общее затраченное время на запись у Монги и у Токи, то результат был бы в пользу последней и немаленький.

      А на чтение времени больше — так это распаковка, наверное. Но я и не нашел у них на сайте, чтобы они обещали быстрое чтение. За счет лишь большей вместимости кеша, тока если. Исправьте, если ошибаюсь.
      • +1
        да у них там это через слово, практически. Все три пункта из www.tokutek.com/mongodb-performance/
        И это вполне могло бы быть правдой и в том числе из-за меньшего обьема данных которые надо читать, из за организции их индекса и прочего. Хотя они мудро не приводят бенчамрков на чтение. На редите один чувак тоже спросил «а что так медленно доступ на чтение работает» и они не соглсились даже с тем, что может быть медленне на 10-20%. А тут в разы.

        Кстати, выше по тексту я четко показал прирост в скорости записи. Не очень поимаю, почему бы вдруг если бы я это писал в реалтайм, то была бы ощутимая разница с тем, как я писал в тесте. Вообще «результат был бы в пользу последней и немаленький» в рассматриваемом случае это сферический конь в ваукуме. Не надо их писать быстрее чем они приходят и (в случае свечек) чаще чем раз в минуту. А то что надо писать, пишится с достаточной скоростью и в монгу. Ну и кроме того лок базы (у монги при записи) не факт, что хуже чем значительно большая нагрузка на cpu у току, с практической точки зрения.
        • 0
          Ну да, свечки — плохой пример. Может где-нибудь где много и часто приходится писать килобайтами, то вот там этот выйгрыш в меньших количествах перемещений памяти вполне может быть оправдан.
          А вам спасибо за статью, а то этот маркетинг и до опенсурса добрался.
      • +2
        Кому-то может быть интересно. Я пишу огромную кучу счетчиков в реальном времени в монгу, а вот графики по ним смотрю очень редко — кажется это мой случай. Хотя все равно разница не такая огромная чтобы переходить на непонятный продукт. С монгой-то что случится — не так много информации, а уж тут вообще будет «сушите весла».
        • +4
          У нас немного другая нагрузка, но результат тестирования схожий. Еще много проблем с индексами, строятся гораздо медленнее, и пару раз попадали на segfaults при их постройке. При подаче багрепорта, ответили только через неделю…

          В общем очень сыро, и с поддержкой пока не очень.
          • +3
            где монго обгоняет tokumx в полтора — три раза, неизменно воспроизводилась.
            Возможно Tokumx уперся в CPU (распаковка)

            Вообще посмотрев на их результаты, видно что скорость записи (в мб/с) при Tokumx — ниже, но при пересчете на кол-во операций — выше, за счет сжатия. Т.е. они (в основном) выигрывают из-за экономии на io. Особенно хорошо будут сжиматься логи и т.п., там и будет большой выигрыш.

            Но сжимать данные можно и без Tokumx, я в одном из проектов для теста сделал обертку которая сжимает все текстовые поля с пом. zlib, в результате база ужалась в 2 раза и естественно скорость возросла.
            • +2
              Я тоже должен признать, что TokuDB не соответствует заявленной производительности. TokuDB был использован как замена TokuDB для достаточно средней базы Zabbix, объём до 200GB. Так вот, все старания консультантов TokuDB ни к чему не привели. Скорость работы была абсолютно неприемлемой. В итоге клиент перешёл на MySQL с InnoDB и остался очень доволен.

              Возможно, что TokuDB рассчитан на определённый шаблон использования, не знаю.
              • 0
                Скажите какие параметры были компрессии? Сколько ядер было в системе? Какое кол-во NVS в zabbix. Какое кол-во inserts, updates в секунду?
              • +2
                На MongoDB meetup в Яндексе, который в марте был, Asya Kamsky, инженер из MongoDB Inc., довольно нелестно отзывалась о Toku. Говорила, что они (Toku) не слишком хорошо представляют себе, как именно работает монга, и у них есть приличное количество неисследованных краевых случаев. Особенно эти заявления касались шардированных инсталляций.
                • +2
                  Похоже все продукты Toku грешат подобным качеством. В TokuDB в «известных проблемах», например, вообще фееричное:

                  «The Fast Loader, a feature introduced in TokuDB v4.0, can, under certain circumstances, cause inconsistencies in the tables and possibly the loss of some data, though in practice we believe most customers will be able to recover 100% of their data. This bug affects TokuDB v4.0, 4.1, and v4.1.1.»

                  В общем, лучше пусть будет чуть медленнее, чем ловить месяцами непонятные косяки с потерями данных, падениями базы, зависаниями, нарушениями консистентности и прочими сюрпризами «супер-быстрых» решений.
                  • 0
                    Большое спасибо автору за сравнительный анализ. К сожалению автор не рассказал про сам движок. TokyTM, как и TokuDb используют технологию Фрактальных индексов, которые более эффективны на больших объемах, чем простые деревья (RB & BTree ), на основе которых построенны индексы MongoDb & InnoDb
                    • 0
                      Пришлось полчаса крутить презентацию туда-сюда, чтобы воскликнуть: «о, так они же просто между родителем и дитем размещают буфер, чтобы уменьшить число дисковых операций в худшем случае»…
                    • 0
                      пугающе тихое обрезание ответа тоже не радует
                      Я так думаю, что это обрезание — баг; стало быть, о нём надо бы сообщить разработчикам.

                      Вы сообщили?
                      • +2
                        лично я не уверен что это баг, но о своих изысканиях приведенных тут, включая и обрыв ответа я им написал.
                      • 0
                        В User’s Guide к TokuMX пишут:

                        > Memory: TokuMX requires at least 1GB of main memory but for best results, we recommend to run with at least 2GB of main memory.

                        Довольно странное решение проводить бенчмарк на минимально допустимом объёме памяти. Было бы интересно посмотреть на результаты аналогичного теста, но с увеличенным на порядок-два объёмом данных и памяти в виртуалках.

                        > Режим гибридной работы монги с току в одном replica set я не тестировал, но подозреваю что и это будет работать.

                        Не будет, там другой протокол репликации. Вы можете использовать mongo2toku для наливания replication stream в tokumx (для более быстрой миграции, например), но клиенты репликасета при этом, естественно, tokumx видеть не будут.
                        • 0
                          Здравый смысл и опыт работы с монгой подсказывают мне, что обьем памяти связан с размером данных+индекса. В моем тесте было памяти в 2 раза больше чем размер этого всего и удовлетворяло их «at least 1GB of main memory». Но любопытсва ради я проведу те же тесты в 4г и допишу, что получил

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