1. Что изменилось в системе за прошедший год

Люди устают от революций. Хотя, конечно, как же без них - прогресс без революций невозможен. Для нас 2004-ый год это год Эволюции. Всё должно было устояться, приобрести чёткие очертания. Мы хотели понять куда, как и с чем двигаться дальше. Вновь после небольшого перерыва вернулись к исследованиям.

Развивалось только то, что было насущно необходимым, жизненно необходимым. Основным направлением было увеличение надёжности. Но не только.

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

Мы считаем, что это одно из главных достижений команды ЛИНТЕР и всей фирмы РЕЛЭКС в прошедшем году.

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

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

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

1.1 Более мобильна

ЛИНТЕР «распространила ареал обитания» ещё на две новые операционные системы - QNX 6.x и MAC OC 10.

Казалось бы, появление QNX 6.x в списке поддерживаемых ОС, с одной стороны, выглядит закономерным. ЛИНТЕР работал на QNX 4.x, и с появлением новой версии этой ОС, столь популярной среди разработчиков real-time приложений, было бы логично также обеспечить ее поддержку. С другой стороны, большую роль в этом сыграли и некоторые производители СУБД, отказавшиеся от поддержки этой платформы. Разработчики ПО просто засыпали нас просьбами поддержать QNX 6.x. Что и было сделано. Причём не просто формально, а с добавлением новых интересных возможностей (in-memory table).

1.2 Горячий резерв (hot-standby server)

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

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

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

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

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

При этом эффективность работы основного сервера практически не зависит от числа резервных серверов.

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

1.3 Производительность

Было снято архаичное ограничение на использование оперативной памяти в 65000 страниц (256М) для одного серверного процесса.

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

ЛИНТЕР может использовать оперативную память до 8 терабайт. Размер рабочих файлов теперь может быть более 2 Гб (WRK, WBV).

1.4 Поддержка протокола SNMP

В 2005-м году РЕЛЭКС выпускает версию СУБД ЛИНТЕР с поддержкой SNMP-протокола.

Как известно, SNMP-протокол предназначен для мониторинга сети, т.е. аппаратного и программного обеспечения, работающего в ней.

Конечно же, речь идёт, в основном, о мониторинге сетей enterprise-уровня, включающих сотни (и более) рабочих станций. Однако даже для небольшого предприятия SNMP-протокол становится актуальным, как только это предприятие включается в более крупные конгломераты, особенно международные.

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

Было решено поддерживать протокол SNMP всех версий, включая и версию 3 (SNMPv3). Здесь нет ничего удивительного, т.к. главное отличие SNMPv3 от предыдущих версий состоит в дополнительной защите данных, то есть в обеспечении дополнительной секретности. Это позволит пользователям ЛИНТЕР комплексно подойти к проблеме защиты информации, теперь и на этапе управления системой.

Версия ЛИНТЕР с поддержкой SNMP уже прошла β-тестирование на реальном объекте и впервые будет представлена широкой общественности на выставке SofTool2005. В этом же году начнутся и поставки SNMP в составе дистрибутива СУБД ЛИНТЕР.

Поддержка SNMP будет входить во все версии дистрибутива, начиная с версии 5.7.

1.5 ReadOnly базы данных

Новый параметр запуска ядра СУБД ЛИНТЕР - /RO.

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

При этом функциональность выборок абсолютно не пострадает. Будут разрешены любые SELECT-запросы, и отключены все транзакционные режимы, проверки блокирования и т.п.

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

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

1.6 Приятные пустяки

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

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

Пока есть только возможность указывать:

• на использование какого-либо индекса для упорядочения ответов запроса, причём можно упорядочивать как в прямом порядке, так и в обратном;
• на определённый порядок выполнения предикатов;
• на способ обработки подзапроса во FROM-предложении (раскрывать или выполнять последовательно). Что в некоторых случаях очень существенно влияет на обработку запросов, содержащих представления, когда оптимизатор может не всегда принять верное решение.

Теперь, что касается хранимых процедур.

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

Функции, возвращающие значения, могут участвовать в любых предложениях SQL запроса (от SELECT до HAVING). Сняты все ограничения на использование SQL-запросов в функциях.

Для интеграции с приложениями платформы .NET разработан OLEDB .NET провайдер.

1.7 Глобальные временные таблицы

То, чего давно ждали наши клиенты. Доступ к механизму временных таблиц.

CREATE GLOBAL TEMPORARY TABLE ИМЯ_ТАБЛИЦЫ ({определение столбца | [ограничение таблицы]}, ... [ON COMMIT {DELETE | PRESERVE} ROWS]);

Для глобальной временной таблицы возможно создание индексов primary key, unique, обычных и составных индексов, а также внешних ключей, ссылающихся на другие таблицы. Внешние ссылки на глобальную временную таблицу создавать запрещается. Поддерживаются ограничения CHECK, DEFAULT, AUTOINC, работа триггеров (за исключением триггеров DELETE для глобальных временных таблиц с ON COMMIT DELETE ROWS; при подаче COMMIT - временная таблица будет очищаться так же, как и при TRUNCATE TABLE), ссылочной целостности (on update cascade, on delete cascade).

1.8 Ускорение работы фразового индекса

Построение фразового индекса теперь ускорилось более чем в 2 раза(!), а скорость поиска возросла в полтора раза.

И это несмотря на то, что увеличилась функциональность этих индексов. Теперь можно индексировать не только коллекции документов в национальных кодировках, но также и в UNICODE.

Word (95,97/2000/XP/2003), Excel (95 и выше), PowerPoint (все), PostScript (но достаточно формально), PDF (все версии с поддержкой восточных языков), RTF, XML, HTML (с UNICODE и в однобайтовых кодировках), TXT (с UNICODE и в кодировках ASCII, ANSI и koi8).

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

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

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

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

2. Real Time

Как уже говорилось выше, выпуск новых версий популярной ОС реального времени QNX 6.x, спровоцировал всплеск активности разработчиков real-time приложений. Многие компании начали переносить свои решения на новую ОС. К нам поступило много запросов на использование ЛИНТЕР в QNX 6.x.

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

В ЛИНТЕР появились новые объекты базы данных. Мы назвали их IN-MEMORY таблицы.

Можно создать как бы копию (slave) существующей таблицы (master) в памяти и работать с ней, как с самостоятельной таблицей. При старте базы slave-таблица может автоматически отображаться в память, а при завершении работы сохраняться в master.

Управление такими таблицами берут на себя всего три запроса:

CREATE SLAVE TABLE
    Slave-таблица FOR Master-таблица [[NO] AUTOSAVE] [[NO] AUTOLOAD];

SAVE Slave-таблица; /* Сохранить изменения Slave-таблицы */

RESTORE Slave-таблица; /* Восстановить Slave-таблицы из Master-таблицы */

    AUTOSAVE - автоматически сохранять slave-таблицу при shutdown - по умолчанию не сохранять.

    AUTOLOAD - автоматически активизировать slave-таблицу при старте системы - по умолчанию не активизировать.

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

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

При любом сбое, содержимое slave-таблицы снова загружается из базовой master таблицы. Конечно же, в этом случае все изменения будут потеряны. Однако, СКОРОСТИ ради… Пользователи часто готовы пойти на это, и во многих случаях такой риск вполне оправдан.

Следует отметить, что работа по реализации IN-MEMORY таблиц велась при активном участии наших партнеров - разработчиков прикладных систем, то есть наши разработки практически сразу «обкатывались» на реальных задачах.

Возможности использования IN-MEMORY таблиц будут включены во все версии ЛИНТЕР старше 5.9.

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

3. Исследовательская часть

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

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

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

Ещё в 2000-ом году американские IT-аналитики подсчитали, что инвестиции в OLAP-технологии дают за 3 года 400% прибыли.

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

Мы ведём исследования в направлении создания OLAP-ядра для подобных систем. В первом приближении мы приняли для себя, что это должна быть специальная реляционная СУБД с мощными возможностями агрегирования данных. Т.е. речь идёт о ROLAP-системе.

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

Ещё в 1993 году Коддом были изложены основные концепции построения OLAP-систем. Он сформулировал 12 правил OLAP. Одно из них выглядит примерно так: система должна обеспечивать постоянную производительность при построении отчётов, при увеличении количества измерений или объёма данных не должно происходить существенное падение производительности.

Этот момент является слабым местом современных реляционных СУБД. Поэтому на первом этапе основной упор был сделан на создание алгоритмов оптимизации обработки таких OLAP-операций SQL, как CUBE, ROLLUP и GROUPING SETS. Здесь мы не стали экспериментировать, а приняли синтаксис языка SQL этих операций, предложенный в стандарте.

Все приведённые выше операторы создают несколько группировок по нескольким полям, например, запрос:

SELECT  Time, Region, Department, Model, SUM(Profit)
FROM  Sales
       GROUP BY CUBE (Time, Region, Department, Model);

Этот запрос должен решить 8 различных группировок (16 комбинаций) - от полной (по Time, Region, Departament, Model) - до пустой. Очевидно, результаты полной группировки будут агрегированы в каждую верхнюю группировку, например, в группировку по Time и Region, которая, в свою очередь, будет источником данных для группировки по столбцу Time и т.д.

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

Из этого примера ясно, что многие группировки верхних уровней, например, по Time+Region или по отдельному полю Time можно рассчитать (на основе нижних агрегатов) различными способами.

Причём, очевидно, что чем больше размерность куба (число элементов в CUBE-предложении), тем больше будет возможностей для выбора наиболее оптимального пути вычисления. А список элементов агрегирования в ЛИНТЕР точно так же как и в Oracle, может достигать 255.

Именно эта простая оптимизация позволила на порядок(!) обогнать Oracle на таких же запросах. Причём, чем большим было число элементов GROUP BY, тем больше был выигрыш.

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

Здесь, конечно же, имеется в виду OLAP-база данных, т.е. база данных, ориентированная на OLAP-приложения. Ещё раз подчеркнём, что речь идёт о специфических данных. В общем случае подобная оптимизация может дать серьёзные отрицательные результаты.

Возможно, уже в ближайшее время РЕЛЭКС может выйти на рынок с новыми продуктами и технологиями обработки данных. Таким образом, мы хотим расширить спектр наших товаров и услуг.

4. Предложение на рынке государственных структур

Так сложилось, что на данный момент на рынке государственных структур и, в частности МО РФ, представлена только Линтер-ВС 6.0 и ещё несколько свободно распространяемых систем.

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

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

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

Компания РЕЛЭКС имеет лицензии на разработку, производство и ремонт средств вооружений и военной техники (ВВТ), лицензию ФСБ РФ на осуществление работ с использованием сведений, составляющих государственную тайну и лицензию Государственной Технической комиссии при Президенте РФ на проведение работ в области защиты информации.

Для обеспечения высокого качества выпускаемой продукции на предприятии внедрена и сертифицирована система качества, соответствующая стандарту ГОСТ Р ИСО 9001.

ЛИНТЕР сертифицирован Государственной Технической комиссией при Президенте РФ на соответствие 2 классу защиты информации от несанкционированного доступа.

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

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

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

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

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

5. Мы работаем для Вас

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

Такая политика позволяет нашим клиентам экономить свое время и средства на обновлении системного и прикладного программного обеспечения.

Если объективно оценивать СУБД ЛИНТЕР, то ее можно отнести к системам среднего класса. Поэтому первый рыночный сегмент, который мы видим для нашей системы - это сервер приложений для автоматизации мелких и средних предприятий. Класс систем может быть практически любым: бизнес-приложения, автоматизация торговой и бухгалтерской деятельности, системы корпоративной безопасности, специализированные аналитические системы и т.п. В этой области мы также предлагаем и прикладное программное обеспечение: ИАС «НЕВОД», решение для синхронизации баз данных DBSync и другие.

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

Второй сегмент - это БД на readonly-носителях с развитыми возможностями индексирования текстовых документов. Такие системы востребованы у производителей информационных баз данных, как правило, распространяющихся на CD-дисках (правовые, экономические БД и т.д.).

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

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

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

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

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

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

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

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

Это всегда хорошо. Это всегда обогащает не только партнеров, но и пользователей. Ради которых, собственно, мы все и работаем.

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

Мы стремимся быть открытыми и по отношению к государству, как гаранту качества. НПП РЕЛЭКС тратит достаточно много ресурсов на сертификацию наших продуктов и качества нашей работы.

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