Родственные работы
Накладные расходы блокировок – это хорошо известная проблема даже однопотоковых систем. Харизопулос (Harizopoulos) и др. [9] анализируют поведение однопотокового менеджера хранения данных SHORE [3] при пропуске двух транзакций из тестового набора TPC-C. При пропуске транзакции Payment система тратит 25% времени на выполнение кода, имеющего отношение к блокировкам, а при пропуске транзакции NewOrder – 16%. Мы подтверждаем эти результаты и раскрываем скрытую проблему конкуренции за защелки, которая делает менеджер блокировок узким местом при возрастании уровня аппаратного параллелизма.
Организация параллельной системы баз данных Rdb/VMS [16] оптимизирована в расчете на устранение узкого места при коммуникации узлов. Чтобы сократить стоимость сетевых передач запросов блокировок, в Rdb/VMS логическая блокировка удерживается в том узле, который ее последним использовал, до тех пор, пока этот узел не возвратит ее узлу-владельцу, или пока не поступит запрос от другого узла. Система Cache Fusion [17], используемая в Oracle RAC, позволяет в кластерах с совместно используемыми дисками объединять буферные пулы узлов и сокращать число обращений к совместно используеым дискам. Подобно тому, как это делается в DORA, Cache Fusion не разделяет данные физическим образом, а распределяет логические блоки. Однако ни в Rdb/VMS, ни в Cache Fusion не затрагивается проблема конкуренции. Большое число потоков управления может обращаться в одно и то же время к одним и тем же ресурсам, что приводит к плохой масштабируемости. В DORA обеспечивается обращение к большинству ресурсов только в некотором одном потоке управления.
В традиционной системе потенциально можно было бы добиться наличия функциональных возможностей DORA, если бы в каждом потоке управления, выполняющем некоторую тразакцию, удерживалась монопольная блокировка некоторой области записей. Монопольная блокировка ассоциируется с потоком управления, а не с какой-либо транзакцией, и удерживается для нескольких транзакций.
Для реализации такого поведения можно было бы использовать разделительные ключи (separator key) [8].
Метод спекулятивного наследования блокировок (speculative lock inheritance, SLI) [13] выявляет во время выполнения "ходовые" ("hot") блокировки, и эти блокировки могут удерживаться потоками управления, выполняющими транзакции, для нескольких транзакций. Как и DORA, SLI снижает конкуренцию в менеджере блокировок. Однако этот метод не позволяет существенно сократить другие накладные расходы внутри менеджера блокировок.
Достижения в области технологии виртуальных машин [2] позволяют применять в многоядерных установках системы без совместного использования ресурсов (shared-nothing). В конфигурациях без совместно используемых ресурсов база данных разделяется на физическом уровне, и имеется репликация как команд, так и данных. Для транзакций, затрагивающих несколько разделов, требуется применять распределенные алгоритмы консенсуса. В H-Store [21] подход отказа от совместного использования ресурсов доводится до крайности за счет использования набора однопотоковых серверов, которые последовательно обрабатывают запросы, избегая управления параллелизмом. В то же время Джонс (Jones) и др. [15] исследуют "спекулятивную" схему блокировок для H-Store, которая может применяться для рабочих нагрузок с многораздельными транзакциями. Значительными проблемами систем без совместного использования ресурсов являются сложность координации распределенных транзакций [11, 5] и неустойчивость, вызываемая "скошенными" (skewed) данными или запросами. Архитектура DORA с совместным использованием всех ресурсов менее чуствительна к таким проблемам и может легче адаптироваться к изменениям нагрузки. В приложении мы обсуждаем, в чем выигрывает DORA от возможности совместного использования ресурсов.
У систем баз данных с поэтапной обработкой запросов (staged database system) [10] имеются общие черты с подходом DORA. Такая система расщепляет запросы на несколько запросов, которые могут выполняться параллельно.
Это расщепление ориентируется на операции и рассчитано на использование конвейерного параллелизма. Однако конвейерный параллелизм мало подходит для типичных рабочих нагрузок OLTP. С другой стороны, аналогично системам с поэтапной обработкой запросов, используются возможности разделения работы путем посылки родственных запросов в одну и ту же очередь. В будущих исследованиях мы постараемся изучить возможности межтранзакционных оптимизаций.
В DORA для снижения уровня конкуренции используется внутритранзакционный параллелизм. Внутритранзакционный параллелизм является темой исследований в течение более двух десятилетий (см., например, [7]). Колохэн (Colohan) и др. [4] используются для параллельного выполнения транзакций спекуляцию на уровне потоков управления. Они демонстрируют потенциал внутритранзакционного параллелизма, достигая времени ответа, на 75% меньшего, чем у традиционной системы. Однако спекуляция на уровне потоков управления – это метод, основанный на аппаратуре, и недоступный в сегодняшних аппаратных средствах. Для поддержки механизма DORA требуются только быстрые коммуникации между ядрами, которые уже поддерживаются в аппаратуре многоядерных процессоров.
В современных процессорных ядрах имеется несколько аппаратных контекстов, позволяющих им перемежать выполнение нескольких потоков команд.
