СУБД

И обеспечивает российским разработчикам доступ к технологии IMDB

После наделавших много шума покупок двух крупных производителей систем корпоративного управления - компаний PeopleSoft и Retek - корпорация Oracle (www.oracle.com) снова обратила свой взор на перспективных поставщиков технологических решений. В середине июня она анонсировала приобретение TimesTen (www.timesten.com) - одной из наиболее ярких инновационных фирм последнего десятилетия в сегменте реляционных СУБД (РСУБД). Стоимость сделки пока держится в секрете. Образованная восемь лет назад, TimesTen выпустила в свое время первую РСУБД, хранящую и обрабатывающую данные только в оперативной памяти, не обращающуюся к жесткому диску и характеризующуюся чрезвычайно высокой производительностью. Она поддерживает 32- и 64-разрядные редакции Solaris, HP-UX, AIX, Tru64 Unix, Red Hat и SuSE Linux, а также Windows.

Все это дало вендору основание позиционировать свой продукт как решение для управления данными в реальном времени. К настоящему моменту он нашел применение в ряде высокопроизводительных решений для отрасли телекоммуникаций и в онлайновых системах, поддерживающих торговлю ценными бумагами. Так, крупнейшие сотовые операторы Sprint и T-Mobile используют СУБД TimesTen в своих биллинговых системах для оперативной проверки состояния баланса звонящего абонента. При этом оценивается стоимость первых двух минут разговора, которая тут же сопоставляется с остатком денег на счете. Затем указанная процедура повторяется каждые две минуты. Технология TimesTen нашла применение и в известной биллинговой системе Amdocs. В общей сложности у TimesTen более 1500 клиентов, среди которых такие известные компании, как Avaya, Cisco Systems, Ericsson, JP Morgan, Lucent, NEC, Nokia и United Airlines.

Что же привнесла TimesTen в технологии реляционных СУБД? Ведь идея размещения базы данных в оперативной памяти достаточно очевидна, а основные усилия по оптимизации производительности промышленных РСУБД и так нередко сводятся к копированию довольно большого фрагмента БД с диска в память (так называемый кэш) и дальнейшей его обработки, минуя обращение к медленным операциям дискового ввода-вывода. Еще восемь с половиной лет назад, когда из Hewlett-Packard выделилась небольшая частная фирма TimesTen, не вызывали никаких сомнений две тенденции развития ИТ - быстрое удешевление оперативной памяти и широкое распространение 64-разрядных платформ. Действительно, объем ОЗУ мощных серверов уже достигает десятков гигабайт, а 64-разрядные архитектуры постепенно добираются и до настольных ПК. И если сегодня есть сомнения относительно востребованности 64-разрядных вычислений в тех или иных областях, то только не в области РСУБД. Как известно, 32-разрядные процессоры позволяют непосредственно обращаться к 4-Гб оперативной памяти, а 64-разрядные способны адресовать 16 млн. терабайт, что фактически снимает какие-либо ограничения на размер базы данных, целиком размещаемой в ОЗУ.

Сначала такие СУБД было принято относить к категории MMDM (Main Me-mory Data Manager), но в последние годы в обиход вошла аббревиатура IMDB (In-Memory Database). Скорость обработки информации инструментами IMDB в 10-20 раз превышает показатели традиционных "дисковых" РСУБД. Если вспомнить, что обращение к данным в ОЗУ осуществляется на несколько порядков быстрее, чем к тем, что находятся на диске, указанный выше выигрыш кажется весьма скромным. Дело, однако, в том, что сегодня традиционные РСУБД фактически тоже манипулируют большими наборами данных (например, теми, что запрашиваются чаще всего), предварительно извлеченными из дисковой подсистемы и помещенными в ОЗУ. Более того, если размер ОЗУ позволяет разместить там всю БД, то многие традиционные РСУБД так и делают. Что же нового в технологическом плане предложила TimesTen?

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

В IMDB, кроме того, совершенно другая структура хранения данных в ОЗУ. Обычные РСУБД копируют данные с диска целыми страницами. При этом структура их остается такой же, какой она была на диске, что, естественно, негативно отражается на алгоритмах обработки данных. Благодаря более рациональной схеме хранения накладные расходы (дополнительная память для временных данных) в IMDB не превышает 20% (в обычных РСУБД - до 50%). Иначе в IMDB устроены и индексы. Дело в том, что столь популярные в традиционных РСУБД B-деревья хороши лишь тогда, когда нужно уменьшить число обращений к диску. Если же этого ограничения нет, то гораздо эффективнее оказываются T-деревья.

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

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

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

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

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

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

По-видимому, наибольшую потребность в высокопроизводительных IMDB-решениях испытывает отрасль телекоммуникаций, где множество сервисов осуществляется в реальном времени. Здесь бывает необходимо обрабатывать тысячи вызовов в секунду, каждый из которых сопровождается тремя - пятью обращениями к БД. Традиционно такие функции реализовывались в специализированном коммутирующем оборудовании, что ограничивало возможности усовершенствования и масштабирования систем. Сегодня эти функции все чаще возлагаются на универсальные компьютеры со стандартным программным обеспечением. Среди них - преобразование телефонных номеров, начинающихся на 800, запись номеров абонентов, пользующихся переадресацией звонков, и т. д. Еще одна задача, требующая очень высокой производительности, - поддержание реестра местоположения абонентов (Home Location Register, HLR) в системах сотовой связи. При перемещении мобильного телефонного аппарата для реализации полноценного роуминга с сохранением всех полномочий пользователя необходимо очень быстрое обновление БД, а для определения специфического набора сервисов, доступных тому или иному абоненту, необходимо выполнять операции реляционного соединения, которые очень эффективно реализуются в оперативной памяти.

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

В каких своих продуктах Oracle намерена использовать приобретенные ею ноу-хау (покупку TimesTen корпорация намерена завершить в июле), пока в точности неизвестно. "Технологии TimesTen станут органичным расширением наших линеек Oracle Database и Oracle Fusion Middleware", - заявил старший вице-президент Oracle по серверным технологиям Эндрю Мендельсон. Думается, отечественным разработчикам данное поглощение окажется весьма полезным, поскольку в результате они получат доступ к технологиям IMDB от вендора, имеющего, в отличие от TimesTen, в нашей стране и собственное представительство, и мощную партнерскую сеть.