Continuing my look at Tokyo Tyrant/Cabinet and addressing some of the concerns I have seen people have brought up this is post #2.
#2.Â As your data grows doesÂ Tokyo Cabinet slow down?
Yes your performance can degrade. One obvious performance decrease with a larger datasetÂ is you start to increase the likelihood that your data no longer fits into memory.Â This decreases the number of memory operations and trades them for more expensive disk based operations.Â Â Â As fast as any application is, as you read off disk opposed to memory performance is going to drop off substantially.Â One of the more difficult things to test with Tyrant is disk bound performance.Â The FS Cache can make Tyrant seem like small amounts of memory will still make it scream.Â Once your data set is larger then that, people start to claim they hit the performance â€œwallâ€.
In order to help test this I went ahead an mounted the FS with my data files with the sync option which effectively disables the FS cache.Â This should help show the real performance of the hash engine.Â Here performance dips substantially, as expected :
Look at the IO rate:
NoSync:Â 31 MB/s
Sync:Â 3.2 MB/s
As one would expect the IO goes crazy when the drive is mounted with the sync option hitting 99% IO wait.Â The interesting this here is we are actually bottlenecking on writes and not reads.Â You see without the FS cache to buffer the writes when we need to remove data from memory we now have to rely on the internal Tyrant cache and when that is exhausted have to then really write to disk not the FS Cache.Â Now Tyrant starts to take on the same characteristics as your classic DB, the bigger the buffer pool the faster the performance:
Even here the performance drop-off once you exhaust memory is relative.Â The focus here should be the drop off versus other solutions with the same configuration, not the drop off versus a completely cached version.Â In this case ask yourself given similar datasets and similar memory requirements what is the performance?Â Take the above sync test, when I use 256M of memory and run my test with writes going directly to disk I hit 964 TPS, in previous MySQL tests the same setup (256M BP) netted ~160 TPS.Â So 5x improvement all things being equal.Â Of course this is a far drop off from the 13K I was getting when everything was effectively in the file system cache or in memory, but 5x is still a very solid improvement.
Next up is looking at Tyrant’s and Cabinet’s write bottleneck.
Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.
Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below.