2. Архитектурные соображения по поводу СУБД, ориентированных на OLTP

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

2.1 Основная память

В конце 1970-х гг. в больших вычислительных машинах имелось где-то около мегабайта основной памяти. Сегодня распространенным явлением является наличие нескольких гигабайт основной памяти в персональных компьютерах, а в больших машинах объем памяти достигает сотни гигабайт. Через несколько лет не будет редкостью терабайтная основная память. Вполне представима grid-система общей стоимостью менее 50000 долларов, состоящая из 20 узлов без совместно используемых ресурсов, в каждом из которых имеется 32 Гб основной памяти (с возможностью расширения в ближайшем будущем до 100 Гб). По существу, в основной памяти прямо сейчас или в близком будущем можно разместить любую базу данных объемом менее терабайта. Объем подавляющего большинства баз данных OLTP не превосходит одного терабайта, и этот объем возрастает достаточно медленно. Показательным фактом, например, является то, что в тестовой базе данных TPC-C для одной физической оптовой базы (склада) требуется около 100 Мб. В очень крупном торговом предприятии может иметься 1000 складов, для хранения данных которых требуется около 100 Гб памяти, что вполне укладывается в упомянутые выше ограничения для размещения в основной памяти.

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

Однако, хотя на рынке имеется несколько продуктов управления базами данных в основной памяти, таких как TimesTen и SolidDB, и эти системы унаследовали черты System R. К унаследованным чертам относится использование для восстановления журнала, поддерживаемого на дисках, и применение динамических блокировок, что приводит к существенным накладным расходам, снижающим производительность системы.

2.2 Многопотоковость и управление ресурсами

OLTP-транзакции являются очень легковесными. Например, в наиболее тяжелой транзакции из TCP-C считывается около 400 записей. При работе с базами данных в основной памяти полезная работа такой транзакции занимает менее одной миллисекунды даже при использовании низкопроизводительных компьютеров. Кроме того, в большинстве известных авторам статьи средах OLTP отсутствуют «задержки по вине пользователей» («user stall»). Например, когда на сайте Amazon пользователь нажимает на кнопку «buy it», он активизирует OLTP-транзакцию, данные от которой будут возвращены пользователю только после ее завершения. По причине отсутствия дисковых операций и задержек по вине пользователей фактическая продолжительность OLTP-транзакции является минимальной. В таком мире имеет смысл выполнять все команды SQL в рамках последовательных транзакций с использованием однопотоковой модели исполнения, а не тратить время и другие ресурсы на изоляцию параллельно выполняемых операторов.

Современные РСУБД представляют собой тщательно разработанные многопотоковые системы, ориентированные на полное использование ресурсов ЦП и дисков. Это позволяет выполнять в параллель много запросов. Кроме того, в этих системах имеются подсистемы, предназначенные для предотвращения перегрузки системных ресурсов, чтобы не возникла ситуация исчерпания IP-соединений, дескрипторов файлов, основной памяти, требуемой для выполнения сортировок, и т.д. В однопотоковой системе не требуется подсистема регулирования ресурсов.

При использовании однопотоковой модели исполнения не требуются структуры данных, для которых поддерживается параллельный доступ. Поэтому можно полностью обойтись, например, без сложного кода, требуемого для поддержки параллельного доступа к B-деревьям. Это позволяет создавать более надежные системы, обладающие более высокой производительностью.

Может возникнуть вопрос: «А как быть с долго выполняемыми командами?». Ответ состоит в том, что в реальных OLTP-системах таких команд просто нет. Во-первых, операции, которые могли бы привести к долговременно выполняемым транзакциям, такие как ввод данных для покупки в Internet-магазине, обычно расщепляются на несколько транзакций, чтобы время выполнения каждой из них оставалось небольшим. Другими словами, в правильно разработанном OLTP-приложении поддерживаются только короткие транзакции. Во-вторых, долго выполняемые произвольные (ad-hoc) запросы направляются в систему хранилища данных, которая оптимизируется для выполнения именно таких операций. Нет никаких оснований заставлять систему OLTP решать проблемы, не относящиеся к OLTP. Такой подход применяется только в «безразмерном» мире.

2.3 Grid-компьютинг и массивная модернизация (Fork-lift Upgrade)

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

Кроме того, никто не любит массовой модернизации оборудования. Поэтому любая новая система должна проектироваться в расчете на возможность инкрементного расширения аппаратных средств. Если grid-компьютер с N узлами не обеспечивает достаточной мощности, должна быть иметься возможность добавить к нему еще K узлов с получением системы, включающей N+K узлов. Более того, должна иметься возможность выполнения такой модернизации без потребности в каких-либо сложных действиях над используемой СУБД. Это позволит избавить системных администраторов от самого страшного для них ночного кошмара – массивной модернизации аппаратуры с последующей полной перезагрузкой данных и запуском системы заново.

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

2.4 Высокий уровень доступности

Реляционные СУБД разрабатывались в ту эпоху (1970-е гг.), когда в типичной организации имелась одна вычислительная машина. Если она выходила из строя, компания несла убытки из-за недоступности системы. Для решения проблемы аварийных ситуаций организации поддерживали и тщательно сохраняли журнальные ленты. При возникновении аварийной ситуации поставщик аппаратуры (обычно IBM) проявлял чудеса героизма, в течение нескольких дней поставляя новую аппаратуру и приводя ее в режим эксплуатации. Затем производилось восстановление системы на основе журнальных лент, что позволяло привести ее к почти тому состоянию, в котором она находилась до возникновения аварийной ситуации.

Десятилетием позже, в 1980-е гг. организации заключали контракты со службами восстановления после аварийных ситуаций, такими как Comdisco, на предмет обеспечения ресурсов резервной аппаратуры, так что имелась возможность быстрой установки журнальных лент на удаленных резервных компьютерах. Эта стратегия позволяла сократить время простоя предприятия по причине аварийной ситуации.

Сегодня имеются многочисленные организации, использующие горячее резервирование (hot standby), которое позволяет производить обработку отказов аппаратуры в реальном времени. В некоторых других компаниях поддерживается несколько основных вычислительных систем, что обеспечивает еще более быструю обработку отказов. Организациям оказывается выгодно платить за несколько систем, чтобы избежать сокрушительных финансовых последствий простоя, когда каждая минута простоя часто обходится в тысячи долларов.

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

Во-вторых, у большинства поставщиков существующих РСУБД имеется интеграционная поддержка системы из нескольких машин поверх их исходной архитектуры, ориентированной на SMP (Symmetric MultiProcessor, симметричный мультипроцессор, компьютерная архитектура, в которой несколько процессоров имеет равноправный доступ к совместно используемой основной памяти). Очевидно, что гораздо более эффективной является поддержка архитектуры shared-nothing с самого начала разработки системы.

В третьих, наилучший способ поддержки архитектуры без общих ресурсов состоит в использовании нескольких машин в одноранговой (peer-to-peer) конфигурации. Тогда нагрузка OLTP может быть распределена между несколькими машинами, а межмашинную репликацию можно использовать для отказоустойчивости. В обычном режиме эксплуатации доступными являются ресурсы всех машин. При отказах деградация функционирования системы возможна только из-за сокращения числа ресурсов. В отличие от этого, во многих коммерческих системах реализуется режим горячего резервирования, при котором вторая машина, по существу, простаивает до тех пор, пока не возьмет на себя управление при отказе первой машины. В этом случае в обычном режиме эксплуатации используется только половина ресурсов, что является заведомо худшим решением. Эти доводы доказывают потребность в полном перепроектировании серверов РСУБД, чтобы в них можно было обеспечить одноранговую высокую доступность внутри новой архитектуры.

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

В статье [LM06] утверждается, что процедуры обработки отказа узла путем передачи нагрузки на другой узел и восстановления функционирования узла, вновь вошедшего в строй, (failover/rebuild) настолько же эффективны, что и процедура прямого восстановления по журналу. Следовательно, у этого способа поддержки высокого уровня доступности, по существу, нет недостатков. В мире высокой доступности не требуется поддержка журнала повторного выполнения операций, нужен только временный журнал откатов. Это поразительно упрощает логику восстановления. Можно отказаться от подсистемы журнализации в стиле Aries [MHL+92] и пользоваться новыми функциональными возможностями для восстановления состояния узла, возобновляющего функционирование после отказа, на основе данных других узлов.

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

2.5 Никаких ручек управления

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

Единственным выходом из этого положения является перевод систем на «самообслуживание» (самовосстановление, автоматическое техническое обслуживание, автоматическую настройку и т.д.). Однако во всех РСУБД имеется огромное количество ручек управления, унаследованных от прошедшей эпохи. Безусловно, все поставщики пытаются обеспечить автоматические средства, устанавливающие эти ручки управления без вмешательства человека. Однако из унаследованного кода невозможно удалить какие-либо имеющиеся возможности. Поэтому в дополнение к операциям с ручками управления, устанавливаемыми людьми, появится операция включения автоматического режима управления, что приведет к еще большему объему системной документации. Кроме того, в настоящее время средства автоматической настройки в РСУБД, с которыми знакомы авторы статьи, не позволяют добиться производительности системы, близкой к той, которую может обеспечить квалифицированный администратор баз данных. До тех пор, пока средства настойки в существующих системах не будут значительно улучшены, администраторы будут продолжать крутить ручки управления. Намного лучшим решением является полный пересмотр процесса настройки и создание новой системы без явных ручек управления.