2. Тенденции в области OLTP

Как отмечалось во введении, истоки большинства популярных реляционных СУБД отслеживаются в системах, разработанных в 1970-х гг. В этих СУБД используются дисковые индексные структуры и неупорядоченные файлы, поддерживаются транзакции на основе журнала и блокировочное управление параллелизмом. Однако со времени принятия таких архитектурных решений прошло уже 30 лет. В настоящее время компьютерный мир совсем другой, нежели тогда, когда разрабатывались эти традиционные системы; назначение этого раздела состоит в том, чтобы проанализировать влияние этих изменений. Аналогичные наблюдения описывались в [SMA+07].

2.1 Кластерные вычисления

Почти все СУБД нынешнего поколения были изначально написаны в 1970-х гг. в расчете на мультипроцессоры с общей памятью. В 1980-е гг. многие компании-поставщики добавили в свои системы поддержку архитектур с общими дисками. В последние два десятилетия появились СУБД с архитектурой без общих ресурсов («shared nothing») в стиле Gamma [DGS+90] и кластеры из персональных компьютеров массового класса, позволяющие решать многие масштабные вычислительные задачи. Любая будущая система баз данных, предназначенная для использования на этих кластерах, должна разрабатываться с нуля.

2.2 Базы данных, хранимые в основной памяти

Существенный рост размеров доступной основной памяти в течение последних нескольких десятилетий дает все основания надеяться, что многие базы данных OLTP уже помещаются или скоро будут помещаться в основной памяти, в особенности, в совокупной основной памяти крупного кластера. Это связано, главным образом, с тем, что размер большинства баз данных OLTP растет далеко не так быстро, как объем доступной основной памяти, поскольку число заказчиков, продуктов и других объектов реального мира, информация о которых сохраняется в этих базах данных, не возрастает в темпе, диктуемом законом Мура. С учетом этого наблюдения поставщикам СУБД имеет смысл создавать системы, оптимизируемые в расчете на распространенную ситуацию, когда база данных целиком помещается в основной памяти. В таких системах важно принимать во внимание оптимизацию индексных структур [RR99, RR00], а также остерегаться использования форматов кортежей и страниц, оптимизированных в расчете на использование дисковой памяти [GS92].

2.3 Однопотоковый режим в системах OLTP

Во всех современных СУБД имеется обширная поддержка многопотокового режима, включая набор протоколов транзакционного управления параллелизмом, а также насыщенность кода командами кратковременных блокировок («защелок», latch), обеспечивающими корректность доступа нескольких потоков управления к совместно используемым структурам, таким как буферные пулы и индексные страницы. Традиционные аргументы в пользу многопотокового режима состоят в том, что он позволяет избежать простоя при обработке нескольких транзакций, когда одна или несколько транзакций ждут поступления данных с диска, а также предотвратить торможение длинными транзакциями выполнения коротких транзакций.

Авторы утверждают, что ни один из этих аргументов более не является весомым. Во-первых, если базы данных постоянно находятся в основной памяти, то никогда не возникает потребность в ожидании обменов с диском. Кроме того, производственные транзакционные системы не предполагают какого-либо ожидания действий пользователей – транзакции почти всегда выполняются на основе хранимых процедур. Во-вторых, рабочие нагрузки в системах OLTP являются очень простыми. Типичная транзакция состоит в выполнении нескольких индексных поисков и обновлений, которые в системе баз данных в основной памяти могут быть выполнены за сотни микросекунд. Более того, при разделении современной индустрии баз данных на рынки обработки транзакций и хранилищ данных долговременные (аналитические) запросы теперь обслуживаются системами хранилищам данных.

Одна из проблем состоит в том, что многопотоковый режим требуется для поддержки машин с несколькими процессорами. Однако авторы полагают, что эту проблему можно решить путем трактовки одного физического узла с несколькими процессорами как нескольких узлов кластера без совместно используемых ресурсов, возможно, управляемого монитором виртуальной машины, которая динамически распределяет ресурсы между этими логическими узлами [BDR97].

Еще одной проблемой является то, что сети становятся новыми дисками, привнося задержки в распределенные транзакции и требуя повторного выполнения транзакций. Безусловно, это верно в общем случае, но для многих транзакционных приложений можно разделить рабочую нагрузку таким образом, чтобы она стала «одноузловой» («single-sited») [Hel07, SMA+07], и каждая транзакция могла полностью выполняться в одном узле кластера.

Следовательно, в некоторых классах приложений баз данных не требуется поддержка многопотокового режима. В таких системах унаследованный код для поддержки блокировок и защелок становится неоправданным накладным расходом.

2.4 Высокая доступность в противовес журнализации

Для производственных систем обработки транзакций требуется доступность баз данных 24 часа в сутки семь дней в неделю. По этой причине в большинстве систем используется некоторая форма обеспечения высокой доступности, как правило, основанная на наличии двукратной (или большей) избыточности аппаратуры для гарантированного наличия доступной резервной системы в случае отказа.

Последние публикации [LM06] показывают, что, по крайней мере, для систем хранилищ данных можно использовать эти доступные резервные системы при восстановлении. В частности, вместо использования журнала REDO, восстановление может быть произведено путем копирования недостающего состояния из других реплик базы данных. В своей предыдущей статье авторы утверждали, что это можно сделать и для транзакционных систем [SMA+07]. Если это действительно так, то код унаследованных СУБД, предназначенный для восстановления баз данных, также становится неоправданным накладным расходом.

2.5 Варианты транзакций

Хотя для многих систем OLTP, несомненно, требуется транзакционная семантика, в последнее время появились предложения (в частности, из области Internet) по поводу систем управления данными с ослабленной согласованностью. Обычно требуется некоторая форма конечной согласованности [Bre00, DHJ+07] при наличии убежденности в том, что доступность более важна, чем транзакционная семантика. Системы баз данных для таких сред, по всей вероятности, мало нуждаются в механизмах, разработанных для поддержки транзакций (например, журналы, блокировки, двухфазная фиксация и т.д.).

Даже если требуется какая-то форма строгой согласованности, имеется много слегка ослабленных моделей. Например, широкое принятие изоляции на основе мгновенных снимков (не являющейся транзакционной) свидетельствует о том, что пользователи готовы поменять транзакционную семантику на производительность (в этом случае за счет устранения блокировок для чтения).

И, наконец, современные исследования показывают, что имеются ограниченные формы транзакций, для поддержки которых требуется гораздо меньше механизмов, чем для поддержки стандартных транзакций над базами данных. Например, если все транзакции являются «двухфазными» – то есть все операции чтения в них выполняются до первой операции записи, и для них гарантируется отсутствие аварийного окончания после завершения фазы чтения, – то не требуется журнализация UNDO [AMS+07, SMA+07].

2.6 Резюме

Как показывают литература, несколько исследовательских групп, включая Amazon [DHJ+07], HP [AMS+07], NYU [WSA97] и MIT [SMA+07] демонстрируют интерес к построению систем, существенно отличающихся от традиционных СУБД, которые ориентируются на OLTP. В частности, система H-Store [SMA+07], разработанная в MIT, демонстрирует, что устранение всех упомянутых выше характеристик может привести к повышению пропускной способности транзакций на два десятичных порядка. Это наводит на мысль, что какая-либо из этих систем баз данных, вероятно, обеспечит выдающуюся производительность.

Следовательно, как полагают авторы, поставщикам традиционных СУБД следует обдумать возможность производства продуктов с явным образом отключаемыми некоторыми из этих характеристик. С целью помочь этим разработчикам в понимании влияния на производительность разных вариантов систем, которые они могут захотеть построить, авторы приступают к детальному исследованию производительности Shore и созданных ими вариантов этой системы.