NoSQL Zone is brought to you in partnership with:

Eric is the Editorial Manager at DZone, Inc. Feel free to contact him at egenesky@dzone.com Eric has posted 804 posts at DZone. You can read more from them at their website. View Full User Profile

A Performance Comparison of LevelDB and MySQL

02.14.2012
| 6577 views |
  • submit to reddit

In January, Google released LevelDB, "a fast and lightweight key/value database library."  In a recent post on the "High Availability MySQL" blog has generated a discussion around the possibility of LevelDB being a storage engine for MySQL due to its performance benefits.  The discussion generated some insight LevelDB's comparative performance to MySQL.  

The LevelDB site provides some insight into these performance benefits.  When creating a brand new database, various methods shows a range of speeds from .4 MB/s to 62.7 MB/s in Write performance.  In Read performance, LevelDB ranged from 152 MB/s to 232 MB/s.  You can see a more detailed explanation of these benchmarks by checking out the LewisDB site here.  

The "High Availability MySQL" blog also suggests that LevelDB may be a "great fit" for MongoDB because it does not require multi-statement transactions.  Commenters pointed out a few more details about LevelDB that may limit its performance:

Unfortunately, there is a trade off between number of SST files and query latency variation: the larger single storage file is - the more time will require to compact it -- Vladmir Rodionov


A recent GitHub post also compared MySQL and LevelDB.  For sequential insert performance, LevelDB was found to get higher throughput/lower latency overall, although MySQL was more stable.



For both average latency and update performance, MySQL and LevelDB performed essentially the same.




Have you had a chance to use LevelDB? How does it compare to other libraries?  Please post your comments below.  

Published at DZone with permission of its author, Eric Genesky.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)