MySQL: Кто-нибудь использовал движок хранения TokuDB?

Question

Кто-нибудь использовал TokuDB storage engine для MySQL?

Веб-сайт продукта утверждает, что он имеет 50-кратное увеличение производительности по сравнению с другими системами хранения MySQL (например, Innodb, MyISAM и т. Д.). Ниже приведены требования к характеристикам http://tokutek.com/downloads/tokudb-performance-brief.pdf

Это правда?

Любые личные впечатления от использования этого механизма хранения данных в MySQL?

Answer 1

У меня такой же вопрос. Я нашел довольно приличное сравнение TokuDB против Innodb

http://www.pythian.com/news/5139/testing-tokudb-faster-and-smaller-for-large-tables/

Однако, я заинтересован в каких-либо других событиях, которые другие, возможно, имели с TokuDB или любым другим подобным механизмом хранения данных для MySQL.

Другой обзор здесь http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/

Answer 2

При хранении капли, такие как изображения, не используйте tokudb. Он имеет меньший размер размера строки.

Если у вас есть данные более 100 миллионов строк, используйте tokudb.

Если вы чувствительны к скорости UPDATE, не используйте tokudb. Он имеет очень быструю вставку, но по сравнению с innodb, более медленную скорость UPDATE и особенно если вы используете инструкции INSERT ON DUPLICATE.

Если вы храните записи журнала, используйте tokudb.

Если вы хотите уменьшить использование данных myisam/innnodb более чем на 5 раз, используйте tokudb. Я лично подтвердил, что их фрактальное дерево + компрессионная база данных чрезвычайно эффективна в пространстве.

Правило большого пальца, используйте лучший инструмент для работы. Токудб ударяет innodb и myisam из воды в определенных ситуациях, но не является общим двигателем замены db для всего, что находится под небом.

Answer 3

Хотя TokuDB медленнее на UPDATE, как указано выше, он очень быстро работает на REPLACE. Обычно вы можете заменить UPDATE на REPLACE INTO. Я использую TokuDB для таблиц размером до 18 миллиардов строк, и ничего больше не приближается, это по крайней мере в 100 раз быстрее, чем innodb для случайных вставок на больших таблицах.