innodb: All content tagged as innodb in NoSQL databases and polyglot persistence
As you probably already know, in MySQL 5.7.3 release, InnoDB Memcached reached a record of over 1 million QPS on a read only load. The overview of the benchmark and testing results can be seen in an earlier blog by Dimitri. In this blog, I will spend sometime on the detail changes we have made to achieve this number.
There’s another post detailing the benchmark:
The test was executed in “standalone” mode (both server and client are running on the same server). So, we used our biggest HW box we have in the LAB - a 48cores machine.
That’s a_good_ number. But if you think about it, the per-core QPS is not that high; if I remember correctly Redis can go up to 70k/s.
Original title and link: InnoDB Memcached plugin benchmark: 1mil QPS with in MySQL 5.7.3 ( ©myNoSQL)
I have heard many mentioning that Oracle removed InnoDB from the MySQL classical edition version. Now, I don’t know too much about the various versions and licenses of MySQL — it looks like there are at least 5: enterprise, classical, standard, cluster carrier grade, and community — but InnoDB doesn’t seem to have been dropped from the community edition too. So, I’m not really sure this is such a big deal.
What are your thoughts on this story?
InnoDB is available under the GPL. Innostore, as a derivative work of Embedded InnoDB, is also available under the GPL. Neither Oracle nor Basho can take that away from you.
- If everyone would actually be forced to go back at using MyISAM, that would be a bit more interesting as it would mean MySQL will be less durable and consistent. (↩)
Original title and link: Oracle Drops InnoDB from MySQL Classical Edition, But Not From Community Edition (NoSQL databases © myNoSQL)
I firstly thought that Innostore, 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?