Немного об отечественном СУБД-строении

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

В качестве предисловия

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

Несколько «крутых» программистов трудятся над ним месяцев пять или шесть, используют «системный язык программирования Perl и СУБД Postgree» и хотят, чтобы кто-то подсказал им, как увеличить производительность, поскольку «система с закачанными данными сильно тормозит сервер, работающий под FreeBSD».

Я тихо, ненавязчиво поинтересовался объемом данных в базе. Оказалось, что около тысячи записей пока, но, возможно, будет в несколько раз больше. Им нужен руководитель, который бы сказал как надо, а они сами быстро все сделают.

Я набрался мужества и спросил, а знает ли кто-нибудь из них язык программирования С. Мне в ответ уверенно заявили, что это все уже устарело и с вебом можно работать только через Java/Perl, а «из баз данных лучше всего Postgree или MySQL». Спорить с этим суждением, господа, бесполезно и даже вредно для собственного здоровья.

В «Компьютерре» за октябрь прошлого года прочитал статью о QNX RealTime Platform и решил все-таки попытаться написать о том, чем занимаюсь уже лет эдак пятнадцать, не меньше. Наверное, пора. За державу обидно. А занимаюсь я СУБД реального времени.

О сервере

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

Начинался проект создания СУБД мягкого реального времени в начале 1990 года. Тогда только что стали появляться IBM PC, а когда мы увидели жесткий диск и разобрались с его структурой (нас было двое, и жесткие диски были объемом до 40 Мбайт), стало очевидным, что не сделать СУБД - это значит найти большое золотое яйцо и не нагнуться, чтобы его подобрать. Нам пришлось обследовать около дюжины настольных СУБД для IBM PC на предмет подтверждения своей идеи, и, затратив полгода на исследования, мы решили разработать конкретные рабочие алгоритмы и программы, а месяцев через восемь появился первый результат (закрякал наш «гадкий утенок»). Далее были поиски и оптимизация алгоритмов доступа к жесткому диску и много еще чего.

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

Интерфейс доступа к функциям микроядра (величина самого микроядра около 20 Кбайт, и загружалось оно как резидентная программа TSR) был реализован для языков программирования С и Pascal как к функциям с передачей множества параметров.

Микроядро получало запрос через точку входа - прерывание со свободным номером и параметры запроса через интерфейс память-память. Для управления памятью и мультипрограммированием доступа к данным был разработан менеджер управления памятью (на одного клиента на сервере требуется около 64 Кбайт ОЗУ).

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

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

Поскольку структура индексного файла - не «В-дерево», то формула поиска ключа в файле не является логарифмом от числа ключей.

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

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

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

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

Теперь кратко о файлах базы данных. Как уже говорилось, мы не изобретали велосипед заново, а взяли за основу плоский тип двумерной таблицы (это в 1990 году-то). Но и здесь файл базы данных резко отличается (логическая его реализация) от общепринятой на тот момент. То есть весь файл разбит на логические блоки-кластеры, в которые укладываются записи фиксированной длины. Это вроде бы усложняет механизм управления доступом к данным, но зато резко увеличивает скорость доступа.

Если мне не изменяет память, такой механизм появился у «той стороны» году в 1994-м или 1995-м.

О клиентах

Механизм работы с данными типа клиент-сервер (как называть программу сервера СУБД - сервер баз данных или сервер приложений, не столь важно - важна сама суть) казался нам самым «живучим» и быстрым.

Сразу скажу, что доступа к серверу иначе как через сеть не предполагалось, и в качестве таковой была выбрана на удивление типичная одноранговая сеть типа Arcnet с сетевыми платами 10 Мбит/с. Хотя, как показал реальный эксперимент на реальных данных, замена плат 10 Мбит/с на платы 2,5 Мбит/с снизила общую производительность системы всего на 20%. Зато увеличение скорости доступа жесткого диска (с 10,2 до 8,7 мс) повысило производительность на 30%.

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

Количество подключенных клиентов локальной сети - сорок машин (486DX/66/4 Мбайт).

Сетевые платы - 10 Мбит/с.

Сетевой кабель - тонкий коаксиал.

Структура - одноранговая «звезда».

Сервер - 120 МГц «Пентиум» с двумя жесткими дисками, связанными в массив RAID-1 и работающими синхронно с временем доступа 9,2 мс. Объем ОЗУ 12 Мбайт.

База данных около 600 тыс. записей (120 Мбайт).

Основной поиск по двум индексным файлам объемом по 4-5 Мбайт каждый.

Плюс огромная куча индексных списков (около девяноста файлов) объемом от 300 Кбайт до 2 Мбайт каждый.

При этом время поиска нужной информации соизмеримо со временем вывода данных на экран дисплея клиентской машины в текстовом режиме вывода (около одной секунды).

Клиентская программа пишется на языке C илиC++ - это не столь важно. Кто как хочет, тот так пусть и делает. Для вызова функций сервера СУБД имеется всего ОДНА функция с массой параметров, код операции микроядра - тоже параметр. Для стыковки вашего клиентского кода с функцией вызова предлагаются всего два объектных файлика. Один для клиентских программ, работающих на той же машине, что и сервер СУБД, как пользовательские процессы. Другой для работы через любую локальную сеть, по протоколу TCP/IP.

Обращение обоих типов клиентов абсолютно прозрачно, но для сетевых, естественно, дольше. Сервер связи как раз и нужен для сопряжения сетевиков с «родными клиентами».

Все программное обеспечение написано на ассемблере + C для процессора типа Intel. Для того чтобы им никто не мешал работать, ряд функций микроядра СУБД обращается прямо в ядро Unix (без посредников) за реализацией системного сервиса. Вот так.

В реализации под Unix уже сняты некоторые ограничения:

• длина записи базы данных увеличена до 2000 байт (было 512 байт);

• количество ключей длиной до 16 байт около 1,5 млн. на один индексный файл (хотя уже и это ограничение в рабочем варианте увеличено до 15 млн. ключей/файл);

• количество одновременно открытых файлов около 300 (было 120);

• количество клиентских процессов увеличено до 150 (было 50);

• включена (пока заглушена за ненадобностью) система хранения закрытых данных (то есть данных, защищенных ключами), причем возможен механизм защиты отдельных записей файла базы данных (но не индексных файлов). Длина ключа составляет 8 символов. Шифрование и дешифрование осуществляется клиентской программой по любому алгоритму. Ну вот и все.

В качестве заключения

Описанная выше идея уже портирована под Unix SCO Open Server 5.0, FreeBSD 4.0, Linux Red Hat 6.2 (ведутся работы по портированию в QNX RtP для создания систем управления в жестком режиме реального времени), разумеется, применительно к типу операционной системы, и состоит из:

• сервера баз данных (исполняемый код около 80 Кбайт - это вам не Oracle);

• сервера связи с сетевыми клиентами (исполняемый код около 8 Кбайт), работающими по протоколу TCP/IP;

• интерактивной программы - браузера для создания заготовок баз данных и индексных файлов и общих операций над файлами (пока только для FreeBSD и в стадии доработки);

• краткого описания функций доступа (API-функций) к серверу баз данных.

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

Например,

# cp /mnt/serv_baza /bin/serv_baza
# cp /mnt/serv_tcp /bin/serv_tcp
# cd /bin
# chmod 0700 ./serv_baza
# chmod 0700 ./serv_tcp

Далее вы с помощью редактора vi создаете файл с именем rc.local и заносите в созданный файл строки:

# Файл инициализации серверов баз данных
# В качестве параметров указывать для serv_baza путь к каталогу баз данных
# Для сервера связи указать имя серверного хоста в сети/bin/serv_baza /u/base_file & # Строка пути не более 40 байт
/bin/serv_tcp имя_сервера & # my_serv или любое другое
# Это может сделать (не) каждый.

В приведенном примере для FreeBSD файл rc.local помещается в каталог /etc . Осталось перезагрузить систему.

Видите, как все сложно. Вот только обидно, что не надо перекомпилировать и перестраивать ядро системы. Ничего такого, что очень круто. Да, это вам не Oracle. Скрипач не нужен. Нет.

[i40127]