Классика баз данных - статьи
Модульность
Некоторые люди утверждают, что архитектура баз данных нуждается в революции, схожей с RISC-революцией в архитектуре компьютеров. Традиционная монолитная архитектура СУБД не является достаточно гибкой для адаптации к сегодняшним требованиям, поэтому нам требуется создавать средства управления данными из набора небольших, простых, повторно используемых компонентов. Например, вместо того чтобы относиться к SQL как к единственной возможности выбора, Чаудхари и Вейкум утверждают, что возможности запросов должны обеспечиваться на разных уровнях сложности. Можно начать с процессора выборки из одной таблицы, имеющего индекс в виде B+-дерева и поддерживающего простые возможности индексирования, модификации и выборки. Можно добавить к этому процессору средства управления транзакциями. Продолжая подниматься по иерархии сложности, можно перейти к процессору выборки-проецирования-соединения. Потом можно добавить к нему поддержку агрегатов. Таким образом, вы преобразуете SQL из монолитного языка в семейство языков с последовательно увеличивающейся мощностью, причем каждый из этих языков представляется как некоторый компонент, удовлетворяющий потребности достаточно большого числа прикладных областей. Для любого конкретного приложения выбираются те компоненты, которые для него требуются. Эта идея компонентной архитектуры может быть расширена для включения других аспектов архитектуры систем баз данных: управления параллелизмом, транзакций, журнализации и обеспечения высокого уровня доступности.
Подсистему управления параллелизмом можно представить в виде иерархии, похожей на ту, которая обсуждалась в примере с языком запросов. Некоторые приложения являются полностью последовательными, и для них не требуются блокировки; у других приложений имеется низкий уровень параллелизма, и для них достаточно обеспечить блокировки на уровне таблиц или API (т.е. разрешить доступ к системе баз данных только одному изменяющему процессу или нескольким читающим процессам). Наконец, приложения с высоким уровнем параллелизма нуждаются в мелкоструктурных блокировках и нескольких уровнях изоляции (когда у приложений имеется потенциальная возможность видеть значения, записанные незавершенными транзакциями).
