September 27, 2007

Database management system architecture implications of an eventual move to solid-state memory

I’ve pointed out in the past that solid-state/Flash memory could be a good alternative to hard disks in PCs and enterprise systems alike. Well, when that happy day arrives, what will be some of the implications for database management software architecture?

The last point is tricky, and indeed I’ve gotten it wrong a couple of times since I first thought of writing this post a couple of days ago. In most DBMS, there’s one update when data is updated; it just gets changed in place. In some, however, such as Illustra long ago and Netezza today, there are two — a small update to a “DeleteID” for the old version, to tell the software to disregard it, plus the creation of a new row. I’ve variously thought that this scheme would significantly reduce or significantly increase updates, but neither conclusion holds water. Rather, to a first approximation, there’s almost no effect at all. (Except for the overhead of the two date columns for CreateID and DeleteID.)

Rather, the things you need to do to keep from wearing out your solid-state disk-replacements will be more like:

Hmm. Maybe those sequential, index-light architectures will have value in the solid-state era after all.

Finally, to point out the obvious — the considerations above, in identical or similar form, apply to nonrelational data management systems just as they do to relational engines.

Comments

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.