On the article One size fits all: A concept whose time has come and gone, Stonebraker comments that in the past some RDBMSs advocated the idea of a single solution to solve all database management needs.
He further points out that data management needs have grown since the inception of the technology in the 1970’s. Database systems started off focusing on OLTP, that is, transaction (i.e. particularly update) intensive applications, moved to OLAP, which is analytical, that is, read-intensive in nature, and hasn’t stopped since. Other interesting examples of new application areas related to data management are stream processing, web search and indexing, XML management, and local and distributed caches.
Today, database systems are often taught in computer science courses, to the point that it is common to sub-divide its study into separate functional areas, such as:
- Query compiler
- Query optimizer
- Transaction manager
- Concurrency manager
- Index manager
- Buffer (Memory) manager
- Storage manager
- Logging and recovery manager
Consider a DBMS system that is implemented by the modularization of each one of these functional areas, for example, which could be done by composing each functional area as a separate OSGi bundle.
This DBMS system could then be easily configured for different database management needs. Let’s revisit the application areas mentioned previously, and see how modularization could help us achieve them:
- Stream processing: extend the query compiler and optimizer to handle stream-based algebra; drop transaction, and storage manager, as there are no atomicity nor durability across events.
- Web search: use index manager based upon inverse lookups instead of B-trees.
- Distributed cache: distribute the logging and recovery manager.
A World of Events 