Hi all, My colleagues and I are evaluating Riak as a persistent, replicated K-V store.
I have a fairly simple (and not so scientific) test that reads and writes 5000 objects that are 32K in size. I am particularly interested in squeezing every last bit of performance out of Riak in a very read-heavy environment. I want to avoid hitting disk for reads as much as possible; our entire content set is much larger than could ever be stored in RAM, but preferably hot/active objects will remain resident in memory until various conditions may force them to be evicted. While the content set is quite large, the number of active keys represent a very small portion of the data which could easily fit in RAM. I've been running the same test against Riak given various combinations of backends and access protocols (HTTP vs. PB). My numbers can be seen in this screenshot: http://img824.imageshack.us/img824/3185/riakperformance.png It is quite evident (and perhaps obvious) that Protocol Buffer performance is noticeably better than HTTP in most cases. What is confusing to me is the performance of purely in-memory backends. Notably, GB Trees and LRU Cache (and even Innostore), at best took 14s to retrieve 5000 32K objects. The exact same test against Membase took just 6s. Perhaps I'm not comparing apples to apples (Riak in-memory versus Membase). Do my tests look reasonable and do the numbers look roughly in-line with expectations? Is there any way to squeeze more juice out of Riak? A purely in-memory/non-persistent backend will not suffice for our ultimate needs, but for testing purposes I'm just trying to see if I can get read performance more in line with what we're seeing with Membase. We love everything about it, but we haven't yet hit the performance we were hoping for. Thanks in advance! - Matt _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
