Мы продолжаем знакомить вас с интересными отечественными IT-компаниями. Сегодня речь пойдет о компании ЗАО НПП «РЕЛЭКС». Данная компания занимается разработкой системы управления базами данных (СУБД) ЛИНТЕР, специализированных версий СУБД и разработкой программного обеспечения особого назначения для государственных и коммерческих предприятий.

ЗАО НПП «РЕЛЭКС» обладает уникальным опытом разработки систем управления базами данных. Разработка собственного продукта СУБД ЛИНТЕР произведена с нуля, не основываясь на уже имеющихся open-source проектах. Система разрабатывается с 1990 года. За это время был выпущен ряд версий продукта, в том числе специализированных. На сегодняшний день на рынке представлено два варианта – ЛИНТЕР БАСТИОН и ЛИНТЕР СТАНДАРТ. ЛИНТЕР БАСТИОН представляет собой СУБД с расширенным набором средств защиты информации (СЗИ), удовлетворяющим сертификации Министерства обороны РФ по 3 классу защищенности от несанкционированного доступа (НСД) к информации и 2 уровню контроля отсутствия не декларированных возможностей (НДВ); и сертификации ФСТЭК России по 2 классу защищенности НСД и 2 уровню контроля НДВ.

«РЕЛЭКС» имеет опыт разработки специализированных версий систем управления базами данных, таких как высокоскоростные read-only СУБД, embedded СУБД, СУБД ограниченного размера для IoT-устройств и др.

Компания занимается разработкой новейшей реляционной СУБД SoQoL, которая предназначена для обработки большого объёма данных и работы с большим количеством пользователей. Разработанный ею MVP показывает кратное преимущество в скорости обработки данных по сравнению с такими СУБД, как  MSSQL, Postgres, Oracle.

Проблема

Существуют ряд проблем, которые связаны с использованием классических реляционных систем управления базами данных (СУБД):

• медленная работа с большими объемами данных,
• масштабирование,
• поддержка работы в облаке.

Исследования последних лет в области управления данными все чаще отмечают проблемы классических реляционных СУБД. Архитектура таких систем сформировалась в 1980-90-х годах. Основные механизмы разграничения доступа к разделяемому ресурсу в то время основывались на принципе взаимного исключения и разделяемого владения, определяемого, как правило, через счетчик ссылок. В СУБД объекты синхронизации, построенные на таких принципах, именуют Latch (защелка). Данные подходы синхронизации хотя и удобны для разработчика тем, что не ломают линейную логику алгоритмов, но плохо масштабируются при работе в многоядерной среде.

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

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

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

Решение

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

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

В СУБД необходимо выполнить следующие правила:

1. Количество активных потоков не должно превышать количества свободных ядер в ОС, отведенных для СУБД.
2. Запрещено переключать контекст исполнения текущей задачи, выполнять любые системные вызовы и производить управление памятью при обращении к неблокирующим контейнерам.
3. Следует избегать длительных вычислительных операций, которые могут увеличить время синхронизации в неблокирующих алгоритмах.

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

Критические секции неблокирующих алгоритмов, связанные с управление памятью, защищаются механизмами с семантикой критических секций типа:

• RCU (Read Copy Update)
• EBR (Epoch Based Reclamation)
• QSBR (Quiescent State-Based Reclamation)

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

Правило 3 можно выполнять и контролировать регламентом разработки.

Для исключения всех вызовов ОС (в правиле 2) из критических секций быстрых алгоритмов необходимо реализовать их асинхронный вызов.

Все управление памяти должно быть переопределено (для исполнения правила 2).

Отсутствие на рынке предложений, хоть в какой-то мере удовлетворяющих сформулированным выше требованиям, привело компанию к необходимости создания собственной платформы, которая:

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

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

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

 

Близкими аналогами являются:

• СУБД с «классическими» подходами обработки данных. Это реляционные проприетарные СУБД Oracle Database, Microsoft SQL Server, IBM DB2, а также СУБД с открытым исходным кодом PostgreSQL, MySQL.
• СУБД, работающие с данными в режиме «всё в памяти». Это MS SQL in-memory OLTP, Tarantool, Redis и аналогичные.
• Специализированные СУБД – графовые, документно-ориентированные и т. п., например, NitrosData, CouchDB.

Преимущества решения компании «РЕЛЭКС»:

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

Ключевые преимущества разрабатываемого продукта

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

• Latch-free техник программирования доступа к общим ресурсам и поддержки NUMA-aware технологий.
• Управляемая невытесняющая мультизадачность на основе корутин, которая позволяет более гибко управлять временем исполнения задач и сокращает затраты на синхронизацию и переключение контекстов. Из указанных аналогов только SQL Server и Tarantool обладают возможностью исполнения корутин.
• Эффективные подходы при обращении к хранимым данным через страничный кэш. Для этого применяются методы контроля доступа к кэшу на основе эпох (EBR) как в
  in-memory решениях. В классических СУБД стоимость обращения к кэшу страниц выше из-за требования блокировки страниц при любых операциях загрузки, чтения, модификации.
• Полноценная AOT-компиляции SQL конструкций и хранимых процедур в нативный код, для динамических пользовательских SQL конструкций применяется JIT-компиляция. Преимущества такой технологии в том, что нативный код выполняется более эффективно, в отличие от пошаговой интерпретации инструкций. Из указанных аналогов AOT-компиляция реализована в SQL Server для in-memory таблиц, частично JIT-компиляция реализована в PostgreSQL, в Tarantool используется LuaJIT, но не поддерживается SQL синтаксис.

Несмотря на прогнозы падения из-за коронакризиса, рынок СУБД в 2020 году по данным аналитического агентства Gartner составил 64,8 млрд долларов США и вырос на 17,1%. Рост сегмента реляционных СУБД составил 15,2%. Ожидается, что к 2027 году рынок СУБД составит 142,7 млрд долларов США по прогнозам компании Research and Markets. По прогнозам The Business Research Company, мировой объем рынка СУБДв 2030 году может составить 172,6 млрд долларов США.

Компания «РЕЛЭКС» вложила в исследования и разработку порядка 106 млн.руб. Общая сумма требуемых инвестиций для завершения разработки и вывода продукта на рынок составляет 170 млн. руб.

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