innodb: All content on NoSQL databases and projects about innodb, featuring the best daily NoSQL articles, news, and links on innodb

Tuesday, 15 June 2010

Details About Riak Innostore and Bitcask Backends ☞

by Alex Popescu
Keywords: riak,innodb,bitcask,NoSQL, NoSQL databases, NoSQL community, the definitive guide to NoSQL

Twitter Reddit

With the recent release 0.11.0 Riak switched the default backend storage from using embedded Innostore to Bitcask.

Andy Gross and johne had a very interesting conversation about the differences between Innostore and Bitcask Riak backend stores:

innostore currently creates a file per bucket/partition combo but all other backends use one file per partition unless you really want innostore, we recommend you use bitcask one other thing with buckets: buckets dont consume any resources as long as they use the bucket defaults - either the stock riak defaults or ones you set in your app.config buckets that change some of those defaults take up a small amount of space in the ring data structure that’s gossiped around

Details About Riak Innostore and Bitcask Backends originally posted on the NoSQL blog: myNoSQL

Wednesday, 24 February 2010

NoSQL and RDBMS: Learn from Others’ Experience

by Alex Popescu
Keywords: benchmark,innodb,mysql,nosql debate,riak,NoSQL, NoSQL databases, NoSQL community, the definitive guide to NoSQL

Twitter Reddit
2 likes

I firstly thought that Innostore[1], the embedded InnoDB from Basho, is just another cool project they’ve made available to the community. It was only after a couple of days that I realized that Innostore is in fact one option for the pluggable Riak backend storage engines. That definitely made me think more about this decision.

Luckily enough, David Smith from Basho has already took the time to explain ☞ the reasons that brought Riak to use InnoDB as one of its storage engines:

1. predictability and 2. stability. […] we need something that is going to have predictable latency under significant loads. After evaluating TokyoCabinent (TC), BerkeleyDB-C (BDB) and Embedded Inno, it was quite clear that Inno won this aspect hands down.

You’ll notice pretty much the same arguments in this post about ☞ MySQL usage at Flickr:

  • it is a very well known component. When you’re scaling a complex app everything that can go wrong, will. Anything which cuts down on your debugging time is gold. All of MySQL’s flags and stats can be a bit overwhelming at times, but they’ve accumulated over time to solve real problems.
  • it’s pretty darn fast and stable. Speed is usually one of the key appeals of the new NoSQL architectures, but MySQL isn’t exactly slow (if you’re doing it right). I’ve seen two large, commercial “NoSQL” services flounder, stall and eventually get rewritten on top of MySQL. (and you’ve used services backed by both of them)

As a side note, that last sentence reminded me of the migration Hashrocket team has completed for a pharma company.

Last, but not least, you can also take a look at this ☞ Yahoo! benchmark that includes MySQL and, if I’m not misinterpreting those results, you’ll notice that for some of them MySQL performed quite well.

I guess what we can learn from all these is:

  • not all traditional storage engines are as bad as we sometimes want to think of them
  • it is probably the complete feature set of the RDBMS that are making them overkill for some projects
  • there are still a lot of scenarios in which an RDBMS makes sense

Strange post for a NoSQL centric blog, isn’t it?

References