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

В последние несколько лет, в связи с резким снижением цен на модули памяти и широкое распространение 64-разрядных ОС, появилась возможность реализации идей по оптимизации производительности СУБД при ее размещении целиком в оперативной памяти. Появились первые коммерческие продукты, реализующие эти идеи в рамках реляционных СУБД (например, TimesTenкомпанииTimesTenPerformanceSoftwareиAngaraDataServerкомпанииAngaraDatabaseSystems). Эти продукты могут использоваться как автономно в качестве пакетов управления данными, размещаемых в оперативной памяти, так и в качестве дополнительной технологии ускорения приложений в сочетании с уже развернутой реляционной СУБД. Здесь мы кратко рассмотрим основные отличия в структурах данных, обусловленных различными подходами к оптимизации систем.

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

С другой стороны, диспетчер данных, размещаемых в оперативной памяти, «знает» о том, где находятся данные и оптимизирует запросы, исходя из более простых предположений.

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

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

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

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

В TimesTenиспользуются технологии индексирования двух типов: хешированные индексы и Т-деревья. Хешированные индексы обеспечивают очень высокую скорость работы, если приложению требуется точное совпадение с ключом поиска. Т-деревья более подходят для извлечения значений, неточно совпадающих с ключом поиска или принадлежащих определенному диапазону. Хешированные индексы создаются автоматически, когда в схеме данных определяется первичный ключ; Т-деревья, в свою очередь, генерируются при выполнении команды «создать индекс».

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