Управление данными, размещенными в оперативной памяти

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

Благодаря значительным усовершенствованиям технология управления размещаемыми в оперативной памяти данными стала достаточно зрелой. Наконец появились коммерческие продукты, в которых она реализована.

В этой статье пойдет о предложениях двух небольших фирм - TimesTen Performance Software и Angara Database Systems.

ПО TimesTen Main-Memory Data Manager позволяет на порядок увеличить производительность приложений баз данных. С точки зрения архитектуры, TimesTen может использоваться и автономно, вместо "самодельных" пакетов управления данными, размещаемых в оперативной памяти, и в качестве дополнительной технологии ускорения приложений в сочетании с уже развернутой реляционной СУБД.

Хотя в качестве семантического и синтаксического интерфейса для TimesTen был выбран SQL, а в качестве API-интерфейса - ODBC, система не претендует на роль полнофункциональной реляционной СУБД. Из-за отсутствия целого ряда признанных стандартными возможностей TimesTen нельзя напрямую сравнивать с реляционной базой данных. Однако TimesTen действительно позволяет на порядок увеличить производительность приложений баз данных.

Различия

За счет чего достигается подобная производительность? Не может ли приложение работать столь же быстро просто за счет того, что все необходимые данные из нижележащей реляционной СУБД помещать в оперативную память? Увы, нет. Дело в том, что реляционные базы данных функционируют исходя из предположения, что обрабатываемые данные в основном находятся на диске. Алгоритмы оптимизации, управление буферным пулом и технология извлечения данных на основе индексов - все существенным образом ориентировано на такую модель хранения. Со своей стороны, TimesTen "знает", что данные находятся в оперативной памяти, и поэтому может использовать более прямой путь для доступа к информации, сокращая размер программы, упрощая и алгоритм, и структуру. Даже когда реляционная СУБД сконфигурирована так, что все данные содержатся в оперативной памяти, на ее производительность влияет глубоко укоренившиеся предположения о том, что данные все-таки хранятся на диске. Изменить подобную "предвзятость" сложно - она упрятана (на что ушли десятилетия разработки и исследований) в логику обработки, схемы индексов и т.д. При сравнении архитектур проявляется рад кардинальных различий. Остановимся детальнее на нескольких вопросах: алгоритмах оптимизации запросов, управлении буферным пулом и индексных структурах.

Оптимизация запросов

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

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

Управление буферным пулом

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

Более того, ни одна из традиционных реляционных СУБД не позволяет во время исполнения динамически изменять предположения о размещении данных. Ориентация на хранение данных на диске, слишком глубоко "вплетена" в код системы, чтобы это можно было исправить, добавив несколько операторов if-then-else. Примером тому может служить сравнение древовидных адресных структур.

Индексные структуры

B-деревья

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

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

T-деревья

В TimesTen картина намного проще. T-дерево оптимизировано для доступа к оперативной памяти и имеет гораздо более экономичную структуру, чем B-дерево. Для навигации по дереву используются указатели "меньше-или-равно" и "больше", представляющие собой непосредственные ссылки на адрес в памяти, а не на дисковую страницу. Всего за две операции сравнения алгоритм поиска T-дерева "узнает": находится ли искомое значение в текущем узле или где-либо еще в памяти. И с каждым переходом по указателю узла индекса область поиска сокращается вдвое.

Задачи управления данными в оперативной памяти - уменьшить требования к памяти, отказаться от дисковых операций ввода/вывода и упростить программу поиска.

Зачем необходимы различия

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

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

Показатели ускорения

Системы управления размещенными в оперативной памяти данными позволяют увеличить производительность не на несколько процентов, а в несколько раз. Приложение, которое тратило половину процессорного времени на управление данными, а половину - собственно на отработку своей бизнес-логики, может удвоить свою эффективность за счет размещения информации в оперативной памяти. (Для приложения, которое тратит еще больше времени на управление данными, это соотношение будет еще больше: при 50% - производительность возрастет вдвое; при - 75% - в четыре раза и т.д.).

Эволюция диспетчеров данных, размещаемых в памяти

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

Однако, постепенно эволюционируя, они вышли из этих узких рамок. Они стали опираться на стандартные API-интерфейсы. Реляционная семантика и синтаксис вытеснили нестандартные модели данных. На смену "самодеятельным" методам управления памятью пришли аппарат транзакций, поддержка целостности данных и надежное восстановление после сбоев. К высокоэффективным архитектурам с непосредственными связями добавилась модель взаимодействия клиент-сервер. Механизм тиражирования данных позволил использовать стратегии обеспечения высокой готовности. Наконец, на рынке появились коммерческие версии систем управления данными, размещаемыми в памяти, их реализация стала намного совершеннее, а их производители оказывают пользователям своих программных продуктов полноценную поддержку.

Архитектура системы TimesTen

API-интерфейсы и SQL

Архитектурой TimesTen предусмотрено взаимодействие в соответствии со спецификацией Open DataBase Connectivity (ODBC). Благодаря этому многие приложения и инструментальные средства, созданные в соответствии с этим стандартом, могут взаимодействовать со средой TimesTen без каких-либо изменений.

Методы индексирования

В TimesTen используются технологии индексирования двух типов: хешированные индексы и T-деревья. Хешированные индексы обеспечивают очень высокую скорость работы, если в приложении требуется точное совпадение с ключом поиска. T-деревья, как и их аналоги в СУБД, рассчитанных на дисковое хранение данных на диске - B-деревья, подходят для извлечения значений, неточно совпадающих с ключом поиска или принадлежащих определенному диапазону.

Хешированные индексы создаются автоматически, когда в схеме хранилища данных определяется PRIMARY KEY ("первичный ключ"). T-деревья генерируются для столбцов (атрибутов) по команде CREATE INDEX ("создать индекс").

Управление транзакциями

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

Контрольные точки и восстановление данных

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

Оптимизация запросов

TimesTen имеет оптимизатор запросов, который выбирает наилучший план выполнения SQL-команды учитывая выбор индексов (в том числе автоматическое создание временных индексов); метаданные (целостность ссылок, первичный ключ и т.д.); cтатистику таблиц и колонок; выбор алгоритма соединения (соединение вложенных циклов, соединение вложенных циклов с индексами, соединение с поглощением).

Планы запросов - просмотр и модификация

TimesTen позволяет разработчику просматривать и модифицировать план запроса, предложенный оптимизатором. Разработчик приложения может дать оптимизатору TimesTen ряд "советов", как лучше оптимизировать конкретный запрос. Эти советы облекаются в форму директив, которые определяют порядок и алгоритм соединения, надо ли использовать временные индексы или какие их типы (T-деревья или хеширование) следует применять, а также следует ли сохранять промежуточные результаты.

Предварительная компиляция SQL-команд

TimesTen поддерживает предварительную компиляцию SQL-команд. Для этого предусмотрены функции SQLPrepare() и SQLExecute(). Функция SQLPrepare() вызывается в начале сеанса или раздела приложения и выполняет предварительную компиляцию плана запроса, сохраняя его для последующего использования функцией SQLExecute() в рамках того же процесса. Предварительная компиляция SQL-команд позволяет увеличить производительность приложения за счет того, что оптимизация выполняется только единожды, а готовый план оптимизации можно будет использовать при последующих вызовах этого же фрагмента на SQL.

Архитектура клиент-сервер

Систему TimesTen можно сконфигурировать таким образом, чтобы обращаться к данным как из серверного приложения, так и с клиентского приложения, работающего с сетевыми протоколами TCP/IP или IIOP.

Тиражирование данных

Благодаря механизму тиражирования данных появляется возможность использования стратегий обеспечения высокого уровня готовности приложений и доступности данных. Ориентируясь на высокую эффективность и низкие накладные расходы TimesTen применяет схему тиражирования на основе регистрации транзакций.

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

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

Характеристики производительности

Тесты производительности, предложенные специалистами университета штата Висконсин (Wisconsin Benchmarks), считаются одними из самых убедительных средств измерения производительности реляционных СУБД и фактически стали стандартным инструментарием для измерения общей производительности баз данных. На рис. 8 показатели TimesTen Main-Memory Data Manager сопоставляются с результатами популярными реляционными СУБД. При этом в обоих случаях данные размещались в оперативной памяти. График демонстрирует, насколько TimesTen Main Memory Data Manager выигрывает в производительности. Длина прямоугольника показывает, во сколько раз производительность на данном тесте выше: если прямоугольник, к примеру, имеет в длину 5 единиц, то это значит, что TimesTen выполняет данный тест в 5 раз быстрее, чем соответствующая реляционная СУБД.

Оценка размера

До появления TimesTen Main-Memory Data Manager версии 3.0 (в настоящее время она доступна как для 32-х, так и для 64-разрядных операционных систем), существовали технические ограничения на размер хранилища данных, размещаемого в оперативной памяти. В настоящее время TimesTen поддерживает 64-разрядные операционные системы HP-UX 11.00 компании Hewlett-Packard и Solaris 7 компании Sun Microsystems. В 64-разрядной ОС на большинстве компьютерных систем допустимый размер хранилища данных TimesTen измеряется десятками гигабайт.

Ограничения на размер хранилища данных, работающих в 32-разрядных вариантах Unix или Windows NT, существуют по-прежнему. На многих аппаратных Unix-платформах 32-разрядное адресное пространство позволяет приложению использовать адресное пространство размером не более 2 Гбайт. Для TimesTen ограничения еще жестче из-за вопросов, связанных с размещением хранилища данных и управлением разделяемой памяти.

Заключение

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

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

СУБД Angara Data Server

Для многих современных приложений одним из наиболее критичных параметров является производительность используемой СУБД. К традиционным средствам увеличения производительности относятся методы, позволяющие переносить данные, хранящиеся на диске в оперативную память. Однако при таком подходе проблема производительности решается лишь частично, поскольку он предполагает лишь сокращение числа операций ввода/вывода на диск. СУБД Angara Data Server 3.0 - один из возможных вариантов снять остроту проблемы, поскольку она специально создавалась для работы с данными, размещенными в оперативной памяти.

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

Архитектура Angara Data Server

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

Упрощенная оптимизация запросов.

Поскольку время доступа к данным, расположенным на диске и используемым при работе традиционных СУБД измеряется в миллисекундах, стоит

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

Отсутствие разбиения на дисковые страницы.

Структура буферных пулов дисковых СУБД соответствует страничной структуре диска. Это упрощает процесс обмена данными между диском и кэш, но увеличивает время, необходимое для доступа к данным в памяти. Кроме того, распределение по страницам снижает эффективность использования памяти, а Angara Data Server позволяет к тому же избежать искусственных ограничений при распределении данных.

Отсутствие менеджера буфера

При работе с дисковыми СУБД даже в тех случаях, когда таблица целиком размещается в буферном пуле, обработка любого запроса предусматривает обращение к диспетчеру буферного пула с тем, чтобы определить, где именно в данных момент требуемые данные находятся. Если таблицы всегда располагаются в оперативной памяти, как это происходит в случае с Angara Data Server, можно обойтись без этого шага, то есть диспетчер буферного пула просто не нужен, поскольку данные никогда не переносятся на диск и нет необходимости выбирать требуемую страницу и копировать ее в память.

Индексирование с помощью T-дерева.

Применяемый в Angara метод индексации, называемый T-деревом, создавался специально для таблиц, резидентно находящихся в оперативной памяти. Между T-деревьями и B-деревьями, используемыми в традиционных дисковых СУБД, существуют два коренных отличия. Во-первых, они различаются по структуре. B-деревья "широкие и не глубокие", а T-дерево, оптимизированное для работы в оперативной памяти, будет намного "глубже и уже", чем B-дерево. Такая структура позволяет не только увеличить производительность, но и сократить объем требуемой памяти.

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

Упрощение структуры позволяет создавать менее сложные программы.

Из-за отсутствия сложностей, связанных с вводом/выводом, буферным пулом и переносом строк, тексты приложений, использующих Angara Data Server, существенно сокращаются по сравнению с их дисковыми эквивалентами. Кроме того, время их работы заметно уменьшается просто потому, что процессору приходиться выполнять значительно меньше команд, что в свою очередь увеличивает стабильность работы приложения.

Индексация

Поддерживаются индексы двух типов: индексы хеширования и T-деревья.

Защита данных

Механизм обеспечения сохранности данных в Angara Data Server предусматривает расстановку контрольных точек, что гарантирует автоматическое восстановление базы данных в состояние, предшествующее выполнению транзакции, во время которой возник сбой. Информация о состоянии, полученная в контрольных точках, попеременно записывается в два файла с пользовательской конфигурацией для того, чтобы защитить систему от потери данных во время операций создания "среза" в контрольных точках. Алгоритмы регистрации и работы с контрольными точками были созданы специально для уникальной архитектуры Angara и позволяют обеспечить защиту данных с минимальным воздействием на производительность. С помощью тех же механизмов Angara Data Server поддерживает восстановление таблиц и индексов.

Транзакции

В Angara Data Server предусмотрен механизм транзакций с тремя режимами регистрации.

Strict Commit: все изменения в базе данных регистрируются каждый раз по завершении транзакции. Это обеспечивает абсолютную гарантию восстановления всех завершившихся транзакций.

Group Commit: журнал регистрации записывается на диск, когда его размер достигает размера дисковой страницы, или когда завершается определенное число транзакций. Такой подход позволяет увеличить производительность и в то же время гарантировать, что в случае сбоя будет утеряна информация о транзакциях, число которых не превышает заранее оговоренного количества.

Temporary: запись файла регистрации на диск выполняется для временных по своей природе данных, что обеспечивает более высокую скорость обработки транзакции.

Диапазон применения

Angara Data Server, интегрируемый на уровне приложений со традиционными реляционными СУБД, позволяет не только воспользоваться преимуществами в скорости, обеспечиваемыми размещением данных в оперативной памяти, но и одновременно работать с данными большого объема, выполнять резервное копирование и восстановление, пользоваться широким набором инструментов и разработки, поддерживать унаследованные приложения.

Angara Data Server может использоваться и автономно. Дело в том, что значительное число приложений работает с достаточно ограниченным объемом данных, но при этом требует уровня производительности, который не могут обеспечить дисковые СУБД. В прошлом у разработчиков таких приложений был лишь один выход: создавать свои собственные решения управления данными, используя структуры в оперативной памяти для быстрого доступа и набор плоских файлов для постоянного хранения данных. Angara может служить альтернативным проектным решением в таких случаях.