Mostly is good:

RDS is pretty awesome — it’s basically a highly available MySQL setup with backups and optional goodness like read-slaves. RDS is one of the best services as far as Amazon Webservices are concerned: 90% of what anyone would need from RDS, Amazon allows you to do with a couple clicks.

but:

Aside from the monitoring and backup quirks, one of the real pain points of Amazon RDS is that a lot of the collective MySQL knowledge is not available to us. The knowledge which is manifested in books, blogs, various monitoring solutions and outstanding tools like Percona’s backup tools are not available to people who run Amazon RDS setups.

Most of the time is difficult to get access to your preferred tools from small service providers. Amazon cannot afford to include in their operations all available tools for MySQL. But I’m pretty sure they have a prioritized list of the most requested ones.

Original title and link: Amazon RDS: The Good and Bad of Hosted MySQL (NoSQL database©myNoSQL)

via: http://till.klampaeckel.de/blog/archives/179-Hosted-MySQL-Amazon-RDS-and-backups.html

Just whetting your apetite for this interview with Mark Callaghan about MySQL, InnoDB, and his work at Facebook:

Q: How do you make MySQL both “less slow” and “faster” at the same time?

A: I ask questions like, “If I can make it do 10 things per second today, can I make it do 20 things per second tomorrow?” For example, we used to use an algorithm that is very CPU intensive to check database pages. Another person on my team, Ryan Mack, modified it to use hardware support on X86 processors so we could profile the servers in production to see what they were doing in these computing checksums.  We then realized that the newest CPUs had a faster way to do that, so we modified the MySQL to use the CRC32 for checksums. The hard part there was upgrading the servers on the fly from using the old check zones to the new checksums without taking the site down.

Exciting and scary.

Original title and link: A Story of MySQL and InnoDB at Facebook Told by Mark Callaghan (NoSQL database©myNoSQL)

via: https://www.facebook.com/notes/facebook-engineering/mysql-and-database-engineering-mark-callaghan/10150599729938920

Mario Beck:

But the memcached plugin to MySQL is a replacement or addition to the SQL interface to MySQL. So instead of using SQL queries in your application to persist or retrieve data from MySQL you can use the memcached interface. And what are the benefits?

• Much higher performance (nb: reduced latency, higher throughput) Easier scalability via sharding Simpler application coding

Plus Baron Schwartz’s cogent addition:

I think a huge benefit you’re discussing, but not naming separately, is consistently. With memcached, you have two copies of the data, and the man with two watches never knows what time it is. With a memcached interface to MySQL, you have only one copy — and it is consistent. This is a huge win.

Original title and link: The Benefits of the MySQL Memcached Plugin (NoSQL database©myNoSQL)

via: http://mablomy.blogspot.com/2012/03/why-should-i-consider-memcached-plugin.html

Matt Thompson‘s Induction is a free OS X application allowing access and visualization of data stored in PostgreSQL, MySQL, SQLite, Redis, and soon MongoDB.

Some are asking for a common NoSQL query language, some are trying to put a tabular format on top of NoSQL data, and some are building an indirection layer as a tool.

Original title and link: Induction: SQL? NoSQL? Explore, Query, Visualize (NoSQL database©myNoSQL)

via: http://inductionapp.com/

Maggie Nelson:

Here are a couple of examples of using MySQL in interesting (and it’s up to you whether unwise) ways:

• MySQL as a graph database, like Twitter’s FlockDB.
• MySQL as document store, like FriendFeed’s extremely custom schema design.
• MySQL as a key/value store. This lets you play with NoSQL concepts using MySQL.

Such examples abound. In fact most of the companies known for their contributions or using NoSQL databases run some sort of interesting relational database deployment. Most of the time these examples are interpreted as clear proof that relational databases can solve any problem. Reality is different though: the engineers’ long time familiarity with relational databases allowed them to ingeniously overpass their limitations when lacking better alternatives. But with NoSQL databases getting more mature every day, less and less problems require acrobatic usages of relational databases.

Original title and link: Examples of Using MySQL in Interesting Ways (NoSQL database©myNoSQL)

via: http://phpadvent.org/2011/out-with-the-old-by-maggie-nelson

Dave Engberg has published on the Evernote Techblog a post explaining why the Atomicity, Consistency, and Durability characteristics of a single replicated MySQL/InnoDB deployment are essential to the way Evernote operates.

While it’s difficult to argue about a technical decision with so little details available, I still wanted to point out a couple of things:

1. Atomicity: most of the NoSQL databases offer atomic operation at the level of a single record. For distributed systems that do not want to rely on 2PC, it is the multi-row atomic operations that are not supported.

   The example presented in the post does not require multi-row transactions, but rather guaranteed client operation ordering. This is achievable in most NoSQL databases.

2. Consistency: the post talks about data consistency from the perspective of data integrity guarantees through usage of foreign keys.

   In the world of NoSQL similar behavior could be achieved by different data modeling solutions. Using Cassandra as an example for the notebook deletion scenario, one could store all the notes of a notebook in a single Cassandra row, thus making the delete operation safe.

   It’s also worth mentioning that many of the eventually consistent NoSQL databases offer different consistent read and write operations.

3. Durability: with just a few known exceptions, most NoSQL databases offer strong durability guarantees.
   

In conclusion, based only on the few details of the post, one could easily argument that a NoSQL database would fit the bill. But most of the time the reality behind is much different, making technical decisions a tad more complicated.

Original title and link: WhySQL: MySQL/InnoDB ACID Guarantees for Evernote (NoSQL database©myNoSQL)

via: http://blog.evernote.com/tech/2012/02/23/whysql/

Itamar Haber over the Xeround blog:

Q: Is Xeround Inconsistent? Xeround employs a set of majority-based algorithms to facilitate its reading and writing of data from/to multiple, distributed nodes. […] Via the use of these algorithms we are ensured that all access to the data is consistent so inconsistency is not an issue.

Q: Is Xeround Unavailable? There is no single point of failure in Xeround and every component that the system consists of is redundant and replaceable.

Q: Is Xeround Partitioning-Intolerant? Yes, to a certain extent it is.

After reading it, I got the same impression as VoltDB’s John Hugg who commented:

It sounds like you’ve gotten this backwards. According to you, in the face of a network event, the system becomes unavailable, but remains consistent. I think you have partition tolerance, but with reduced availability.

Instead of focusing strictly on the CAP characteristics of a distributed database, one should focus on what is the required behavior for their system and look for the database solution that offers them the guarantees they need.

Original title and link: Where Does Xeround Fit In The CAP Theorem? (NoSQL database©myNoSQL)

via: http://xeround.com/blog/2012/01/xeround-and-the-cap-theorem

Jelastic, a company offering a cloud platform for Java server hosting, has published some stats about the databases used by their over 7000 users:

While it would be wrong to generalize these results to absolute database marketshare, it is interesting nonetheless to see that MongoDB is already outrunning PostrgeSQL being the second most used database and that CouchDB, which was added only one month ago, is already used by 5% of Jelastic’s users. MySQL detains the first position with over 40% users or differently put double the number of the second place (MongoDB).

These numbers would be even more interesting if they would account for some real usage stats like database sizes or query volumes.

Mat Keep

Original title and link: Jelastic Database Marketshare: MySQL, MongoDB, MariaDB (NoSQL database©myNoSQL)

via: http://blog.jelastic.com/2012/01/23/database-marketshare-january-2012/

ScaleBase’s Liran Zelkha is making the case for database sharding using a proxy:

First and foremost, since the sharding logic is not embedded inside the application, third party applications can be used, be it MySQL Workbench, MySQL command line interface or any other third party product. This translates to a huge saving in the day-to-day costs of both developers and system administrators.

Compare ScaleBase’s proxy-based sharding:

with MongoDB’s sharding:

Another example would be the Hadoop HDFS NodeName which provides somehow similar functionality.

Original title and link: Database Sharding Using a Proxy (NoSQL database©myNoSQL)

via: http://www.scalebase.com/making-the-case-for-sharding-using-a-database-proxy/