ЛИНТЕР в качестве встроенной СУБД. От простого к сложному? От сложного к простому!

Павел Пасечник (ЗАО НПП "РЕЛЭКС")

Реляционный сервер баз данных ЛИНТЕР - активно развивающаяся система. История этой СУБД насчитывает уже не один десяток лет. Изначально, ЛИНТЕР разрабатывался как универсальная система для применения в различных областях - таковым он является и сейчас.

От простого к сложному

Что требуется от СУБД, которая претендует на роль встраиваемой?…

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

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

Что же для этого необходимо?

1. "Бережное" отношение к вычислительным ресурсам.

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

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

Итак, предсказуемость потребления ресурсов (ОЗУ и ВЗУ) - это одно из главных требований встраиваемости.

СУБД ЛИНТЕР изначально проектировалась исходя из парадигмы постоянства занимаемой оперативной памяти и минимизации использования ресурсов операционной системы.

Для полноценной работы СУБД ЛИНТЕР достаточно 4 МБ оперативной памяти (а при некотором ограничении ее функциональности 2МБ). При этом можно контролировать объем памяти, выделенной СУБД дополнительно. С ростом этого объема будет расти эффективность обработки больших объемов информации и параллельной работы.

И, как следствие, ЛИНТЕР - одна из самых предсказуемых систем.

Если СУБД ЛИНТЕР стартовала на выделенной памяти, то дополнительная оперативная память ей в процессе работы не потребуется.

Кроме того, это одна из самых недорогих систем подобного класса.

2. ЛИНТЕР - управляемая система.

Что мы под этим подразумеваем?…

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

Например, произошел сбой диска, содержащего БД, или на машине запущено слишком много приложений и не хватает оперативной памяти для СУБД.

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

3. Простота "администрирования".

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

Такой режим работы мы называем полуавтоматическим. СУБД ЛИНТЕР позволяет работать в таком режиме.

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

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

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

Например, можно осуществить запуск процесса архивации базы данных вопреки установленному расписанию. Это может быть выгодно, в ситуации, когда приложение определило, что интенсивность запросов к базе данных упала, или приложение "планирует" такое падение интенсивности …

4. Интеллектуальность работы СУБД ЛИНТЕР.

Одним из основных принципов при создании СУБД был принцип "действий по умолчанию". В любой ситуации СУБД может предпринять соответствующее действие сама - без вмешательства администратора.

Это очень важное свойство для встраиваемой системы.

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

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

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

5. Минимум объектов управления.

Для работы СУБД необходима только одна задача - ядро СУБД. При работе в сетевых условиях потребуются дополнительно сетевые драйверы: драйвер клиента на клиентской машине и драйвер сервера - на серверной. Запуск, останов и управление этих задач может осуществляться прикладной системой.

В случае если необходимо периодическое сохранение БД, может использоваться еще и задача архиватора БД.

Прочие утилиты могут использоваться в случае, если они нужны прикладной системе. Их использование не является необходимым.

Это значительно упрощает конечную систему, делает её более обозримой, легко устанавливаемой и документируемой.

6. Возможности предварительной настройки.

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

За счёт небольших размеров системной части первоначальной базы данных, это вполне реально.

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

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

Но самое важное то, что первоначальная база данных уже будет содержать параметры запуска ядра СУБД ЛИНТЕР. Так что первоначальный запуск не потребует дополнительных настроек.

7. Автоматизация обеспечения надёжности.

Во-первых, журнализация работы БД.

Все действия с БД протоколируются в журнале транзакций для обеспечения корректного отката в случае ошибки операции или отказа аппаратных средств в процессе ее обработки.

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

Во-вторых, холодный и горячий Backup.

С процессом холодного сохранения базы данных достаточно ясно. Он может запускаться приложением по завершению сеанса работы ядра СУБД ЛИНТЕР.

Hot backup может работать параллельно с ядром СУБД и выполняться по заранее составленному расписанию.

Например, каждый понедельник, в 17.00; ежедневно в определённое время, и т.п.

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

Разработчик приложения может автоматизировать и восстановление базы данных из резервной копии. Так, если при запуске СУБД сообщила приложению, что указанная база повреждена (соответствующим кодом возврата), то в дело вступает backup. Он может удалить поврежденную базу данных и развернуть на ее место архивную копию. После этого приложение вновь попытается запустить СУБД.

Для приложений с повышенными требованиями к скорости hot backup можно вызывать в моменты минимальной нагрузки на сервер. Для этого в ЛИНТЕР предусмотрены механизмы слежения за использованием ресурсов ядра СУБД.

8. Кросс-платформенность.

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

Это может достигаться разными способами. Или с помощью реализации прикладного ПО на переносимых языках (к примеру, Java) или реализацией клиентских приложений под широкий спектр платформ.

При этом должна существовать возможность размещения сервера и клиента на машинах с разными архитектурами.

Естественно, сама СУБД должна удовлетворять требованиям к кросс-платформенности.

ЛИНТЕР удовлетворяет всем требованиям, накладываемым необходимостью "встроить" СУБД в приложение.

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

Уже упоминалось, что СУБД ЛИНТЕР - масштабируемая система управления базами данных.

Таким образом, при установке прикладной системы на более мощные ЭВМ пользователь действительно получит выигрыш в производительности.

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

Масштабируемость должна послужить одной из наиболее привлекательных сторон нашей отечественной СУБД.

Теперь коснёмся приложений, которые предусматривают серьёзные требования к многопользовательской работе.

И здесь СУБД ЛИНТЕР может оказаться привлекательной системой для встраивания в готовый продукт.

В ЛИНТЕР версии 6.1 (и выше) осуществлён переход к многоверсионности данных.

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

Таким образом, в новейших версиях СУБД ЛИНТЕР улучшены показатели распараллеливания обработки запросов.

При этом выдержаны стандартные режимы работы транзакций от Dirty Read до Cursor Stability и Serializable.

Кроме того, следует отметить, что СУБД ЛИНТЕР версии 6.1 поддерживает стандарт SQL-92 (Entry Level) и даже многое из Intermediate Level.

От сложного к простому

Однако встраиваемость имеет и другую сторону.

Говоря это, мы имеем ввиду возможность использования СУБД в специфических условиях.

Какие условия имеются ввиду? Перечислим некоторые из них:

• повышенные требования к производительности;
• жёсткие ограничения по оперативной памяти;
• жёсткие ограничения по внешней памяти;
• повышенные требования к надежности;
• работа в реальном масштабе времени.

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

В идеале это должно выглядеть так. Конфигуратор высвечивает множество подсистем. Отмечая некоторые из них, мы, тем самым, получаем необходимую нам конфигурацию СУБД ЛИНТЕР.

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

Уже появились заказчики и, соответственно, начаты работы и ресурсы по созданию и использованию подобных систем.

Где это требуется? Здесь можно назвать такие системы как СУБД для КПК, мобильных телефонов, бортовых систем, файловых систем (на основе систем управления базами данных) и т.п.

Например, разработка фирмы ADIC (США) - HSM иерархическая система хранения данных - файловая система на основе СУБД ЛИНТЕР.

Итак, поподробнее об этом и многом другом…

1. Возможность ведения базы данных в памяти.

Это позволит использовать систему на аппаратных средствах, у которых отсутствует файловая система для хранения БД.

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

Понятно, что в такой системе в случае отказа по питанию все данные будут утеряны, и при повторном запуске прикладной программе придётся начинать работу с чистой БД.

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

Скорость перезапуска системы после отказа оборудования значительно возрастет.

2. Представления в оперативной памяти.

Речь идёт о таблицах, которые являются результатами VIEW. Такая таблица формируется в оперативной памяти. Это, естественно, даст выигрыш в скорости.

Такое представление строится в оперативной памяти (если её объём достаточен для этого), как нормальная таблица. Для неё строятся необходимые индексы. После этого её описание - это описание таблицы, но не VIEW.

Конечно же, такая стратегия подходит только для мало изменяемых представлений, например, объединение совокупности справочников. Модификация базовых исходных таблиц представления естественно потребует перестроения VIEW, однако в некоторых случаях и на такие затраты можно пойти для повышения скорости обработки поисковых запросов.

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

А для использования read-only таблиц перемещение в ОЗУ - наиболее желательное решение.

Конечно же, доступная память будет использоваться в режиме Write-Back кэша, что повышает производительность при частых модификациях БД.

3. Снижение универсальности повышает эффективность работы.

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

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

4. Конфигурация системы обработки запроса.

Речь идет, прежде всего, об SQL-трансляторе и аппарате хранимых процедур и триггеров.

Дело в том, что в отлаженной и готовой к поставке прикладной системе, скорее всего все запросы известны и оттранслированы. При исполнении остаётся только подставлять новые параметры.

Оптимизацию запросов в системе, можно передвинуть на этап разработки приложения (синтаксическую) и обработки (статистическую).

Таким образом, в уже готовой системе со стандартным набором запросов SQL-транслятор уже не нужен, и от него можно отказаться.

Кроме того, в готовой системе можно отказаться так же от подсистемы обработки DDL-операций. Действительно, таблицы в предустановленной БД все созданы, индексы построены и т.д.

Далеко не во всех приложениях требуется аппарат хранимых процедур и триггеров.

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

Далее - сортировка. Отказ от неё означает отказ от SQL-запросов, содержащих предложения GROUP BY, ORDER BY, CREATE INDEX и т.п.

Если потребности в таких запросах нет, то СУБД ЛИНТЕР можно уменьшить на размер подсистем обработки таких запросов. Ещё более уменьшить и ещё более упростить.

Возможно также паллиативное решение - вместо большой универсальной сортировки можно использовать сортировку небольших объёмов данных находящихся в ОЗУ. Тем более, во многих подобных системах размер ответов, подлежащих сортировке невелик.

Словный поиск и аппарат словных индексов. Подсистема может быть отключена без ущерба для большинства приложений. А в случае, если разработчик уже отказался от поддержки длинных типов данных (BLOB, EXTFILE), то вообще нет смысла оставлять ее в системе. Но иногда требуется и подсистема словного поиска; хороший пример - телефонная база данных, где возможен не только индексно-последовательный доступ. Например, поиск всех номеров, заканчивающихся на 59…

Поэтому словный поиск можно как включать, так и не включать в систему в зависимости от потребностей приложения.

Аппарат составных индексов тоже в большинстве случаев может оказаться лишним. Во многих запросах использование составных индексов может практически без ущерба для производительности быть заменено использованием индексов по одному столбцу.

5. Отключение/включение возможностей расширенной защиты данных.

В СУБД ЛИНТЕР очень серьёзная подсистема защиты от несанкционированного доступа. ЛИНТЕР сертифицирован Гостехкомиссией при Президенте Российской федерации на соответствие второму классу защиты от несанкционированного доступа согласно руководящему документу "Средства вычислительной техники. Защита от несанкционированного доступа к информации".

В нашей системе защите подлежат не только таблицы, но даже записи таблиц и отдельные поля записей.

Такая секретность, конечно же, бывает важна, но в большинстве случаев не является необходимой.

Тем более что она влияет на размер базы данных (а, значит, на скорость работы), а так же и на возможности оптимизации в системе.

Например. Рассмотрим простейшее условие A.I != 5; без секретности можно перевести операцию в более оптимальную - NOT (A.I = 5), а с секретностью такой возможности увы нет.

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

6. Декларативная ссылочная целостность.

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

7. Возможен так же отказ от "больших" типов данных.

Например, отказ от полей с длиной более 4-х килобайт.

Не говоря уже о таких объектах, как BLOB-объекты и внешние файлы.

8. Ограничение внешней памяти.

Это не столь уж смешное, на первый взгляд, требование.

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

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

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

Кроме того, во многих системах достаточно короткие транзакции, так что объём файлов журнала можно так же свести к минимуму; тем более что почти всегда отсутствуют "длинные" типы данных.

Как уже было отмечено, у компании РЕЛЭКС существует большой опыт в создании таких систем. Первая версия СУБД ЛИНТЕР для встроенных систем появилась 1996-ом году. Это была версия ЛИНТЕР 4.4 работающая под управлением операционных систем реального времени OS-9 (на аппаратной платформе Motorola 680хх) и OS-9000 (на платформе x86). Причём, к этой системе предъявлялись жесткие требования по надёжности. Дальше были версии для QNX и VxWork's. Одна из последних разработок - версия ЛИНТЕР 5.9 для отечественной ОС 2000 (разработка НИИСИ). В области использования СУБД ЛИНТЕР как встроенной системы в продуктах сторонних компаний, достойны упоминания следующие разработки:

ADIC (США) - HSM иерархическая система хранения больших объёмов данных. Файловая система на основе СУБД ЛИНТЕР;

ВНИИРА (Санкт-Петербург) - диспетчерская система аэропорта;

AlignMark, Inc. (США) - автономная система дистанционного обучения.

В настоящий момент фирма SONY планирует использовать СУБД ЛИНТЕР в некоторых своих новых разработках.

Компания РЕЛЭКС продолжает исследования и разработки в области встраиваемых СУБД и в ближайшие несколько лет планирует занять определённую часть мирового рынка таких систем.