NoSQL Means Never Having to Store Blobs Again
Morgan Tocker has an awesome article and comment thread in the MySQL Performance Blog about When should you store serialized objects in the database? Before the NoSQL age is was very common to simulate schemalessness by storing blobs in MySQL. Sharding was implemented by running multiple MySQL instances and spreading writes across them. While not ideal for the purpose, developers felt comfortable with MySQL. They knew how to install it, back it up, replicate it, in short: they knew how to make it work. Yet they also needed to store objects without the penalty of joins. Searches and aggregate queries were handled by indexes kept in separate tables, this offloaded the fast path to objects.
This all made perfect sense. Usually we just want stuff to work and going with what you know is often the best path to that goal. And what we have known is MySQL. All the different pros and cons of this approach are covered wonderfully in the post.
But the world has changed. With the same goals in mind I don't think you would try and force MySQL into being a sharded blob store anymore. You would use of the many NoSQL alternatives that would out of the box give you schemalessness, searching, scalability, and reliability. There is still a learning curve, but with all the other benefits putting in the effort has a good ROI.
Many of the past uses of MySQL have moved on and with the buyout of MySQL the future may look very different. It's amazing how fast things change. What NoSQL does not have is universality. Many many packages like Drupal work out of the box with MySQL. Currently there's no similar way to just drop in a NoSQL solution into any project. That might hold wider adoption back a bit.
