Comments 16
Не удивительно, ведь расчеты-то у них по формуле: 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.
Что определенно наводит на мысль, что если бы вы писали свечки реалтайм и засуммировали общее затраченное время на запись у Монги и у Токи, то результат был бы в пользу последней и немаленький.
А на чтение времени больше — так это распаковка, наверное. Но я и не нашел у них на сайте, чтобы они обещали быстрое чтение. За счет лишь большей вместимости кеша, тока если. Исправьте, если ошибаюсь.
А вообще, разница-то, изнутря у них вот в чем:
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.
Что определенно наводит на мысль, что если бы вы писали свечки реалтайм и засуммировали общее затраченное время на запись у Монги и у Токи, то результат был бы в пользу последней и немаленький.
А на чтение времени больше — так это распаковка, наверное. Но я и не нашел у них на сайте, чтобы они обещали быстрое чтение. За счет лишь большей вместимости кеша, тока если. Исправьте, если ошибаюсь.
да у них там это через слово, практически. Все три пункта из www.tokutek.com/mongodb-performance/
И это вполне могло бы быть правдой и в том числе из-за меньшего обьема данных которые надо читать, из за организции их индекса и прочего. Хотя они мудро не приводят бенчамрков на чтение. На редите один чувак тоже спросил «а что так медленно доступ на чтение работает» и они не соглсились даже с тем, что может быть медленне на 10-20%. А тут в разы.
Кстати, выше по тексту я четко показал прирост в скорости записи. Не очень поимаю, почему бы вдруг если бы я это писал в реалтайм, то была бы ощутимая разница с тем, как я писал в тесте. Вообще «результат был бы в пользу последней и немаленький» в рассматриваемом случае это сферический конь в ваукуме. Не надо их писать быстрее чем они приходят и (в случае свечек) чаще чем раз в минуту. А то что надо писать, пишится с достаточной скоростью и в монгу. Ну и кроме того лок базы (у монги при записи) не факт, что хуже чем значительно большая нагрузка на cpu у току, с практической точки зрения.
И это вполне могло бы быть правдой и в том числе из-за меньшего обьема данных которые надо читать, из за организции их индекса и прочего. Хотя они мудро не приводят бенчамрков на чтение. На редите один чувак тоже спросил «а что так медленно доступ на чтение работает» и они не соглсились даже с тем, что может быть медленне на 10-20%. А тут в разы.
Кстати, выше по тексту я четко показал прирост в скорости записи. Не очень поимаю, почему бы вдруг если бы я это писал в реалтайм, то была бы ощутимая разница с тем, как я писал в тесте. Вообще «результат был бы в пользу последней и немаленький» в рассматриваемом случае это сферический конь в ваукуме. Не надо их писать быстрее чем они приходят и (в случае свечек) чаще чем раз в минуту. А то что надо писать, пишится с достаточной скоростью и в монгу. Ну и кроме того лок базы (у монги при записи) не факт, что хуже чем значительно большая нагрузка на cpu у току, с практической точки зрения.
Кому-то может быть интересно. Я пишу огромную кучу счетчиков в реальном времени в монгу, а вот графики по ним смотрю очень редко — кажется это мой случай. Хотя все равно разница не такая огромная чтобы переходить на непонятный продукт. С монгой-то что случится — не так много информации, а уж тут вообще будет «сушите весла».
У нас немного другая нагрузка, но результат тестирования схожий. Еще много проблем с индексами, строятся гораздо медленнее, и пару раз попадали на segfaults при их постройке. При подаче багрепорта, ответили только через неделю…
В общем очень сыро, и с поддержкой пока не очень.
В общем очень сыро, и с поддержкой пока не очень.
где монго обгоняет tokumx в полтора — три раза, неизменно воспроизводилась.Возможно Tokumx уперся в CPU (распаковка)
Вообще посмотрев на их результаты, видно что скорость записи (в мб/с) при Tokumx — ниже, но при пересчете на кол-во операций — выше, за счет сжатия. Т.е. они (в основном) выигрывают из-за экономии на io. Особенно хорошо будут сжиматься логи и т.п., там и будет большой выигрыш.
Но сжимать данные можно и без Tokumx, я в одном из проектов для теста сделал обертку которая сжимает все текстовые поля с пом. zlib, в результате база ужалась в 2 раза и естественно скорость возросла.
Я тоже должен признать, что TokuDB не соответствует заявленной производительности. TokuDB был использован как замена TokuDB для достаточно средней базы Zabbix, объём до 200GB. Так вот, все старания консультантов TokuDB ни к чему не привели. Скорость работы была абсолютно неприемлемой. В итоге клиент перешёл на MySQL с InnoDB и остался очень доволен.
Возможно, что TokuDB рассчитан на определённый шаблон использования, не знаю.
Возможно, что TokuDB рассчитан на определённый шаблон использования, не знаю.
На MongoDB meetup в Яндексе, который в марте был, Asya Kamsky, инженер из MongoDB Inc., довольно нелестно отзывалась о Toku. Говорила, что они (Toku) не слишком хорошо представляют себе, как именно работает монга, и у них есть приличное количество неисследованных краевых случаев. Особенно эти заявления касались шардированных инсталляций.
Похоже все продукты 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.»
В общем, лучше пусть будет чуть медленнее, чем ловить месяцами непонятные косяки с потерями данных, падениями базы, зависаниями, нарушениями консистентности и прочими сюрпризами «супер-быстрых» решений.
«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.»
В общем, лучше пусть будет чуть медленнее, чем ловить месяцами непонятные косяки с потерями данных, падениями базы, зависаниями, нарушениями консистентности и прочими сюрпризами «супер-быстрых» решений.
Большое спасибо автору за сравнительный анализ. К сожалению автор не рассказал про сам движок. TokyTM, как и TokuDb используют технологию Фрактальных индексов, которые более эффективны на больших объемах, чем простые деревья (RB & BTree ), на основе которых построенны индексы MongoDb & InnoDb
пугающе тихое обрезание ответа тоже не радуетЯ так думаю, что это обрезание — баг; стало быть, о нём надо бы сообщить разработчикам.
Вы сообщили?
В 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 видеть не будут.
> 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 видеть не будут.
Sign up to leave a comment.
Тестирование «быстрой MongoDB» – TokuMX в условиях, близких к реальности