Отечественная БД HyTech

Большое спасибо Николаю за комментарий. Если читателя интересует официальная HyTech от СКАЗ-М, настоятельно рекомендую ознакомиться с ним. Моя же заметка о форке HyTech 1.6, который был сделан году этак в 1993, и после которого пути развития сильно разошлись.

Рождение форка

Будучи студентом четвёртого курса довелось мне познакомиться с отечественной разработкой в области баз данных под названием HyTech. Использовалась она (да и по сей день используется) в фирме, где я тогда работал — НТЦ «Сонар-Плюс». Идея и первоначальная реализация на C принадлежит «СКАЗ-М». Сейчас разработка всё ещё продолжается, более того — активно используется в продакшене. Им удалось создать серверную версию, реализовать части стандарта SQL, а также написать кучу адаптеров (php, Delphi/Builder, ODBC, JDBC). Почему я говорю «им»? С этой реализацией мне так и не пришлось столкнуться, т.к. на моём месте работы её переписали на Delphi. Оставим в стороне разбор этого политического решения, факт остаётся фактом — родился ещё один форк 🙂 Далее я буду рассказывать исключительно про форк, т.к. с официальной версией поработать не сумел.

Внутреннее устройство

Битовая маска

Вкратце, HyTech — файл-серверная БД (типа dBase IV) без SQL-интерпретатора. Построена на всё тех же таблицах и индексах, но оперирует понятиями множеств записей. Т.е. одну выборку записей можно пересечь с другой выборкой записей, уточнить уже существующую без перевыполнения всего запроса. Это, как мне кажется, одна из её киллер-фич. Удаётся такое за счёт внутренней реализации, основанной на инвертированных списках. Результат выполнения любого запроса представляет собой битовую маску, где 1 — запись подходит под условие, 0 — не подходит. Таким образом удаётся избежать открытия курсора и чтения данных на этапе поиска. На проиндексированной базе выборка происходит очень быстро (нет, не так — ОЧЕНЬ быстро). Точные цифры бенчмарков получить уже затруднительно, но по памяти HyTech рвёт как Тузик грелку хвалёные Ораклы, SQLite и пр. и пр. Одним же из главных минусов опять же является битовая маска — как нетрудно посчитать, уже на 16 миллионах записей размер выборки составит 2 мегабайта, что в общем случае уже критично сказывается на производительности.

Журнал изменений

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

Описатель БД

Стоит отдельно сказать про т.н. описатель БД. В той версии, с которой я работал, все поля строились на доменах — грубо говоря колонках, у которых указан тип и ограничения, а уже на них таблицы. Т.е. операция изменения структуры таблицы сводилась к изменению описателя таблицы (создание нового домена, если нужно) и её пересозданию. Опять же спецификой моей версии является полное отсутствие SQL, хранимых процедур, null'ов, триггеров и прочих плюшек современных СУБД. Хорошо хоть транзакции есть :) Вот как-то так работает HyTech. Ещё раз напомню, что я говорю о форке версии 1.6 в далёком 1993 году

Применение

Я рассмотрел только основные достоинства и недостатки этой бд, на самом-то деле нюансов ещё куча, но все они следуют из вышеописанного. На мой взгляд, идея инвертированных списков весьма интересна и могла бы найти своё применение в некоторых областях. Первое, что приходит в голову, — локальный поиск. Тут ограничением на 16 миллионов записей можно пренебречь, журнала фактически не будет, т.к. он сразу может упаковываться в постоянную часть. Поиск какого-либо документа будет происходить почти моментально, а условия можно добавлять без полного перезапуска оного. Так же было бы уместно на мой взгляд встраивать HyTech во всякие каталогизаторы, где есть теги — фото, видео, нумизматические коллекции и пр.

Оригинальная реализация HyTech написана на C++ и даже есть порт под linux, но вот удобных инструментов так и не появились. Когда я писал интерпретатор SQL для delphi версии (мой диплом, заслуживает отдельной статьи 🙂), я смотрел что же уже сделано в версии на C++. SQL интерпретатор есть, но он тривиален — не поддерживает оптимизацию, агрегатные функции и пр., зато есть куча коннекторов. Так что может кто-нибудь и попробует что-нибудь реализовать с помощью HyTech.

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