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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

Ответ 3

У меня такой же вопрос. Я нашел довольно приличное сравнение 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/