5. Следствия для будущих серверов баз данных OLTP

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

• Во-первых, отказ от любого одного компонента системы оказывает относительно небольшое воздействие на общее повышение производительности. Например, оптимизации, относящиеся к поддержке баз данных в основной памяти, позволили повысить производительность Shore примерно на 30%, что является существенным показателем, но, вероятно, не сможет склонить поставщиков систем баз данных к реинженирингу своих систем. Аналогичный выигрыш можно было бы получить путем устранения всего лишь защелок или перехода в однопотоковому режиму с выполнением рабочей нагрузки по одной транзакции.

• Наиболее существенный выигрыш достигается при применении нескольких оптимизаций. Полностью разгруженная система обеспечивает двадцатикратный выигрыш в производительности над исходным вариантом Shore, и это действительно очень существенно. Следует заметить, что такая система может по-прежнему поддерживать транзакционную семантику, если транзакции выполняются по одной, и восстановление путем копирования состояния из других узлов сети. Однако такая система очень и очень отличается от любой системы, предлагаемой поставщиками в настоящее время.

5.1 Управление параллелизмом

Эксперименты авторов показывают значительный вклад в общие накладные расходы динамических блокировок. Это означает, что большой выигрыш может принести выявление сценариев, таких как коммутативность приложений или поочередная обработка транзакций, для которых позволительно отключить управление параллелизмом. Однако имеется много приложений баз данных, которые недостаточно хорошо соблюдают подобные приличия или не могут работать в режиме выполнения транзакций по одной. В таких случаях интересным вопросом является то, какой из протоколов управления параллелизмом является наилучшим? Двадцать лет назад разные исследователи [KR81, ACL87] выполнили всестороннее имитационное моделирование, которое ясно показало превосходство динамических блокировок над другими методами управления параллелизмом. Однако в этих исследованиях предполагалось хранение баз данных на дисках и наличие соответствующих простоев транзакций в ожидании завершения ввода-вывода, и это, очевидно, существенно влияло на результаты. Было бы крайне желательно заново произвести такие модельные исследования, имея в виду рабочую нагрузку с базами данных в основной памяти. Авторы серьезно подозревают, что превалирующим вариантом будет некоторая разновидность оптимистического управления параллелизмом.

5.2 Поддержка многоядерных процессоров

Возрастающая распространенность многоядерных компьютеров приводит к интересному вопросу: что будут делать с несколькими ядрами будущие серверы баз данных OLTP? Один вариант состоит в параллельном выполнении нескольких транзакций на разных ядрах в одном узле (как это делается сегодня); конечно, такой параллелизм требует использования защелок и приводит к потребности решения многих проблем распределения ресурсов. Эксперименты авторов показывают, что хотя накладные расходы механизма защелок не особенно велики (10% от общего числа циклов процессора в основной транзакции New Order), они остаются препятствием для достижения существенного повышения производительности систем баз данных OLTP. Когда технологии (такие, как транзакционная память [HM93]) эффективного выполнения высоко параллельных программ на многоядерных машинах достигнут зрелости и начнут применяться в продуктах, будет очень интересно проанализировать новые реализации защелок и заново оценить накладные расходы многопотокового режима в системах баз данных OLTP.

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

5.3 Управление репликацией

В традиционных системах баз данных принято поддерживать репликацию на основе схемы «активный-пассивный» путем пересылки журнальной информации. У каждого объекта имеется «активная» первичная копия, к которой, в первую очередь, направляются все изменения. Затем журнал изменений передается по сети в один или несколько «пассивных» резервных узлов. После этого в удаленных базах данных по журналу воспроизводятся изменения, выполненные в первичном узле.

У этой схемы имеется несколько недостатков. Во-первых, если не используется какая-либо разновидность двухфазной фиксации транзакций, то удаленные копии не являются транзакционно согласованными с первичной копией. Следовательно, если чтения должны быть транзакционно согласованными, то они не могут производиться над репликами. Если операции чтения направляются к репликам, то нельзя ничего сказать о точности ответов. Второй недостаток состоит в том то, что обработка отказа не является мгновенной. Следовательно, простои из-за сбоев являются более длительными, чем могли бы быть. В третьих, для поддержания реплик требуется журнал, а эксперименты авторов показывают, что на поддержку журнала уходит около 20% общего числа тактов процессора. Поэтому авторы полагают, что интересно было бы исследовать альтернативы репликации «активный-пассивный», такие как подход «активный-активный».

Основной причиной того, что в прошлом использовалась репликация «активный-пассивный» с пересылкой журнала, является то, что воспроизведение изменений по журналу обходится гораздо дешевле выполнения над репликой логики транзакции. Однако в системе баз данных в основной памяти время выполнения транзакции обычно составляет менее одной миллисекунды, что, вероятно, не намного превышает время, требуемое для воспроизведения изменений по журналу. В этом случае альтернативная архитектура «активный-активный» кажется вполне осмысленной. При этом подходе все реплики являются «активными», и транзакция выполняется синхронно надо всеми репликами. Преимуществом этого подхода является почти мгновенная обработка отказов, и отсутствует требование направления изменений сначала в узел с первичной копией. Конечно, в таком сценарии существенную дополнительную задержку будет порождать двухфазная фиксация, из чего следует потребность в технологии, избегающей использования двухфазной фиксации – возможно, путем выполнения транзакций в порядке временных меток.

5.4 Слабая согласованность

В большинстве крупных Web-ориентированных магазинов для достижения высокой доступности и обеспечения восстановления после аварийных отказов используется репликация баз данных OLTP, обычно в глобальной сетевой среде. Однако, похоже, что никто не собирается платить за транзакционную согласованность в глобальной сети. Как отмечалось в разд. 2, распространенным рефреном в Web-приложениях является «конечная согласованность» [Bre00, DHJ+07]. Обычно сторонники такого подхода выступают за разрешение несогласованности не техническими средствами; например, дешевле предоставить кредит недовольному клиенту, чем поддерживать стопроцентную согласованность. Другими словами, реплики, в конечном счете, становятся согласованными, по-видимому, тогда, когда система переводится в пассивное состояние.

Должно быть понятно, что конечная согласованность невозможна без обеспечения транзакционной согласованности над общей рабочей нагрузкой. Например, предположим, что транзакция 1 фиксируется в узле 1 и аварийно завершается или теряется в узле 2. Транзакция 2 читает результаты транзакции 1 и пишет результаты в базу данных, что приводит к распространению несогласованности и загрязнению системы. При этом, очевидно, должны существовать рабочие нагрузки, для которых конечная согласованность достижима, и было бы интересно попытаться найти такие рабочие нагрузки. Однако, как отмечалось выше, результаты авторов показывают, что удаление поддержки транзакций – блокировок и защелок – из систем баз данных в основной памяти приводит к резкому повышению производительности.

5.5 B-деревья с учетом знаний о поведении кэша

В своих исследованиях авторы не преобразовывали B-деревья Shore в формат, в котором учитывались бы знания о поведении кэша («cache-conscious») [RR99, RR00]. Такая перестройка, по крайней мере, в системе без других оптимизаций, представленных в этой статье, оказала бы только умеренное влияние на производительность. В работах, посвященных этой разновидности B-деревьев, исследуются проблемы отсутствия в кэше данных, требуемых при доступе к значениям ключей, которые хранятся в узлах B-дерева. Оптимизации авторов статей позволяют сократить на 80-88% время выполнения операций над B-деревьями без изменения паттернов доступа к ключам. При переходе от максимально оптимизированной Shore к ядру с минимальными накладными расходами – в котором производится доступ к тем же данным – оставшееся время сокращается еще на две трети. Другими словами, авторы полагают, что более важно оптимизировать другие компоненты, такие как управление параллелизмом и восстановление, чем оптимизировать структуры данных. Однако после минимизации системы до очень простого ядра новым узким местом может стать именно отсутствие данных в кэше при выполнении операций над B-деревом. В действительности, может оказаться, что в этой новой среде лучшую производительность смогут обеспечить другие индексные структуры, такие как хэш-таблицы. Опять же, эту гипотезу требуется тщательно проверить.

6. Родственные исследования

Проводилось несколько исследований узких мест производительности современных систем баз данных. Работы [BMK99] и [ADH+99] показывают, что возрастание объемов доступной основной памяти мало способствует повышению производительности систем баз данных. В [MSA+04] анализируются узкие места, возникающие из-за конкуренции за различные ресурсы (такие как блокировки, синхронизация ввода-вывода или центральный процессор), с точки зрения клиента (что включает воспринимаемые задержки из-за операций ввода-вывода или вытесняющее планирование других параллельно обрабатываемых запросов). В отличие от исследования, представленного в данной статье, авторы упомянутых статей анализируют полные системы баз данных, и не обсуждают их покомпонентную производительность. Исследования на основе тестовых наборов, такие как TPC-B [Ano85] области OLTP или Wisconsin Benchmark [BDT83] в области общей обработки SQL-запросов, также характеризуют производительность полных СУБД, а не их отдельных компонентов.

Кроме того, имеется большое число публикаций, посвященных системам баз данных в основной памяти. В исследованиях индексных структур в основной памяти анализировались AVL trees [AHU74] и T-trees [LC86]. Другие методы применения основной памяти описаны в [BHT87]. К числу полных систем баз данных в основной памяти относятся TimesTen [Tim07], DataBlitz [BBK+98] и MARS [Eic87]. Обзор этой области содержится в [GS92]. Однако ни в одной из этих работ не предпринимались попытки изолировать компоненты накладных расходов, что является основным вкладом данной статьи.

7. Заключение

Авторы выполнили исследование производительности системы Shore для того, чтобы понять, на что тратится время в современных системах баз данных, и попытаться разобраться в том, какой могла бы быть потенциальная производительность нескольких недавно предложенных альтернативных архитектур систем баз данных. Путем удаления компонентов из Shore авторам удалось создать систему, на которой модифицированный тестовый набор TPC-C выполняется почти в 20 раз быстрее, чем на исходной системе (хотя и с существенным сокращением функциональных возможностей!).

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

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

Это говорит о том, что недавние предложения по поводу создания систем баз данных с ограниченными функциональными возможностями [WSA97, SMA+07] могут привести к достаточно интересным результатам.

8. Благодарности

Авторы благодарны рецензентам SIGMOD за их полезные замечания. Это исследование частично поддерживалось грантами Национального научного фонда (National Science Foundation) 0704424 и 0325525.

9. Оценка повторяемости результатов

Все результаты, описанные в этой статье, были проверены комитетом SIGMOD по повторяемости. Код и данные, использованные в статье, доступны на сайте sigmod.org .

Назад Оглавление Вперёд