3 ms·
For our workload (discussion forum, custom engine) the move to TokuDB was so effective that we ended up completely eliminating a number of front-end caching sta
by sjwright 11y ago
For our workload (discussion forum, custom engine) the move to TokuDB was so effective that we ended up completely eliminating a number of front-end caching stages, because rendering the page from scratch every time ended up being very nearly as fast as pulling from the cache.
(The hot path was a single well-optimised query that retrieved all content for the page. The query didn't need to change.)
- mooreds 11y agoWow, that's a great datapoint.
- sjwright 11y agoTo be more precise, the cache was still faster than building on the fly, but given the quantity of content we were dealing with, the cache was a resource hog. Were it not for TokuDB our next move probably would have been to deploy a dedicated cache server with huge amounts of RAM. As it stands now, this content is now being handled by a single (and quite unremarkable) MariaDB slave and assembled on-the-fly like any other web page. For anyone dealing with gigabytes of text content, I highly recommend giving it a go. You don't even need to screw with your master, just change the table type on the slave.
- Jgrubb 11y agoHey if you're still paying attention to this thread I'd love to pick your brain about this topic. contact in my profile if you don't mind. Thanks.