Архитектура баз данных реального времени

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

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

называемый кэш) и дальнейшей его обработки, минуя обращение к медленным опе­рациям дискового ввода-вывода.

Действительно, объем ОЗУ мощных серверов уже достигает десятков гигабайт, а 64-разрядные архитектуры постепенно добираются и до настольных ПК. И если сегодня есть сомнения относительно востребованности 64-разрядных вычислений в тех или иных областях, то только не в области РСУБД. Как известно, 32-разрядные процессо­ры позволяют непосредственно обращаться к 4-Гб оперативной памяти, а 64-разряд­ные способны адресовать 16 млн. терабайт, что фактически снимает какие-либо огра­ничения на размер базы данных, целиком размещаемой в ОЗУ.

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

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

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