Рис. 1. Классическая архитектура системы баз данных
На рис. 1 показана классическая трехзвенная архитектура построения приложений баз данных. Эта архитектура была впервые применена компанией SAP, и ее варианты по-прежнему широко используются для создания приложений баз данных. Все запросы инициируются пользователями на уровне представления, например, с использованием Web-браузера. Логика приложения программируется на среднем уровне; на среднем же уровне поддерживаются такие функциональные средства, как Web-сервер. Все управление данными производится на низшем уровне с использованием СУБД (например, IBM DB2, Microsoft SQL Server, MySQL, Oracle и т.д.).
Вся прелесть этой архитектуры кроется в том, что она чрезвычайно хорошо приспособлена к требованиям традиционных систем баз данных (табл. 1). Основное требование поддержки согласованности данных поддерживается в нижнем звене, внутри сервера баз данных. Основная цель оптимизации (минимизация времени ответов и максимизация пропускной способности) достигается за счет применения во всех звеньях ряда методов, разработанных за последние четыре десятилетия: кэширование, индексация, разделение данных и многое другое. Кроме того, масштабируемость достигается на двух верхних уровнях: на этих уровнях архитектура с рис. 1 масштабируется почти неограниченно. Однако в нижнем звене масштабируемость является ограниченной.
К сожалению, трехзвенная архитектура с рис. 1 не слишком хорошо подходит для удовлетворения новых требований из табл. 1. Еще более важно то, что эта архитектура является дорогостоящей. Обычно требуются значительные инвестиции в нижнее звено, включающее дорогостоящую (а не дешевую) аппаратуру. Аппаратные средства должны быть расчитаны на поддержку ожидаемой пиковой производительности, которая может на порядки величин превосходить реальную среднюю производительность. В результате громадная часть аппаратных ресурсов тратится впустую, и весьма затруднительно использовать эти простаивающие ресурсы для каких-либо других целей.