Responding to Monash's recent post on diversity of database systems
This week, Curt Monash published a post titled "Database management system choices - overview" on the DBMS2 blog that makes the argument that in the database world, one size does not fit all. In response, I have one comment and one quibble (read the post in its entirety here).
The comment: Many different kinds of DBMSs
Curt's post leads to the obvious question: Just how many different kinds of viable DBMSs can we expect to see? I can imagine the following:
I expect all of these to be architected differently, with the possible exception of RDF stores, which are efficiently supported on top of column stores and focused on the warehouse market.
The quibble: OLTP demands shared nothing
Every high-end OLTP application is currently requiring 7 x 24 x 365 x 10 years of availability. That is, the database has only one state, which is "up." Hence, high availability -- in the face of crashes as well as disasters -- is a requirement. Disaster recovery requires replication over a wide area network; recovery from crashes, requires LAN-based replication. As such, every OLTP system is, in fact, deployed over a shared-nothing architecture, encompassing both LAN and WAN networking.
The comment: Many different kinds of DBMSs
Curt's post leads to the obvious question: Just how many different kinds of viable DBMSs can we expect to see? I can imagine the following:
- OLTP DBMSs focused on fast, reliable transaction processing
- Analytic/Data Warehouse DBMSs focused on efficient load and ad-hoc query performance
- Science DBMSs -- after all MatLab does not scale to disk-sized arrays
- RDF stores focused on efficiently storing semi-structured data in this format
- XML stores focused on semi-structured data in this format
- Search engines -- the big players all use proprietary engines in this area
- Stream Processing Engines focused on real-time StreamSQL
- "Lean and Mean," less-than-a-database engines focused on doing a small number of things very well (embedded databases are probably in this category)
- MapReduce and Hadoop -- after all Google has enough "throw weight" to define a category
I expect all of these to be architected differently, with the possible exception of RDF stores, which are efficiently supported on top of column stores and focused on the warehouse market.
The quibble: OLTP demands shared nothing
Every high-end OLTP application is currently requiring 7 x 24 x 365 x 10 years of availability. That is, the database has only one state, which is "up." Hence, high availability -- in the face of crashes as well as disasters -- is a requirement. Disaster recovery requires replication over a wide area network; recovery from crashes, requires LAN-based replication. As such, every OLTP system is, in fact, deployed over a shared-nothing architecture, encompassing both LAN and WAN networking.
I think you are missing a major category:
10. Object Databases
Speaking for ourselves (db4o) you would possibly put us into your category (8) right now.
However there is potential for object databases that adjust well to the object-oriented model, that solve concurrency issues at object level, that handle client state and that do the processing where it works best in a distributed system, all object-oriented.
Object Databases are coming back. Some evidence:
http://odbmsjournal.org/icoodb/