СУБД "Линтер"

"Линтер"... Похоже на "литр", вам не кажется? Да, звучит определённо похоже. Ничего удивительного в этом нет: эту систему управления базами данных (СУБД) написали россияне, а тяга к литрам славянских душ наших восточных соседей вошла не только в фильмы и анекдоты, но даже в фольклор других народов.


Что умеет "Линтер"

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

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

Как и все СУБД, "Линтер" умеет удалять, изменять и добавлять объекты базы данных: индексы, таблицы, хранимые процедуры, триггеры. Ну и сами данные, конечно же. Будучи реляционной СУБД, "Линтер" позволяет использовать язык SQL. Можно работать с большими (до 2-х гигабайт) BLOB-полями, импортировать/экспортировать данные из/в ASCII и DBF файлов с помощью встроенных в СУБД средств. Также можно блокировать/деблокировать доступ к таблице/записи, можно использовать различные режимы обработки транзакций, причём как в приложениях, использующих "Линтер", так и в хранимых процедурах. СУБД, по заверениям её разработчиков, позволяет также "организовывать (и использовать) гибкую и надежную систему безопасности и секретности информации (сертифицирован Государственной технической комиссией при Президенте РФ на соответствие 2 классу защиты информации от несанкционированного доступа, что соответствует уровню B3 по американскому национальному стандарту orange book)". Но о безопасности я ещё немного расскажу ниже.

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

Сама по себе СУБД, конечно, вещь, спору нет, полезная. Но без пользовательских приложений, осуществляющих доступ к данным, её полезность сокращается в разы. "Линтер" имеет множество API для взаимодействия с внешними приложениями. Есть интерфейсы (сиречь драйверы) для ODBC 3.x, OLE DB, а также специализированные библиотеки для разных языков программирования и средств разработки: Perl, PHP, dbExpress (интерфейс для прямого доступа к СУБД "Линтер" из популярных средств разработки Delphi/Kylix/C++ Builder); JDBC 1.0, 2.0, 3.0; Lintcl (интерфейс для поддержки tcl/tk), (LinPy - интерфейс для доступа к данным из Python). Есть даже Oralin - интерфейс для использования СУБД "Линтер" из программ, разработанных с использованием OCI интерфейса СУБД Oracle. Ну а для любителей острых ощущений есть LinApi - интерфейс низкого уровня, предназначенный для подготовки сложных программ на языке C. В программах, использующих вызовы этого интерфейса, можно использовать оттранслированные, асинхронные запросы, приоритеты запросов и так далее, и тому подобное.

Что ещё я не упомянул из возможностей "Линтер"? Кажется, поддержку иерархических транзакций, полнотекстовую индексацию различных типов документов (включая индексацию XML-документов), поддержку национальных кодировок и UNICODE, поддержку расширений СУБД Oracle (SEQUENCE, JOIN и т.д.), возможность синхронизации данных между различными базами данных (в том числе и на карманных персональных компьютерах), двунаправленную репликацию с широкими возможностями разрешения конфликтов. Кроме этого, СУБД "Линтер" обладает впечатляющей кросс-платформенностью: поддерживаются Windows, Novell NetWare, UNIX в ипостасях SV, SCO, BSD, UNIXWARE, LINUX, USIX; OS/9000, OS/9, OpenVMS, Solaris и QNX.

Теперь немного цифр. База данных для "Линтер" может содержать до 65535 таблиц каждая объёмом до 12 Тб, количество записей в одной таблице - до 1 миллиарда, размер записи - до 64 Кб (не считая, конечно же, BLOB-полей), количество полей в записи - до 250. Минимальный объём памяти, занимаемой ядром СУБД - 3 Мб, типы данных: Char, Varchar, Nchar, Nchar Varying, Byte, Varbyte, Boolean, Smallint, Integer, Bigint, Real, Double, Numeric, Date, Blob, Extfile. Поддерживаемые сетевые протоколы: TCP/IP (в том числе и SSL), SPX, NetBios, Named Pipes.

Неплохо, не так ли?


Безопасность баз данных СУБД "Линтер"

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

На самом же деле, в СУБД "Линтер" политика безопасности реализуется с помощью двух основных подсистем: подсистемы управления доступом к информации и подсистемы поддержания высокой готовности информации. Авторизация пользователей производится при установлении соединения с системой. Проверке подлежит регистрационное имя пользователя и его пароль. Если процесс авторизации пользователя прошел успешно, то все дальнейшие запросы к СУБД по данному соединению однозначно связываются с данным пользователем. Контроль доступа к информации проходит любой запрос на доступ к любым объектам базы данных. Отметка о прохождении запроса (удачном/неудачном) может протоколироваться в журнале системы защиты. При этом используются критерии дискреционной и мандатной защиты. Что это значит?

Дискреционная защита - аппарат привилегий, которые можно подразделить на две категории: привилегии безопасности (позволяют выполнять административные действия) и привилегии доступа (определяют права доступа конкретных субъектов к определенным объектам). Привилегий безопасности три: администратор базы данных, привилегированные пользователи БД и пользователи БД. Ясно, что эти разные категории пользователей имеют разные права. Что касается привилегий доступа, то они таковы: SELECT - на выборку данных; INSERT - на добавление данных; DELETE - на удаление данных; UPDATE - на обновление данных; ALTER - на изменение параметров таблицы; INDEX - на создание/удаление индексов; ALL - включает все перечисленные права доступа. Привилегии можно объединять в роли.

Мандатная защита состоит в назначении различных уровней ценности для всей хранимой информации. Для этого в СУБД "Линтер" используются метки доступа. Метка доступа состоит из трех частей: группы доступа (именованная совокупность пользователей) и двух уровней доступа. Метки доступа могут быть назначены всем субъектам базы и объектам: начиная от таблиц и до полей записей включительно.

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

Протоколирование работы (авторы СУБД назвали эту функцию "системой слежения "Линтер") - это контроль функционирования подсистемы защиты, обнаружения попыток несанкционированного доступа, исправления их последствий и предотвращения их в будущем. В журнал системы безопасности заносятся следующая информация: отметка времени, имя пользователя, имя объекта, группа события, тип события, статус завершения "Линтер". Кроме того, сюда же заносится дополнительная информация о клиентской станции (сетевой адрес, PID клиента, сокет клиента), с которой пришел запрос. Стоит ли напоминать о том, что регулярный мониторинг журнала системы безопасности позволяет поддерживать надежность системы защиты на высоком уровне и своевременно реагировать на попытки обойти систему защиты?

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

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


Что ещё есть в этой СУБД?

Много всего есть того, о чём я не смогу сейчас рассказать по той простой причине, что газетная статья, к сожалению, не резиновая. К счастью, с сайта www.linter.ru можно скачать демо-версию СУБД "Линтер" и со всем ознакомиться самостоятельно. Тем не менее, кратко по некоторым ещё не упомянутым мною моментам я всё же пройдусь.

По словам разработчиков, "Линтер" - легко встраиваемая система. Программа установки прикладного приложения может легко установить все необходимые для функционирования СУБД файлы и одновременно настроить её. Таким образом, в качестве встраиваемой СУБД разработка россиян действительно может быть весьма неплоха. Также в "Линтер" реализован механизм поддержки резервных серверов, обеспечивающий высокую надёжность и производительность горячего резерва. При сбое в работе основного сервера время перехода резервного сервера в режим основного составляет всего несколько секунд. Кроме того, в СУБД реализованы геометрические типы данных, которые позволяют работать с географическими данными, создавать их, сохранять и анализировать, что удобно для разработчиков геоинформационных систем. Также, по словам разработчиков, "Линтер" эффективно функционирует в условиях ограниченности ресурсов, в том числе и на карманных персональных компьютерах под управлением Windows CE. На этой платформе СУБД может работать не только в качестве клиента, но и в качестве полноценного сервера базы данных.

Подводя итоги, можно сказать, что разработка российских программистов, как минимум, интересна. Если же принять во внимание все её возможности, а особенно то, что она сертифицирована как надёжный и устойчивый программный продукт, то это действительно реальный конкурент таким промышленным гигантам, как Oracle или Microsoft SQL Server. Поэтому "Линтер" следует иметь в виду при разработке приложений, работающих с данными. В любом случае, ознакомиться с этой СУБД действительно стоит.

Вадим СТАНКЕВИЧ

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

Номер: 

35 за 2007 год

Рубрика: 

Software
Заметили ошибку? Выделите ее мышкой и нажмите Ctrl+Enter!

Комментарии

Страницы

Аватар пользователя Инкогнито
>Настоящий Полковник

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

По поводу кол-ва записей то понимаю. Но кто-то великий предлагал когда-то идентификатор делать буквенный. Это не вы?

Есть такое правило. ВСЁ ГЕНИАЛЬНОЕ ПРОСТО.

Раньше компьютеры были большие, а программы были маленькие, а теперь наоборот.

Если вам мало полей, то извиняйте. Есть поля BLOB -в них и храните всё что душе надо если не умеете проектировать. А есть ещё классное средство от желающих хранить файлы в базе -это ссылка на них

Аватар пользователя Настоящий Полковник
>>Инкогнито

15 октября 2007 года, 22:17

>>>Настоящий Полковник

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

Вы не поверите, продумывал, продумываю и буду продумывать.

Скажите разработчикам Oracle, MSSQL, Sybase - зачем они больше сделали. ;)

>>Наверное может слышали о нормальных формах.

Вы теоретик? Ну-ну. Нормализируйте дальше. Независимо от необходимой функциональности и логики.

>>Приведите примеры проектов в которых нужно больше 255 полей?

Уже приводил. У меня такой проект. И городить еще одну таблицу, куда надо будет запихивать те поля, которые в 255 не уложились - это полный маразм. А потом делать лишние join'ы.

>>По поводу кол-ва записей то понимаю.

О, не все, значит, потеряно.

>>Но кто-то великий предлагал когда-то идентификатор делать буквенный. Это не вы?

Нет, я такую глупость не мог предложить.

Например, некоторые используют GUID. ;) Только иногда сортировку надо делать нормальну. Например, по мере добавления записей. И не говорите, что лучше вводить поле типа Date - там не все так хорошо - милисекунды, однако, и значения могут совпадать. Нечасто, но могут. А на допущениях я системы не строю.

>>Есть такое правило. ВСЁ ГЕНИАЛЬНОЕ ПРОСТО.

Вот именно. И возможность в таблице иметь больше 255 полей - именно просто. А не городить огород и извращаться.

>>Раньше компьютеры были большие, а программы были маленькие, а теперь наоборот.

Это вы к чему? Для "красного словца"?

>>Если вам мало полей, то извиняйте.

Мне достаточно на MSSQL, Oracle, Sybase. Там их намного больше, чем 255. В современных версиях, конечно. ;)

>>Есть поля BLOB -в них и храните всё что душе надо

Вы извращенец? Float (Double), Varchar, Date (Datetime) хранить скопом в BLOB? ;) Еще что-нибудь придумайте. А индексировать как? Опять извращаться или использовать всякие прибамбасы типа Full Text Search? ;)

>>если не умеете проектировать.

"Яйца курицу учат"? ;)

>>А есть ещё классное средство от желающих хранить файлы в базе -это ссылка на них

А это к чему? Вы сами поняли, что хотели сказать?

Файлы в базе - это хорошо или плохо? ;)

Давайте еще что-нибудь скажите умное.

Аватар пользователя Настоящий Полковник
Кстати, Инкогнито, у вас сколько в компьютере памяти стоит? 2Гб? А зачем вам столько? 1Гб хватит. Настроить и оптимизировать систему не можете, чтобы хватало?

У вас 1Гб? А зачем вам столько? 512 хватит. ;)

Жесткий диск какого объема? 40Гб? ;) Зачем столько? 10 хватит. Разместить и упорядочить данные не умеете, чтобы хватало места?

Дальше продолжать? Аналогия понятна? ;)

Аватар пользователя Настоящий Полковник
Чтобы было понятнее, что такое "воинствующая безграмотностьь", приведу пример моего диалога с одним "продвинутым" человеком, который явно много начитался специальной литературы и трепетно относился к нормализации базы. ;)

Он - один из разработчиков аналогичной системы, как у меня. В такого класса системе очень важно быстроджействие - поиск по базе и массированный fetch для вычислений. Их система на определенном обхеме производила поиск и вычисления за 20 минут. Использовалась Oracle 9.x.

Моя система на Sybase ASA 9 укладывалась в 1-2 минуты. Они попросили проконсультировать по поводу повышения производительности их системы (есть некоторая партнерская договоренность).

И вот обсуждение-переписка:

Я (12:20) :

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

Я (12:21) :

они у вас в принципе отсутствуют, насколько я мог судить по 70 и 100 тысячным тестовым базам

Я (12:21) :

создаете поле новое - индекс на него

Он (12:21) :

и на каждое поле в каждой таблице идекс?

Я (12:21) :

если где-то используется order by для получения списка - составной индекс на поля, там указанные

Я (12:21) :

да

Я (12:22) :

попробуйте и увидите

Я (12:22) :

почему-то многие считают, что ораклу индексы не нужны.

Он (12:22) :

нужны - но РАЗУМНЫЕ

Я (12:22) :

есть даже категория специалистов по так называемому "тюнингу" оракла. ИНДЕКСЫ НАДО ИСПОЛЬЗОВАТЬ

Я (12:23) :

а не кеши подстраивать

Он (12:23) :

при наличии индексов по всем полям мы выиграем в поиске, но катострафически потеряем во вставке и обновлении.

Я (12:23) :

ничего вы не потеряете

Он (12:23) :

ладно, я считал вас грамотным специалистом, похоже я ошибся.

Я (12:23) :

в 2 сек по обычному стандарту отклика системы всегда уложитесь

Я (12:24) :

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

Он (12:24) :

хорошо, думаю не имеет смысла продолжать наш разговор.

Я (12:24) :

и не поможет вам ни C++, ни Oracle

Он (12:24) :

спасибо, до свидания.

Я (12:25) :

до свидания

Аватар пользователя Инкогнито
Хех, если данные выбираются в разы чаще, чем вставляются, где там можно катастрофически потерять на вставке? :-)

100 тысяч это смешно, вот backtesting алгоритмов на исторических биржевых данных накопившихся за несколько лет, вот это весело.

Аватар пользователя Настоящий Полковник
>>100 тысяч это смешно, вот backtesting алгоритмов на исторических биржевых данных накопившихся за несколько лет, вот это весело.

100 тысяч выборок из blob-полей и обработка хранимых в них массивов.

100 тысяч - это не предел. Планируются миллионы и десятки миллионов.

Аватар пользователя Настоящий Полковник
И полная история всех изменений и обработок. Т.е. полная версионность всей системы. Никаких hard-delete, только soft-delete.
Аватар пользователя Настоящий Полковник
>>backtesting алгоритмов на исторических биржевых данных накопившихся за несколько лет, вот это весело.

Точно. Особенно на Линтере с ограничением в 1 миллиард записей в таблице. ;)

Аватар пользователя Настоящий Полковник
>>Хех, если данные выбираются в разы чаще, чем вставляются, где там можно катастрофически потерять на вставке? :-)

Забыл прокмментирвать.

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

Аватар пользователя Инкогнито
>Настоящий Полковник

По поводу нормальных форм. Ну к 3-ей нормальной форме вы хоть приводите :)

А по поводу быстродействия (вы приводили выше), то вам наверное известно что SyBase обгоняет Oracle на одинаковом оборудовании.

Как пишет Майкл Стоунбрекер в одной из статей (Computerworld Россия, 25 сентября 2007) что при столбцовых записях а не строковых -скорость возрастает до 50 раз.

(Наверное вы понимаете о чём я пишу)

А если вы не можете вычленить ключевые поля для поиска, то строите индексы по всей базе, это увеличит её в сотни раз. Теперь понятно что база в 100 Гб -разрастается в 2 Тб. Я думаю по 2-м Тб проще бегать.

Если данные имеют непостоянную структуру, то используют XML

Страницы