В особо ответственных элементах корпоративных, технологических и бортовых систем в течение вот уже нескольких десятилетий применяются уникальные технологии управления данными в оперативной памяти. Отказ от внешних запоминающих устройств позволял достичь впечатляющих операционных характеристик, правда, цена решений была исключительно высокой. Одним из первых инструментальных решений стала предложенная корпорацией IBM система Information Management System, располагающая двумя механизмами управления: IMS Fast Path для данных, поддерживаемых в оперативной памяти, и IMS для данных, хранящихся на внешних дисках. В 70—90-е годы в этой области велись интенсивные исследования и экспериментальные разработки, в результате которых были созданы системы HALO, MARS, MM-DBMS, OBE, System M, TPK и др. Дальнейшее развитие таких технологий стимулируется неуклонным ростом объемов и снижением стоимости доступной оперативной памяти, возможностями многоядерных 64-разрядных процессоров, архитектурой параллельной обработки и распространением распределенных систем. В результате сегодня высокопроизводительные механизмы управления данными в оперативной памяти перестали быть экзотикой — они встраиваются в сетевое и связное оборудование, специализированные устройства, сенсоры и датчики для систем управления в реальном времени, в операционные системы и популярные приложения. Например, система ObjectStore компании Progress позволяет с гарантированными параметрами обслуживать базу данных Amazon.com, к которой ежеминутно обращается не менее миллиона пользователей, а разработанное компанией Applix решение TM1 (ныне оно предлагается в составе IBM Cognos 8) обеспечивает пересчет в реальном времени OLAP-кубов в задачах бизнес-анализа.
Среди подобных решений особое место занимают реляционные системы управления базами данных в оперативной памяти (in-memory/main memory database, IMDB/MMDB). Благодаря стандартизованным интерфейсам они могут обслуживать множество программ, обеспечивая высокую реактивность и пропускную способность систем при пиковых нагрузках, позволяя тем самым решать задачи сбора, интеграции, обработки и анализа информации в близком к реальному масштабе времени, которые централизованные СУБД поддерживать просто не в состоянии. В традиционной трехзвенной архитектуре «клиент — сервер приложений — мощный сервер реляционных СУБД» приложение далеко не всегда в состоянии предоставить и обработать всю необходимую информацию тогда и там, где это необходимо: по мере роста систем централизованные сервисы доступа к информационным ресурсам оказываются чрезмерно ресурсоемкими и дефицитными, причем экстенсивное наращивание мощностей корпоративных серверов и систем хранения данных проблему не снимает.
Высокопроизводительные системы, поддерживающие базы данных в оперативной памяти, предлагают сегодня корпорации IBM (solidDB), Oracle (TimesTen) и Sun Microsystems (SQL Cluster), специализированные компании ENEA (Polyhedra), McObject (eXtremeDB), Birdstep Technology (Raima Data Manager), Altibase (Altibase), а также представители сообщества Open Source (в том числе CSQL, MonetDB, H2 DBMS и HSQLDB). Именно с помощью таких продуктов в информационных системах операторов связи, фондовых бирж и банков, авиакомпаний, торговых и транспортных сетей, промышленных предприятий, научно-исследовательских организаций, оборонных и специальных структур сегодня ежесекундно выявляются и регистрируются миллионы фактов, анализируются происходящие события, принимаются обоснованные решения и перераспределяются потоки данных и работ.
Освободиться от дисков
Как известно, общая производительность традиционных систем ограничена скоростью выполнения операции обмена с внешними устройствами, поэтому применяются механизмы управления буферами и кэширования, индексирования, оптимизации обработки запросов, распределение баз данных во внешней памяти, распараллеливание обработки запросов на мультипроцессорах, кластерные решения, сегментирование и даже специализированные аппаратно-программные решения.
Техника кэширования основана на временном хранении копии данных в буферной памяти. Например, процессорный кэш обеспечивает эффективный обмен между процессором и оперативной памятью, благодаря дисковому кэшу сокращается число обращений к внешней памяти, сетевой кэш за счет сохранения HTML-страниц и их фрагментов позволяет сократить сетевой трафик и нагрузку на Web-серверы и серверы приложений. Буферный кэш СУБД и механизм управления им обеспечивает своевременное считывание и возврат страниц баз данных во внешнюю память. Именно в этой области памяти прозрачно для прикладной программы осуществляются операции манипулирования данными: программа обращается к исполнительной системе СУБД, та, оптимизировав запрос, определяет адреса нужных страниц на диске, перемещает их целиком в кэш, выполняет необходимые преобразования и передает нужные данные программе. Измененные данные возвращаются на диск, и они проделывают обратный путь (рис. 1а).
Конечно, чем большую часть базы данных удастся разместить в буферном кэше, тем с большей скоростью будет происходить обработка. Однако, несмотря на то, что современные серверы, операционные системы и СУБД позволяют полностью кэшировать базы данных объемом в десятки и сотни гигабайт, предельная производительность системы по-прежнему определяется традиционной архитектурой механизма управления данными, нацеленного на минимизацию числа операций обмена данными между медленной внешней памятью и прикладными программами. До сих пор в кэше приходится держать полные образы страниц данных на диске, структура индексов соответствует страничной организации данных, а доступ осуществляется через менеджер буферного пула.
Радикально улучшить производительность можно, освободив СУБД на время исполнения программы от необходимости обращаться к внешним запоминающим устройствам (рис. 1б). В «бездисковой» СУБД все пользовательские и системные таблицы, каталоги, индексы, буферы системного журнала, таблицы блокировок, временные области и другие объекты эффективно располагаются в оперативной памяти, что позволяет существенно «облегчить» архитектуру. Структура индексов также претерпевает изменения — они становятся компактнее, поскольку при доступе к данным не требуется минимизация количества операций ввода-вывода. В алгоритмах обработки запросов главным критерием выбора оптимального плана становится не число обращений к внешней памяти, а вычислительная «стоимость» операции и эффективная загрузка процессора. Наконец, более эффективно решается ряд задач администрирования, например борьба с фрагментацией памяти. В результате по времени реакции и пропускной способности система, в которой работа базы данных происходит в оперативной памяти, значительно выигрывает даже по сравнению с решением с полностью кэшированной базой традиционной «дисковой» СУБД. Так, например, в тесте Telecom One, имитирующем рабочую нагрузку в телекоммуникационных приложениях при 100 тыс. мобильных абонентах, пропускная способность системы IBM solidDB оказалась в среднем в десять раз выше, чем у традиционных СУБД.
Долговременное хранение
Но как обеспечить физическую целостность базы данных, если оперативная память компьютера энергозависима, и при отключении или отказе сервера СУБД данные будут потеряны? Для этого применяются локальные или сетевые процедуры резервного копирования и восстановления, а в качестве оперативных механизмов — периодическое сохранение «моментальных снимков» состояния базы данных и ведение системных журналов изменений на диске, а также репликация и синхронизация баз данных. При открытии состояние базы данных восстанавливается по контрольной точке, и дальнейшая обработка в памяти поддерживается эффективными механизмами управления конкурентным доступом, обработки транзакций и блокирования ресурсов. При записи контрольной точки все зафиксированные транзакции сбрасываются из буфера журнала во внешнюю память, а между контрольными точками в журнал вносятся транзакции по мере фиксации, что обеспечивает возможность восстановления в случае системного отказа. Применение механизма контрольных точек без ведения системного журнала обеспечивает более высокую производительность, но в аварийной ситуации дает возможность вернуться только к предыдущему целостному состоянию. В зависимости от специфики приложения и требуемого баланса между производительностью и обеспечением сохранности данных в промежутках между контрольными точками запись изменений в журнал относительно момента фиксации транзакции может осуществляться синхронно или асинхронно. В системах Altibase и IBM solidDB реализовано гибридное решение — сервер СУБД содержит два механизма управления данными: один оптимизирован для доступа к диску, а другой ориентирован на хранение данных в оперативной памяти. Прикладная программа может обращаться и к тем, и к другим данным с помощью одного оператора SQL.
Уровень изоляции определяется спецификой прикладных задач: одни должны монопольно «захватывать» обрабатываемые данные, в других допускается определенная степень вмешательства со стороны выполняемых параллельно программ. В СУБД в оперативной памяти чтение результатов незафиксированных транзакций не предусмотрено, поэтому поддерживаются три уровня изоляции транзакций: Read Committed (чтение результатов только зафиксированных транзакций — это достаточный уровень изоляции для большинства приложений); Repeatable Read (чтение результатов только зафиксированных транзакций с гарантией того, что данные остаются неизменными до фиксации транзакции); Serializable (наивысший уровень изолированности — результат конкурирующих транзакций должен быть таким же, как после их последовательного выполнения).
В традиционной СУБД изоляция транзакций реализуется с помощью хэш-таблиц, указывающих на блокируемые объекты, а при хранении баз данных в оперативной памяти соответствующие признаки могут встраиваться непосредственно в объекты базы данных, и это дает возможность оптимизировать алгоритмы управления блокировками. В ряде систем, например в Oracle TimesTen, с целью поддержки распределенных транзакций предусмотрен интерфейс для программного мониторинга изменений, регистрируемых в журнале (Transaction Log API, XLA), и инициализации соответствующих действий (применения изменений к внешним базам данных, рассылки уведомлений и т.п.).
Архитектура передового развертывания
На рис. 2 представлена укрупненная схема взаимодействия компонентов системы баз данных, поддерживаемых в оперативной памяти.
СУБД в оперативной памяти могут применяться как в компактных решениях, встраиваемых в специализированные приложения и устройства, так и в крупных проектах масштаба предприятия, в которых множество приложений в сервис-ориентированной архитектуре (Service-Oriented Architecture, SOA) обеспечивают решение задач по периметру сетевой инфраструктуры компании. Сбор, обработка и предоставление данных в реальном масштабе времени нужны для поддержки персонализированных форм взаимодействия с пользователями, гармонизации бизнес-процессов и упрощения внутренних операций, обработки информационных потоков и доставки данных мультимедиа. Организациям практически любого масштаба и направления деятельности необходимы приложения, развертываемые как можно ближе к источникам и местам потребления информации, причем дополнительные выгоды для заказчиков могут обеспечить средства поддержки баз данных в оперативной памяти, интегрируемые с корпоративными СУБД.
В дополнение к основному уровню хранения данных (back-end) целесообразно, опираясь на совокупные ресурсы оперативной памяти распределенной серверной платформы, иметь облегченные и в то же время более производительные механизмы управления и среду хранения данных на «переднем плане» (front-end) непосредственно на серверах приложений и периферийных узлах. Для этого используются различные архитектурные схемы развертывания решения: библиотека функций СУБД, подключаемая непосредственно к прикладной программе, сервер IMDB, обслуживающий прикладные программы; дополнительно могут применяться функциональные компоненты, обеспечивающие кэширование основной базы данных, и отказоустойчивые конфигурации. Во всех этих схемах действует единый интерфейс прикладного программирования.
Такие решения могут быть относительно автономными, например, в телекоммуникационных приложениях реального времени и интеллектуальных устройствах для сбора и обмена данными о поступающих вызовах, состоянии сети, перемещении абонентов и т.п. В системах обработки потоков данных, поступающих по коммерческим, новостным и технологическим каналам, в интеграционных решениях и системах бизнес-аналитики усиленные с их помощью узлы хранения данных и управления транзакциями позволяют распределить нагрузку и разгрузить корпоративные серверы, а в системах резервирования билетов, мест в гостиницах, в электронной торговле и системах поддержки коллективной работы они могут обеспечить вертикальное или горизонтальное партиционирование баз данных и ускорение доступа к их интенсивно используемым подмножествам. Наконец, на их базе может быть развернут синхронизируемый с основной «дисковой» базой данных быстродействующий локальный или распределенный кэш основной базы данных, способный справляться с пиковыми нагрузками на корпоративные системы.
Отказоустойчивость
Системы управления базами данных в оперативной памяти позволяют реализовать отказоустойчивые конфигурации с основным и резервным узлами СУБД, в которых обеспечивается постоянная автоматическая синхронизация на уровне системы, сеанса или транзакции, что позволяет сбалансировать пропускную способность, сохранность данных и время восстановления системы, а при отказе практически мгновенно переключать ресурсы (рис. 3). К тому же наличие постоянно готовой копии системы позволяет, не отключая основной сервер, параллельно выполнять вспомогательные работы: формирование отчетности, резервное копирование, установку обновлений программного обеспечения и т.д.
Кэширование баз данных
Механизм управления данными в оперативной памяти позволяет поддерживать локальный или распределенный кэш основной базы данных в виде копий ее фрагментов, реплицируемых в памяти на серверах приложений, «приближенных» к месту создания или использования данных. Кэшируемые фрагменты основной базы данных, в качестве которых могут выступать одна или несколько таблиц, их «горизонтальные» проекции или «вертикальные» подмножества строк, определяются в рамках установленных структурных ограничений администратором баз данных с помощью операторов расширения SQL или дополнительных инструментов.
Прикладным программам доступны высокопроизводительные сервисы СУБД в оперативной памяти для хранения и обработки данных, управления конкурентным доступом и транзакциями и обеспечения отказоустойчивости, причем благодаря использованию аналогичных с основной СУБД интерфейсов, взаимодействие с кэшем и основной базой данных «прозрачно» для приложения. После загрузки из основной базы данные могут считываться или обновляться непосредственно в кэше подключенными к нему (локально или по сети) прикладными программами. Двусторонний трафик при загрузке, периодической подкачке, синхронизации данных (в синхронном или асинхронном режиме) обрабатывает специальный программный агент — коннектор кэша и основной базой данных. Управление осуществляется автоматически в соответствии с параметрами, установленными по умолчанию или задаваемыми администратором баз данных, а также на уровне прикладной программы, при этом обеспечивается восстановление системы в аварийных ситуациях.
Такое решение позволяет разгрузить корпоративные серверы хранения данных и обеспечить необходимые операционные характеристики для высоко реактивных масштабируемых приложений реального времени, обработки транзакций, а также ведения условно-постоянной, нормативно-справочной информации, профилей пользователей, данных о конфигурации и т.д.
Распределенные базы данных
Сервисы управления базами данных должны быть непрерывными, в особенности для критических задач. Благодаря возможности репликации баз данных непосредственно в оперативной памяти на узлах сети, данные можно расположить настолько «близко» к приложениям, насколько этого требует быстродействие, пропускная способность или доступность решения, например, в сетях доставки мультимедиа-контента, телекоммуникационных системах и устройствах и т.д.
Высокопроизводительные механизмы синхронной и асинхронной (на основе модели публикации и подписки) репликации и синхронизации баз данных встраиваются в СУБД в оперативной памяти и используют такие их возможности, как управление транзакциями и поддержка расширений SQL, позволяющих достаточно быстро разрабатывать распределенные приложения, максимально отражающие специфику реальной задачи, например, способность выявлять и разрешать конфликты, исходя из бизнес-правил и логики.
В распределенной системе основная база содержит «эталонные» данные, которые реплицируются на одну или несколько копий. Копия может иметь несколько таблиц, одни из которых содержат только копии эталонных данных, другие — только локальные значения, а третьи некоторую их смесь. Изменения, внесенные в какую-либо из копий передаются на главный сервер, который верифицирует их в соответствии с заданными правилами, и после проверки рассылаются на остальные копии (рис. 4). При этом в зависимости от требований решаемой задачи поддерживаются различные по производительности, организации взаимодействия и отказоустойчивости схемы репликации, разрешения конфликтов, восстановления баз данных и проводки изменений в реальном времени, в том числе ориентированные на решения, встраиваемые в устройства без дисков. Для управления репликацией применяются соответствующие операторы расширения SQL.
***
После приобретения в 2005 году «ветерана» СУБД в оперативной памяти компании TimesTen корпорацией Oracle последняя предлагает решение Oracle TimesTen, в состав которого входит сервер СУБД Oracle Timesten In-Memory Database и дополняющие его опции Replication — TimesTen to TimesTen для создания отказоустойчивых конфигураций и равномерного распределения нагрузки и Cache Connect to Oracle для кэширования баз данных Oracle на серверах приложений.
Объявленные в начале лета 2008 года три решения IBM SolidDB 6.1, работающие под управлением ОС Linux, HP/UX, AIX, Solaris и Z/OS — результат первого этапа интеграции технологий финской компании Solid Information Technology, приобретенной IBM годом ранее, в стек решений по управлению информацией по требованию. Два из них — IBM solidDB Cache для DB2 и IBM solidDB Cache для Informix Dynamic Server могут быть развернуты в дополнение к серверам СУБД для увеличения производительности за счет кэширования основной базы данных, а третье — IBM solidDB — благодаря сдвоенному гибридному механизму СУБД поддерживает базы данных в оперативной памяти и на дисках.
На рынке систем управления базами данных в оперативной памяти заметно присутствие не только лидеров, но и «чистых» игроков, таких как шведская компания ENEA, которая с 1993 года предлагает семейство реляционных СУБД в оперативной и флэш-памяти Polyhedra для мобильных устройств и клиент-серверных приложений, требующих максимальной производительности и надежности в системах с интенсивными информационными потоками, например в беспроводных сетях и промышленных системах управления. К таким игрокам относятся и южнокорейская компания Altibase с одноименной гибридной системой, и поставщики встраиваемых СУБД McObject с eXtremeDB и Birdstep Technology с Raima Data Manager (в эту группу следует включить и поставляемую Oracle систему Berkley DB), а также таких систем категории Open Source, как CSQL, FastDB, MonetDB, H2 и HSQLDB.
На системы управления базами данных в оперативной памяти приходится от 0,5 до 1% современного рынка СУБД, и этот сегмент, по мнению аналитиков IDC, еще только формируется. Решения этого класса не следует рассматривать как альтернативу корпоративным СУБД — их применение оправданно в особо ответственных ситуациях в качестве инструмента существенного повышения производительности, надежности и пропускной способности, дополняющего корпоративный портфель средств управления данными.
Рис. 1. Доступ приложения к базе данных: а) в традиционной системе; б) в СУБД в оперативной памяти (Oracle TimesTen)
Рис. 2. Схема взаимодействия компонентов системы баз данных, поддерживаемых в оперативной памяти с репликацией и кэшированием основной базы данных. Решение Oracle TimesTen
Рис. 3. Отказоустойчивые конфигурации: а) основной и резервный сервер: б) два активных сервера; в) активный и несколько резервных серверов IMDB. Решение Altibase
Рис. 4. Различные схемы репликации баз данных: односторонняя а) с одной копией, б) с несколькими копиями, в) двусторонняя, г) многосторонняя. Решение Oracle TimesTen Replication
