Всем привет!
 
В этом посте хотим поговорить с вами о возможных вариантах использования SoQoL.
 
Система управления базами данных — это межотраслевое системное программное обеспечение. С одной стороны это хорошо — нет никаких ограничений для применения, может использоваться в любой отрасли народного хозяйства, с другой стороны плохо — ведь размывается эффективность конкретного применения.
 
Какие отличительные особенности есть у СУБД SoQoL?
Это:
- высокая производительность — кратно быстрее аналогов. Как возражение — в конкретной задаче с конкретными условиями результаты могут значительно отличаться. Но Время в среднем просуммирует и вынесет объективную историческую оценку;
- максимально эффективное использование аппаратных ресурсов. Тут мы выжимаем максимум на современных алгоритмах и подходах, созданных для современных аппаратных архитектур.

И всё это в сочетании с тем, что это полноценная (не специализированная) транзакционная реляционная СУБД с поддержкой ACID, стандарта ANSI:SQL и процедурным языком по типу PL/SQL.

SoQoL потенциально может показать свою эффективность в таких приложениях, как:
- АСУ ТП;
- учётные системы;
- PLM, MES, CRM системы;
- автоматизированные системы расчетов (биллинг);
- системы обработки финансовых сообщений;
- системы дистанционного банковского обслуживания;
- и многие другие системы, где требуется OLTP СУБД (возможно с последующей поддержкой OLAP).
Почему «потенциально»? Потому что он еще не везде используется.

А какие области применения вам кажутся наиболее благоприятными для СУБД SoQoL? Где бы мы могли максимально помочь компаниям в их задачах обработки данных? Что, по вашему мнению, может привлекать компании в SoQoL, в чем его ценность? Что лично вас привлекает?

Сегодня мы поговорим о команде ALTER DATABASE, которая используется для изменения свойств базы данных. Каждая СУБД имеет свои уникальные особенности и возможности при использовании этой команды, например:

1. Oracle
В Oracle команда ALTER DATABASE позволяет администраторам изменять параметры базы данных, например, такие как имя базы данных, режим ARCHIVELOG для ведения журналов архивации, параметры хранения данных и т.д. Команда ALTER DATABASE в Oracle также позволяет управлять ресурсами базы данных, устанавливать параметры кэширования и оптимизации запросов.

2. MS SQL Server
В MS SQL Server команда ALTER DATABASE предоставляет широкий набор возможностей: с её помощью можно изменить имя базы данных, установить режим восстановления (например, SIMPLE, FULL или BULK-LOGGED), изменить размер файлов базы данных, добавить или удалить файлы данных или файлы журнала транзакций. ALTER DATABASE в MS SQL Server также позволяет управлять параметрами безопасности и авторизации базы данных.

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

4. В SoQoL команда изменения базы данных имеет следующий синтаксис:

ALTER DATABASE [<имя_базы_данных>] SET <имя_опции> = <значение_опции>

Она позволяет указать новое значение заданной опции для БД.

Также имеется команда ALTER DATABASE [<имя_базы_данных>] checkpoint, создающая контрольную точку в БД на момент выполнения команды.

Более подробно опции описаны в разделе "11.1 CREATE DATABASE" документации SoQoL. Они позволяют управлять:
- синхронизацией с диском изменений БД при завершении транзакций (обнаружили, что тут в документации написано как-то коряво, исправим),
- настройками создания контрольных точек,
- характеристиками основного и исторического журнала,
- сбором статистики,
- кодировкой БД,
- автозапуском БД при старте сервера,
- значением часового пояса и др.
Мы также намереваемся в будущем управлять пространствами объектов БД разных видов на внешних носителях, но об этом напишем, когда будут новости по этой части.

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

Каким настройками вы пользовались при работе с базами данных и с какой целью? Какие проблемы решали? Поделитесь.

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

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

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

Oracle, например, предлагает контейнерное решение, в котором общие разделяемые данные и мета-данные от разных экземпляров БД могут быть выделены и переданы в родительский контейнер в единственном экземпляре.

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

Поэтому, можно наблюдать разные варианты реализации сервиса для множества баз данных:
- MS SQL Server имеет возможность выводить и вводить в эксплуатацию перемещенный экземпляр БД, каждая БД имеет свой журнал, независимое восстановление БД, горячее резервирование и копирование.
- PostgreSQL не имеет возможность выводить и вводить в эксплуатацию перемещенный экземпляр БД, все экземпляры БД имеют общий журнал, восстановление, резервирование и копирование возможно только всех экземпляров БД.
- Oracle в архитектуре "Pluggable Databases" имеет возможность выводить и вводить в эксплуатацию перемещенный экземпляр БД, все экземпляры БД имеют общий журнал, горячее копирование отдельной БД доступно с определенными ограничениями, восстановление и горячее резервирование возможно только всех экземпляров БД. Доступны родительские контейнеры, куда могут быть вынесены общие данные от разных БД.

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

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

Как вы видите оптимальную архитектуру сервиса СУБД под те или иные задачи? Поделитесь своим мнением и опытом.

Что делает СУБД быстрой или медленной, если она работает с диском? Какой ценой достигается более высокое быстродействие?

Все СУБД реализуют свой внутренний кеш для содержимого с диска. При этом они:
1. Могут использовать системный файловый кеш, положившись на организацию ввода-вывода ОС.
2. Запретить ОС кешировать ввод/вывод и реализовать собственную схему ввода-вывода.

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

Второй вариант не имеет недостатков первого, но требует более сложной реализации в СУБД (например, в СУБД Сокол), которая должна обеспечивать:

1. Эффективный ввод/вывод, выраженный в объеме записанной информации в единицу времени.
2. "Честный" ввод/вывод, равномерно обслуживающий запросы ввода/вывода и соблюдающий приоритеты.
3. Масштабируемый ввод/вывод, позволяющий утилизировать возможности современных дисковых систем.

Эффективность ввода-вывода в СУБД Сокол реализуется за счет укрупнения областей в запросах ввода/вывода.

"Честность" обеспечивается за счет постановки запросов ввода-вывода от параллельных задач в глобальную очередь внутри СУБД.
Разделение запросов по приоритету обеспечивается за счет выделения разных очередей для категорий:
- абсолютно приоритетная очередь записи журнала;
- приоритетная очередь чтения запрашиваемых данных;
- приоритетная очередь записи вытеснения;
- очередь отложенной записи данных хранилища - то, что ассоциируется с checkpointing.

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

Очереди всех категорий обрабатываются параллельно всеми ядрами ЦПУ. Это обеспечивает возможность масштабирования ввода-вывода. Глубина менее приоритетных очередей регулируется динамически и при отсутствии конкуренции они могут занять всю пропускную полосу диска.

Что известно о других системах:
- В opensource любят "срезать углы" - тут в основном используется вариант двойного кеширования.
- MS SQL и Oracle используют ввод-вывод без двойного кеширования. В документации у них нет упоминания о внутреннем планировщике ввода-вывода. Безусловно это не означает, что они не решали обозначенные задачи. Просто их терминология, постановка задачи и решение немного другие.

Что вы знаете о кешировании и вводе/выводе в известных вам системах, а также о преимуществах и недостатках в их реализации?

Из каких фаз состоит процесс трансляции SQL-запроса в Соколе? Есть ли здесь место для дополнительных оптимизаций?

В Соколе можно выделить следующие фазы трансляции SQL-запроса:
1. Поиск по тексту запроса готового кода исполнения в кеше (назовем его кеш №1) для текущей схемы.
2. Синтаксический анализ и параметризация запроса (константы тоже выносятся в параметры), на выходе - абстрактное синтаксическое дерево.
3. Компоновка, связывание символических объектных ссылок с объектами базы данных, на выходе - связанное синтаксическое дерево.
4. Поиск по сериализованной структуре связанного синтаксического дерева готового кода исполнения запроса в кеше (назовем его кеш №2).
5. Оптимизация:
- построение разных вариантов реляционных деревьев и выбор оптимального на основе связанного синтаксического дерева;
- построение вариаций физических планов и выбор оптимального на основе реляционных деревьев.
6. Кодогенерация:
- генерация виртуального IR (Internal Representation) кода;
- (опционально) генерация нативного JIT кода на основе LLVM.
7. Сохранение кода откомпилированного запроса в кешах запросов:
- по тексту запроса для текущей схемы в кеш №1;
- по сериализованной структуре связанного синтаксического дерева в кеш №2.

Тему устройства кешей рассмотрим в отдельном посте.

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

JIT трансляция активируется хинтом /*+ JIT_CODEGEN */, который нужно разместить после ключевых слов операторов SELECT/INSERT/UPDATE/DELETE. Для процедур и функций хинт должен находиться после спецификации аргументов, а для анонимных блоков после ключевого слова DECLARE.

Для генерации кода используется дата-центричный подход. Идея была озвучена в статье: http://sites.computer.org/debull/A14mar/p3.pdf

Изначальная идея исполнительной системы Сокола формировалась на основе генерации нативного кода. Тем не менее, дата-центричный подход хорошо работает и для виртуального кода. Для коротких запросов из TPC-C бечмарка разница в пиковых результатах между JIT кодом и виртуальным не превышает 10%. Для более серьезных и длительных запросов JIT показывает двукратное повышение производительности. Использование виртуального кода обусловлено высокой ценой JIT-трансляции.

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

Идею генерации кода можно развить дальше, например:
- код хранимых процедур оформить в виде динамически загружаемых библиотек. В качестве единицы трансляции (DLL-библиотека) здесь подходит пакет хранимых процедур;
- сделать трансляцию запросов в JIT быстрой (и обязательной) за счет использования собственного быстрого кодогенератора на основе подхода copy and patch - https://en.wikipedia.org/wiki/Copy-and-patch

Как оцениваете идею помещения кода хранимых процедур в DLL (не путать с DDL :) ) на фоне однородности кода хранимок и SQL-запросов, которой удалось достичь в Соколе?
С какими узкими местами в описанном процессе приходилось бороться?

Через 15 минут выступаем

Во время выступления

После выступления. Спасибо всем, кто смотрел и задавал вопросы!

Слайды презентации нашего выступления на ArchDays в Москве 5 ноября - https://archdays.ru/?speaker=2081 (скроллингуйте вниз)

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

create or replace function f_inc(a IN int) return int
as
begin
return a + 1;
end;

Синтаксис тела и описания параметров функций соответствует синтаксису хранимых процедур (примеры есть в папке examples дистрибутива).

Пока тестируем. Уже пробуете? 😉

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

Поздравляем с наступающим Новым 2025 Годом! 🎉🎊💥 Здоровья и счастья в новом году! Пусть все желания сбудутся! Сокол будет присматривать за их исполнением ✨

Доброго дня, наши подписчики!

Приветствуем вас в новом 2025 году! Надеемся, что вы успешно в него вступили и горите новыми идеями и задачами. Сил вам для всех свершений!

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

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

Отличительные черты разрабатываемого решения:

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

• отказоустойчивость основывается на переработанной идеи RAFT-протокола, RAFT-журнал является вторичным по отношению к WAL и допускает сегментацию на несколько потоков для параллельного обслуживания;

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

• сервисы горячего резервирования и архивирования создаются на основе общего протокола и механизма репликации. Ожидается, что в кластере репликации могут находиться одновременно и узлы архивирования (с поддержкой PITR) и узлы резервирования. Например, отказоустойчивая конфигурация может состоять из 3-х узлов: 2 операционных узла, любой из которых может быть лидером в определенный момент, и узел синхронного архивирования, который также участвует в консенсус алгоритмах, хотя и не может стать лидером;

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

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

• режим использования репликации в сервисах - синхронный, асинхронная репликация опциональна.

Поддерживаете такое видение или нужны корректировки "политики партии"?

Доброго дня всем! Сегодня поговорим об этом.
upd: по оси ординат число транзакций в минуту

Часто спрашивают, а есть ли в Соколе "connection pool". Ну, типа, в любой серьезной СУБД такое должно быть.

Краткий ответ "нет и вам это не нужно", обычно не воспринимается как положительный.
Давайте, разбираться.

Рассмотрим ранее приведенные измерения TPC-C бенчмарка с разным количеством складов: 10К-1К.
Только сделаем два набора измерений: с числом клиентов 160 и 1600. Почему 160 клиентов? Ну просто потому, что ранее у PG при таких условиях мы наблюдали пик производительности.

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

В Соколе же большее количество соединений дает бОльшую отдачу от системы.
Причины:
1. Большое число параллельных активных соединений способствует более эффективному GROUP COMMIT, цена синхронизации отдельной транзакции падает.
2. При большем количестве соединений поддерживается постоянная нагрузка на ЦПУ - пока одни потоки ожидают подтверждения коммита, другие работают.
3. Фрагментация памяти между конкурирующим соединениями исключается за счет предварительной оценки необходимых ресурсов для исполнения запроса и атомарного запроса их целиком у системы.
4. Ресурсные затраты для неактивного соединения минимизированы, все ресурсы освобождаются.

Что можно на основе этого сказать?
1. Использование промежуточного приложения-мультиплексора соединений (он же "connection pool") - это часто вынужденная мера для компенсации архитектурных особенностей в существующей системе.
2. Мультиплексор соединений может быть даже вреден и может препятствовать эффективной работе СУБД, которая хорошо работает с большим количество соединений.
3. Сокол использует модель "coroutine per connection" и более того, неактивное соединение переходит в бесстековое состояние. Неактивное соединение не требует каких-либо значительных ресурсов. Можно сказать, что сам Сокол является отличным мультиплексором соединений.

Уточнение:
Термин "connection pool" может быть использован в разных смыслах. Здесь мы рассматривали его именно как мультиплексор соединений к СУБД, когда количество логических подключений от пользователя больше, чем число возможных подключений, которое обеспечивает СУБД.
Другое дело когда "connection pool" создается с целью уменьшения времени установления каждого нового соединения. Такая практика имеет право на жизнь и ее не будем оспаривать.

Всем доброго дня!
В понедельник, 17 марта состоится шестой митап российского сообщества разработчиков СУБД и распределенных систем, где мы от команды СУБД Сокол выступим с докладом "Можно ли сделать репликацию параллельной и как увязать RAFT-журнал с WAL-журналом?".
Мероприятие бесплатное. Регистрация обязательна. При очном участии обязательно наличие паспорта. Участвующим онлайн будет доступна трансляция на YouTube и чат.
Присоединяйтесь - https://databaseinternals.timepad.ru/event/3263638/

Отличной всем пятницы!

💥 На конференции Saint HighLoad++ 23/24 июня 2025 в Санкт-Петербурге выступаем с докладом "Пределы и узкие места масштабирования дисковых СУБД" (https://highload.ru/spb/2025/abstracts/15004) "... Предлагаем рассмотреть СУБД Сокол в озвученных обстоятельствах в сравнении с другими системами."
Планируйте, приезжайте и приходите