3 ms·

Gotta say I'm a big fan of tokudb over innodb myself. Much better performance as tables grow and much much better compression. My own benchmarks: https://wil

Gotta say I'm a big fan of tokudb over innodb myself. Much better performance as tables grow and much much better compression. My own benchmarks: https://williamedwardscoder.tumblr.com/post/160628887798/compressing-mysql-databases https://williamedwardscoder.tumblr.com/post/160628887798/com...

morgo 9y ago
TokuDB uses a write-optimized data structure. A B+tree like InnoDB is more read optimized (although writes scale well while the key pars of the tree are in memory). There will always be use-cases for each.
- willvarfar 9y ago
  I know you are the product manager and gave a line to tow and all, but tokudb really belongs distributed with stock MySQL. It's a basic enabler for a modern revolution in MPP which perhaps Oracle doesn't want to realize.. ;) When tables are small and fit into memory tokudb and innodb are damn close performance-wise. But innodb has crap compression so stops fitting into memory a lot sooner, and innodb performance drops off a cliff when it stops fitting into memory. Whereas tokudb just sails on awesomely. It's easy to have multi-TB tokudb tables. Just a shame that the next jump upwards is forgotten-ware like ShardQuery. MariaDB is doing Spider and Tokudb ...
wolf550e 9y ago
Not everything is a document store. Some people actually have normalized schemas with foreign keys. TokuDB doesn't support foreign keys. Can Fractal Trees technology support the exact same API as B-Trees, only faster? I don't know. I would love to see a comparison when both technologies are at feature parity.
- willvarfar 9y ago
  > Can Fractal Trees technology support the exact same API as B-Trees, only faster? Yeap. That tokudb doesn't support foreign keys is not a data-structure thing, its a feature they cut from the mysql shim that sits on top of the fractal tree library. I've got a list as long as my arm about missing features, features that don't work well together, blatant opportunities that the optimizer misses, etc. In all seriousness, I'd be all over postgres instead if it just had fractal trees ;) Most of the problems are not the engine, they are the (R?)DBMS on top.

morgo 9y ago

TokuDB uses a write-optimized data structure. A B+tree like InnoDB is more read optimized (although writes scale well while the key pars of the tree are in memory). There will always be use-cases for each.

willvarfar 9y ago
I know you are the product manager and gave a line to tow and all, but tokudb really belongs distributed with stock MySQL. It's a basic enabler for a modern revolution in MPP which perhaps Oracle doesn't want to realize.. ;) When tables are small and fit into memory tokudb and innodb are damn close performance-wise. But innodb has crap compression so stops fitting into memory a lot sooner, and innodb performance drops off a cliff when it stops fitting into memory. Whereas tokudb just sails on awesomely. It's easy to have multi-TB tokudb tables. Just a shame that the next jump upwards is forgotten-ware like ShardQuery. MariaDB is doing Spider and Tokudb ...

wolf550e 9y ago

Not everything is a document store. Some people actually have normalized schemas with foreign keys. TokuDB doesn't support foreign keys. Can Fractal Trees technology support the exact same API as B-Trees, only faster? I don't know. I would love to see a comparison when both technologies are at feature parity.

willvarfar 9y ago
> Can Fractal Trees technology support the exact same API as B-Trees, only faster? Yeap. That tokudb doesn't support foreign keys is not a data-structure thing, its a feature they cut from the mysql shim that sits on top of the fractal tree library. I've got a list as long as my arm about missing features, features that don't work well together, blatant opportunities that the optimizer misses, etc. In all seriousness, I'd be all over postgres instead if it just had fractal trees ;) Most of the problems are not the engine, they are the (R?)DBMS on top.