СУБД реального времени

Согласно данным аналитической платформы Statista, объем сгенерированных данных в 2025 году вырастет на 23% по сравнению с 2024 годом и достигнет 181 зеттабайт. Причины — развитие технологий Интернета вещей, социальных сетей, систем глобального и локального позиционирования, облачных технологий, искусственного интеллекта, автоматизация и роботизация производства, систем массового обслуживания и мобильных технологий. Стремительное увеличение объемов генерируемых данных предъявляет новые требования к скорости их обработки — классические «дисковые», универсальные базы данных старались преодолеть ограничения на объемы хранимых данных и скорость обработки с помощью вертикального масштабирования и ускорения работы отдельных элементов системы. Одновременно началось развитие СУБД по альтернативным направлениям:

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

кластеры серверов баз данных с распределением нагрузки между узлами, а затем и системы массово-параллельной обработки (MPP), позволившие обеспечить почти линейное увеличение производительности кластера за счет добавления дополнительных серверов; яркими примерами MPP стали технологии Hadoop и Greenplum;

появились СУБД, построенные на принципе резидентности (In-Memory — «работа в памяти»), позволяющем избежать задержек при обращении к дисковой подсистеме сервера за счет размещения данных и модулей их обработки в оперативной памяти.

СУБД In-Memory

Помимо стандартных требований для всех СУБД (целостность, отказоустойчивость, удобство доступа и упрощение разработки программного обеспечения), главное требование для резидентных баз данных — обработка данных в режиме реального времени. Обычное время ожидания выполнения запросов для таких СУБД должно измеряться в единицах миллисекунд, в отличие от дисковых баз, для которых характерное время отклика — на два порядка больше. Такая производительность требуется в системах навигации и управления, производственной автоматизации, решениях ИИ, роботизации, инфраструктурах массового обслуживания, в которых критически важно уметь «на лету» обрабатывать большие объемы данных. Однако размещение всей базы данных целиком в оперативной памяти одного даже очень мощного компьютера — задача трудновыполнимая. Современные серверы работают с объемами оперативной памяти до нескольких терабайт — этого достаточно только для небольших баз. Кроме этого, оперативная память энергозависима и все хранимые в ней данные теряются при отключении питания.

Для обработки баз размером в несколько десятков терабайт при одновременном требовании ко времени отклика в несколько миллисекунд логично разбивать базу на части и размещать их в оперативной памяти нескольких серверов (узлах кластера серверов). Необходимо обеспечить параллельную обработку данных на разных серверах, обмен данными и результатами вычислений. Нельзя забывать и про отказоустойчивость: при отключении питания одного или нескольких серверов данные не должны теряться, а вся система должна оставаться работоспособной. Все это и есть принципы построения СУБД, которые называются резидентными решетками данных (In-memory Data Grid, IMDG).

Резидентная решетка данных (IMDG)

Модель IMDG (см. рис.) объединяет принципы резидентности с массовой параллельной обработкой данных (MPP), а соответствующая СУБД размещается в кластере серверов, использующих свою оперативную память для совместной, согласованной и параллельной обработки данных.

Данные «на лету»

В 2008 году компания Mail.ru инициировала создание собственной резидентной базы данных, использующей гибкую схему для эффективного создания высоконагруженных приложений. СУБД получила название Tarantool и состояла из собственно базы данных, а также сервера приложений на языке Lua. Спустя десять лет руководитель команды разработки ядра Tarantool Константин Осипов создал собственную ветку разработки резидентной базы данных — СУБД Picodata.

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

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

• периодическое обновление снимков базы данных (snapshot) на диске;
• Raft — алгоритм для решения задач консенсуса, который обеспечивает безопасную и эффективную реализацию машины состояний поверх кластерной вычислительной системы;
• упреждающая журнализация — техника обеспечения атомарности и устойчивости баз данных (двух ключевых свойств ACID) посредством ведения отдельной от базы данных упреждающей журнализации (write-ahead log), при которой информация об изменениях в базе данных вносится и фиксируется перед записью в базу данных.

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

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

Одно из преимуществ резидентных решеток данных — соединение данных и вычислительного слоя. В классической трехзвенной архитектуре «веб-сервер — сервер приложений — сервер базы данных» приложения обычно обращаются к серверу СУБД для выполнения действия с данными. Для одной бизнес-операции могут потребоваться десятки таких запросов, поэтому скорость будет определяться скоростью доступа к серверу и пропускной способностью сетевого соединения. В случае с резидентными решетками вычисления выполняются с данными, хранящимися в оперативной памяти узла кластера, что исключает задержки, связанные с обращением к серверу. В Picodata обработку данных выполняют специальные плагины на языке Rust. Модульность кода, расширяемость системы за счет плагинов, а также наличие большой экосистемы библиотек языка Rust (crate — крейт) позволяют упростить и ускорить разработку бизнес-логики. На сегодняшний день в библиотеке имеется более 150 тыс крейтов.

Сферы применения

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

Сегодня эту СУБД можно использовать для миграции высоконагруженных, критических для бизнеса приложений, построенных на платформах ушедших с российского рынка производителей (Oracle, Microsoft). Для этого имеется, например, модуль Picodata Synapse поддержки переноса бизнес-приложений с Oracle на PostgreSQL, выполняющий не только копирование данных, что само по себе нетривиальная задача, но и перенос структуры базы и встроенного кода, а также модификацию исходного кода самого приложения с его последующей отладкой и тестированием. Часто такой проект может растянуться во времени, однако можно не прерывать работу исходной системы — Picodata Synapse делает начальное копирование данных из Oracle, например, в Arenadata Postgres, а затем на протяжении всего периода миграции поддерживает процесс обмена изменившимися данными. Пользователей и бизнес-процессы можно переносить из одной системы в другую постепенно, обеспечивая непрерывность, — в этом случае проект миграции пройдет относительно безболезненно для бизнес-пользователей и бизнес-процессов предприятия.

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

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

Текущее и будущее

Развитие СУБД Picodata сегодня идет по следующим направлениям:

• повышение информационной безопасности и защищенности: авторизация запросов, основанная на списках контроля доступом (Access Control List, ACL), журнал аудита безопасности, безопасное затирание файлов инстанса при их удалении, усиление требований к сложности паролей в соответствии с требованиями к сертификации СУБД;
• коннекторы к корпоративным системам и приложениям (Kafka, Oracle, PostgreSQL), а также плагина Synapse переноса данных из кластера Oracle Exadata в кластер PostgreSQL;
• поддержка РЕД ОС, Альт Линукс, Астра Линукс, ОС РОСА;
• повышение надежности работы кластера и восстановление после сбоев: аварийное переключение лидеров репликасетов (ReplicaSet — процесс, запускающий несколько экземпляров групп контейнеров Kubernetes и сохраняющий их число постоянным), внедрение механизма консенсуса Raft;
• совершенствование аппарата администрирования (веб-интерфейс, приложение обеспечения синхронизации доменных пользователей и групп пользователей LDAP с пользователями и ролями Picodata, повышающее удобство использования СУБД и экономящее усилия системных администраторов при импорте пользователей и ролей);
• упрощение работы пользователей и разработчиков (кластерный распределенный SQL, пользовательская SQL-консоль для выполнения распределенных запросов во всем кластере, поддержка сложных запросов при работе с глобальными таблицами, поддержка хранимых процедур, интерфейс RPC API — основной интерфейс взаимодействия с инстансом Picodata, модуль Pgproto подключения к кластеру Picodata по протоколу PostgreSQL, и пр.).

Кроме того, создается программно-аппаратный комплекс «Машина больших данных Скала^р МБД.Т» для платформы Picodata — готовое решение для быстрой обработки и надежного хранения сверхбольших объемов «горячих» данных.

СУБД Picodata представлена в редакциях Community и Enterprise. Первая распространяется под лицензией BSD (Berkeley Software Distribution license), не ограничивающей порядок использования СУБД, гарантирующей отсутствие привязки к производителю и открытость продукта. Вторая предлагает расширенные возможности интеграции с проприетарным ПО и поддержку 24/7.

***

Picodata — распределенная, резидентная, высокопроизводительная СУБД для управления базами данных с возможностью расширения функциональности за счет плагинов на языке Rust. В СУБД поддерживается хранение структурированных и неструктурированных данных, транзакционное управление ими и язык SQL. Все данные хранятся в оперативной памяти, а их сохранность обеспечивается благодаря периодическому обновлению снимков базы данных на диске, алгоритму Raft для решения задач консенсуса, а также записи информации о транзакциях в журнал упреждающей записи (WAL-файлы). СУБД Picodata позволяет решить проблему увеличения нагрузки на СУБД или бизнес-приложение, обрабатывая и анализируя данные в режиме реального времени, а также используя интеллектуальную шину обмена данными между приложениями. Кроме этого в СУБД предусмотрены средства миграции с СУБД Oracle без остановки бизнес-процессов.

Василий Демин (v.demin@arenadata.io) — менеджер по продуктовому маркетингу, компания Arenadata; Дмитрий Родионов (d.rodionov@picodata.io) — ведущий разработчик, компания Picodata (Москва).