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

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

Из каких фаз состоит процесс трансляции 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-запросов, которой удалось достичь в Соколе?
С какими узкими местами в описанном процессе приходилось бороться?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня мы поговорим о команде 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. При работе с базами данных важно учитывать специфику каждой СУБД и использовать соответствующие инструменты для эффективного управления базами данных.

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

Всем привет!

В этом посте хотим поговорить с вами о возможных вариантах использования SoQoL.

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

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

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

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

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

Обсуждение предыдущего поста показало, что отказоустойчивое решение на основе репликации и консенсуса — это то, что хотят от SoQoL в ближайшем будущем. И мы услышали «громкое требование» о необходимости восстановления до определенной точки в прошлом (PITR). Наша команда видит явное подтверждение в правильности выбранного приоритета в разработке и это радует.

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

Вопросы:
1. Где-то в известных вам случаях в продакшене используются такие возможности логической репликации, организуют репликацию определенного набора объектов или отдельных схем?
2. Расскажите о случаях, когда возникала потребность реплицировать вновь созданные объекты и субъекты? Сталкивались ли при этом с проблемами? Как решали?
3. Почему, на ваш взгляд, современные тенденции в разработке тяготеют к логической репликации или даже репликации операторов, а не данных?

И снова здравствуйте! Поздравляем отдохнувших и всё ещё отдыхающих!

Как некоторые из вас знают, сейчас одной из наших важнейших задач является создание отказоустойчивого решения с резервными узлами. Исторически каждая из СУБД накапливала различные варианты решения данной задачи и предложила удобные (или не очень) средства для её решения. Мы изучали многие из них, что-то прототипировали в собственной системе. Для полноты картины хотим с вами обсудить эту тему.

Каждый из вас имеет собственный опыт использования отказоустойчивых решений. Поэтому хотим спросить, с какими сложностями вы сталкивались при использовании различных решений или что было удобно и понравилось? Может у вас сформировалось видение "наилучшего решения" или интересных деталей, дающих определенному механизму интересные преимущества. Поделитесь — обсудим, рассмотрим плюсы и минусы. Так, для затравки, некоторые механизмы репликации:
- физическая репликация RAC от Оракла;
- физическая репликация от PostgreSQL;
- логическая репликация от PostgreSQL;
- сторонние логические репликации PostgreSQL BDR, MySQL Tungsten Replicator, Oracle GoldenGate;
- резервирование с автоматическим переключением мастера на основе протоколов консенсуса;
- мультимастер.

Да, и на всякий случай уточним, что сейчас разговор не про масштабирование (или шардирование). Это будет отдельная тема.