Another NoSQL Friendly RDBMS, Plus Some Pros and Cons

Aside from pointing out to ☞ just another NoSQL friendly RDBMS post — ☞ these ☞ two plus the FriendFeed post were written quite a long time ago, I thought it would be interesting to include here what the guys over MySQL Performance blog consider as ☞ good situations for using this technique and its downsides:

Schema-less RDBMS Pros

• If the application really is schema-less and has a lot of optional parameters that do not appear in every record, serializing the data in one column can be a better idea than having many extra columns that are NULL.
• when you update the text/blob, a large percentage of the data is actually modified.
• Another potential pro for this technique is that ALTER TABLE commands are no longer required

Schema-less RDBMS Cons

• the first serious downside is write amplification. If you are constantly making small updates to one piece of data in a very large blob, the effort MySQL has to go to is greatly increased.
• this pattern tends to force you to read/write larger amounts of data at once
• there is a clear loss in functionality. You can no longer easily perform aggregation functions on the data (MIN, MAX, AVG)
• It can become difficult to apply even the simplest constraints on the data
• (a smaller issue) is that data will not be stored in the most efficient form

References

• ☞ A Schema-less Relational Database
• ☞ How FriendFeed uses MySQL to store schema-less data
• Friendly: A NoSQL “Friendly” MySQL in Ruby
• ☞ Use SQL Server as your NoSQL database
• ☞ When should you store serialized objects in the database?