My personal experience is that InnoDB performance drops off a cliff as tables grow and parts of tables stop fitting in RAM. TokuDB just keeps on going.
TokuDB also compresses your data really well.
My own stats: https://williamedwardscoder.tumblr.com/post/160628887798/com...
Yes but at least in my experience as things fit in RAM, InnoDB is still the correct choice.
TokuDB is great once you run out of RAM-related solutions but given the price point RAM is at these days, we are talking 100GB+ tables which probably shouldn't be one a single machine anyway.
If your dataset fits in ram, and when it doesn't you have to buy more boxes with more ram rather than just buying more disk, then I think you are making a very uneconomical trade off.
> If your dataset fits in ram, and when it doesn't you have to buy more boxes with more ram rather than just buying more disk, then I think you are making a very uneconomical trade off.
It is all in what lower latency is worth to the bottom line and how well you scale horizontally.
(Src: have run each, and stuff like shard-query to parallelise queries and scale them out)
The machine isn't even that beefy, 128 GB of RAM, dual mid range Xeons, and prosumer SSDs in RAID 10. I would rather spend money in PCI-E SSDs, 300+ GB of RAM, and high end CPUs if it meant I didn't have to implement sharding at an application level.
You can comfortably handle multi-tera tables on single machines these days. Adding more machines isn't "scaling", its admitting "we can't scale in software so make it a hardware problem"
I think we are ultimately going to switch to PostgresSQL as it has better tooling and features that we need (json, jsonb, postgis) and performance is also good when properly tuned.
This doesn't take away from TokuDB though - which is pretty awesome in any case.