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?
- Compression will be even more important. Cost per terabyte of storage will spike up for that storage that is moved from disk to solid-state.
- The sequential-rather-than-random reading strategy of data warehouse appliance makers may become less relevant. The one way to get rid of the disk-speed bottleneck is to get rid of disks.
- DBMS will need to write data as rarely as possible. Solid-state memory tends to wear out if you keep writing over it. Assuming this problem gets better over time (if it doesn’t, this whole discussion is moot) but isn’t totally solved, architectures which have fewer writes are on the whole better.
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:
- Don’t constantly reorganize data.
- Don’t store indices (such as b-trees) that constantly need to be rebalanced.
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