E-mail:
Пароль:
Забыли пароль?

Новые возможности СУБД ЛИНТЕР

Егоров Алексей, Ермаков Михаил

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

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

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

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

Одним из крупных изменений является реализация кэша результатов выполнения запросов. Он выполнен на двух уровнях: кэш самих оттранслированных запросов и кеш результатов.

Кэш результатов запросов предназначен для кэширования результатов выполнения select-запросов, в тексте которых присутствует хинт ANSCACHE.

Пример:

select id, ch from test /* +ANSCACHE */;

Кэширование построено на побайтном сравнении претранслированных запросов: если пришедший от пользователя или от транслятора SQL претранслированный запрос и претранслированный запрос, хранящийся в элементе кэша результатов запросов, одинаковы, то для выдачи результата выполнения запроса используется элемент кэша результатов запросов.

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

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

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

Например, можно выполнить запрос для системной таблицы под пользователем SYSTEM

select * from $$$SYSRL

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

select * from SYSTEM.$$$SYSRL

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

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

Было улучшено квантование вычисления предикатов IN/NOT IN в отсутствие индексов.

Предположим, у нас есть запрос с предикатом

SELECT что-то FROM T1 WHERE T1.C1 IN (SELECT T2.C2 FROM T2 WHERE условие2) AND ...
и оба столбца T1.C1 и T2.C2 не индексированы,

При не индексированных столбцах T1.C1 и T2.C2 вычисление предиката превращалось в двойной цикл обхода, что может быть на несколько порядков медленнее, чем если бы был хотя бы один индекс.

Нами в данном случае применяется адаптивный алгоритм, который вычисляет нагрузку на ядро и адаптирует квантование вычисления проверки попадания значений T1.C1 в набор значений T2.C2. Благодаря внесенным изменениям в квантование удалось существенно увеличить скорость выполнения запросов, показанных в примере.

Для сокращения времени обработки запросов в больших циклах, было улучшено квантование обработки запросов, которые требуют перенумерации ответов, это преимущественно запросы к VIEW и содержащие подзапросы во FROM-конструкциях. Это позволило значительно сократить время обработки запросов. Была добавлена функциональность пользовательских сообщений в AUDIT. Разрешается однократная запись пользовательского сообщения с заданным текстом и маркировка всех сообщений от текущего соединения заданным текстом в поле USERTEXT.

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

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

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

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

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

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

Доработано использование хинта /* +LAST */ для предиката BETWEEN, проведена оптимизация скорости выполнения запросов.

Рассмотрим процесс выполнения запроса

select TABLE_1.NAME
   from TABLE_1,TABLE_2
where
   TABLE_1.id between 10 and 1000000 /* +LAST *//* много записей */
   and TABLE_1.id = TABLE_2.id
   and TABLE_2.id > 25;                          /* +LAST *//* много записей */

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

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

На этапах разработки часто требуется возможность удаления столбца таблицы. Мы решили пойти на встречу пожеланиям пользователей, хотя и считаем, что на стадии эксплуатации эта функциональность не играет принципиальной роли, и добавили возможность удаления столбца таблицы, в том числе каскадного. Разрешены выражения, в том числе и неконстантные, в стандартной конструкции DEFAULT. Разрешена конструкция «GENERATED BY DEFAULT (выражение)». Для столбцов GENERATED BY DEFAULT или имеющих DEFAULT-выражения реализована такая же возможность удаления и модификации этих выражений, как и для константных DEFAULT-значений.

Для расширения был введен оператор MERGE. Иногда возникает потребность в передаче множества строк из таблицы, обновлявшейся при выполнении транзакции (транзакционной таблицы), в некоторую основную таблицу базы данных. Обычно транзакционная таблица содержит обновленные варианты строк, существующих в основной таблице, а также, возможно, новые строки, которые должны быть занесены в основную таблицу. При наличии традиционных средств обновления базы данных содержимое транзакционной таблицы может быть перенесено в основную таблицу путем выполнения двух отдельных шагов. На первом шаге требуется выполнить оператор UPDATE для всех строк основной таблицы, для которых имеются модифицированные “двойники” в транзакционной таблице. Затем нужно выполнить оператор INSERT для занесения в основную таблицу всех строк транзакционной таблицы, для которых таких двойников нет. Оператор MERGE, позволяет выполнить такую операцию за один шаг. Была введена конструкция IF NOT EXIST при выполнении CREATE запроса для всех объектов, которые могут быть созданы. В случае наличия в базе данных объекта с тем же именем никаких действий произведено не будет и запрос не вернёт кода ошибки. В случае отсутствия в базе данных объекта с тем же именем объект будет создан.

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

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

Была добавлена возможность управлять закрытием подчиненных курсоров в командах COMMIT и ROLLBACK, опция RELEASE.

Пользователи сталкивались с тем, что большие запросы выходили иногда за рамки наших ограничений. Была проведена оптимизация, была изменена внутренняя структура буферов транслятора SQL, введен дополнительный буфер для временных структур вследствие чего размер этих запросов был существенно уменьшен до 30%.

Ранее память, используемая каналом, составляла 64К, из них часть занимает оттранслированный запрос, часть занимают его данные и часть занимают временные рабочие данные. Сейчас временные рабочие данные вынесены за этот предел, и они не имеют принципиальных ограничений и их размер указывается в настройках. Теперь вся временная память, которая используется запросом не входит в ограничение и ошибку 812, если при трансляции запроса сразу не получили, то потом никогда и не получите.

С помощью SQL-запросов можно теперь напрямую работать с данными типа BLOB. Можно добавлять, изменять и удалять значение BLOB. Приведу пример.

Создадим таблицу test с колонкой BLOB и вставим в него значение.

create or replace table test(bl blob character set "UCS2");
insert into test(bl) values('0123456789 aaa 0123456789');
select lenblob(bl), getblobstr(bl, 1, 60) from test;
| 50|0123456789 aaa 0123456789.....|

Далее вставим в поле bl, начиная с 3-ей позиции длиною в 10 байт, с заменой удаляемого текста символами ‘аа’

update test set bl=insert(bl, 3, 10, 'aa');
select lenblob(bl), getblobstr(bl, 1, 60) from test;
| 50|0aa 6789 aaa 0123456789.....|
update test set bl=insert(bl, 23, 6, HEX('31003100310031003100'));
select lenblob(bl), getblobstr(bl, 1, 60) from test;
| 50|0aa 6789 111 0123456789.....|

Вернемся к первоначальному значению поля bl. Посмотрим как работает функция замещения символов.

update test set bl=replace(bl, '12345', 'jjj');
| 50|0jjj 6789 aaa 0jjj 6789.....|
|update test set bl=replace(bl, HEX('37003800'), HEX('780078007800'));
select lenblob(bl), getblobstr(bl, 1, 60) from test;
| 50|0jjj 6xx9 aaa 0jjj 6xx9.....|

Возможность редактирования полей типа BLOB в sql-запросах может быть очень полезным при большом объеме работы с данными этого типа.

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

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

Размер сообщений, которыми обмениваются компоненты СУБД, увеличен до 64K.

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

Была реализована поддержка операций над интервальным временем.

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

Для интервального времени разрешены операции:

  1. вычисление интервала времени между значениями типа «дата-время».
  2. сложение/вычитание интервалов времени с числовыми значениями и интервалами времени.
  3. умножение/деление интервалов времени на числовое значение и на интервал времени.

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

Общеизвестно, что ЛИНТЕР является кроссплатформенным СУБД и поддерживает более 20 операционных систем. За последние эти годы мы существенно продвинулись в поддержке новых современных и развивающихся операционных систем. У нас появилась поддержка операционной системы реального времени RTOS-32, разрабатываемой компанией On-Time и используемой такими гигантами как Motorola, Xerox и многими другими. Кроме того, поддержаны современные развивающиеся платформы iOS, Android, Maemo, Astra Linux, Linux XP. Мы двигаемся в ногу со временем и при выходе новых версий операционных систем мы адаптируемся и тестируемся под них. Так же поддерживаются 64 битные версии платформ.

В поддержке программных интерфейсов мы тоже не стояли на месте. В интерфейсе ADO.NET были внесены значительные изменения. Была добавлена поддержка Mono 2 в Linux, добавлена поддержка Mono Developer 2, доработан код LINQ-провайдера. Была добавлена поддержка Nhibernate, и .NET 4. Добавлена интеграция с Microsoft VS и поддержка LINQ.

Так же набор поддерживаемых интерфейсов расширился за счет поддержки интерфейса Ruby и средств разработки Ruby on Rails.

В интерфейсе LINPHP добавлена опция автоматического получения значений BLOB-полей таким же образом, как и полей всех остальных типов. Реализовано получение BLOB-значений из курсора, возвращаемого хранимой процедурой. Добавлена возможность BIND для BLOB-значения. Оптимизирована работа с БД путем исключения лишних вызовов. Добавлена возможность настройки преобразований параметров через файл php.ini. Добавлены новые интерфейсы PDO и ADO. Добавлена поддержка новых версий PHP (5,6)

В интерфейсе Perl были добавлены функции для работы с несколькими BLOB-столбцами и некоторые ранее отсутствующие функции для работы с BLOB. Внесены изменения в функцию BLOBGetSize — теперь эту функцию можно вызывать и как прежде, и с указанием номера столбца. Доработан интерфейс для 6-й версии, была добавлена функция, возвращающая информацию о соединении в виде массива; добавлена функция установления кодировки; добавлена функция, использующая команду пакетного чтения записей; добавлены функции, позволяющие получать данные обо всей записи сразу в виде массива и в виде хеша, а также обо всех записях ответа; в GetColInfo – возвращается больше информации о столбце в виде хеша; обновлён .pm файл – описание работы с расширением.

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

Совсем недавно была разработана поддержка компонента ORM eXpress Persistent Objects от компании DevExpress.

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

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

Доработан парсинг комментариев. Реализовано включение графиков SYSTEM_TIME и USER_TIME в окне статистики.

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


Возврат к списку

ѕрокрутить вверх