СУБД SoQoL

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

Все СУБД реализуют свой внутренний кеш для содержимого с диска. При этом они:
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;
- резервирование с автоматическим переключением мастера на основе протоколов консенсуса;
- мультимастер.

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

Всем привет с обучения в акселераторе "Драйвер" (Фонда развития интернет инициатив или просто ФРИИ), куда мы пришли, чтобы прокачать наш проект СУБД SoQoL и найти новых друзей, партнеров, клиентов!

Напоминаем, что уже завтра состоится митап сообщества Database Internals, на котором Андрей Коротченко расскажет об архитектуре СУБД SoQoL.

Ссылка для регистрации: https://databaseinternals.timepad.ru/event/2873648/

Участвующим онлайн будет доступна трансляция на YouTube и чат.

Привет!
По многочисленным просьбам сделали трансляцию митапа «SoQoL — СУБД для цифровой модернизации»
Начало в 16:00 по московскому времени.

Ссылка:
https://youtube.com/live/EGHenuXgAe8?feature=share

На третьем митапе сообщества Database Internals главный архитектор Андрей Коротченко расскажет об архитектуре СУБД SoQoL.

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

Мероприятие пройдет офлайн по адресу г. Москва, ул. Льва Толстого, д. 16, офис Яндекса, подъезд 3, этаж 5, конференц-зал «Синий кит». Участвующим онлайн будет доступна трансляция на YouTube и чат.

Ссылка для регистрации: https://databaseinternals.timepad.ru/event/2873648/

23 мая в офисе РЕЛЭКС проведем офлайн митап на тему «SoQoL — СУБД для цифровой модернизации».

Спикер — Михаил Бакланов, директор Центра СУБД.

Что обсудим:
— Тенденции и перспективы в сфере СУБД.
— Раскроем устройство и принципы работы СУБД SoQoL. Сделаем обзор её возможностей и характеристик.
— Поделимся информацией, какие задачи можно решить с использованием СУБД SoQoL.
— Раскроем причины, почему предприятиям необходимо ориентироваться на новую СУБД.
— Сравним нашу СУБД с известными конкурентами и расскажем о её преимуществах и особенностях.
— Поделимся реальными кейсами миграции на СУБД SoQoL и результатами.
— Старт работы с СУБД SoQoL: какие шаги предпринять.

Ждём 23 мая в 16.00
По адресу: Воронеж, ул. Бахметьева, д. 2Б, 7 этаж, оф. 711.

Регистрация по ссылке обязательна.

28 мая 2024 года пройдет саммит при поддержке Минцифры, посвященный лучшим практикам в области ИТ в России - TAdviser SummIT.
 
Это место для инноваторов и консерваторов, людей, которые участвуют в управлении крупнейшими организациями в нашей стране.
 
И SoQoL будет на TAdviser SummIT!
 
На нашем стенде будут присутствовать сотрудники компании, с которыми вы сможете в неформальной обстановке обсудить интересующие вас вопросы о SoQoL, а также возможность начала и развития сотрудничества.
 
На саммите запланирована пленарная часть и несколько специальных мероприятий. Будет много интересных спикеров.
 
Ну а мы постараемся сделать нашу с вами встречу на саммите интересной и полезной.
 
Место проведения, план размещения участников и другие подробности смотри здесь.
 
P.S. Мы будем рады вас видеть на стенде 26 :)

Первый вебинар
 
23 апреля мы провели первый вебинар, посвящённый новой СУБД – SoQoL. Больше часа рассказывали и отвечали на вопросы как устно, так и в чате. И если на заранее озвученные вопросы можно услышать ответы здесь, то вопросы из чата так там и остались.
 
Для тех, кого не было на вебинаре, мы решили часть вопросов вывести в пост. Итак, посмотрим, о чём вы спрашивали:
 
«Поддерживаете ли NUMA архитектуры? (6 и более процессорных сокетов)»
Безусловно, тестовая локальная машина 2 нума нода. Тестировали на 4х - полет нормальный, никаких аномалий в профилировке нет.
 
«Что подразумевается под горячим резервированием? Это физическая репликация, т.е. реплики, standby и т.д. или это создание резервной копии (бэкапа) в онлайн режиме?»
Логическая репликация в основе. В первую очередь это standby, дальше больше.
 
«Какие инструменты можно использовать для работы? DBeaver, например, или какие-то специальные ваши инструменты?»
Можно использовать инструменты, совместимые с JDBC-интерфейсом, в том числе и упомянутый DBeaver.
 
«Есть ли возможность работать с несколькими базами данных в пределах одной сессии (переключаясь, как, например, в MySQL)?»
В SoQoL такое невозможно, пользователи одной БД не могут подключаться к другим базам данных.
 
«Подскажите, пожалуйста, а как база восстанавливается после сбоя? К примеру, после отключения питания».
Так как и положено для подобных систем - через WAL-журнал.
 
«Насколько существенно пришлось доработать код для ЦПУ Эльбрус?»
Что мы сделали:
- оптимизировали создание и переключение контекстов (в Эльбрусе это дорого);
- создали кэш контекстов (стеков);
- реализовали возможность бесстековых задач (корутин), что минимизирует переключения контекстов.В идеале (к нему стремимся) в SoQoL вообще переключения контекста для коротких транзакций сойдёт на нет. Переключение нужно будет только в случае, когда нужно ожидать какого-либо ресурса в процесс исполнения.
 
«Еще один вопрос, поддерживается ли подключение по протоколу IPv6?»
IPv6 - да, поддерживается
 
«Есть средства для оптимизации запросов? (Например аналог/реализация EXPLAIN)»
Да, в SoQoL реализована команда EXPLAIN.
 
«С 1С в паре будет работать?»
Как внешний источник - уже да. Прочее сложнее, это к 1С. Безусловно, о нас им известно.
 
«Используется ли в Soqol файловая система для доступа к дискам?»
Да. Сейчас для каждого хранилища создается свой файл. В ближайшее время должны перейти на один файл для пространства, а там можно подумать и о сырых устройствах.
 
«Насколько большую БД пробовали практически запускать?»
Тестируем до 1Тбайт - то, что позволяет наш тестовый сервер.
 
«Какие версии Oracle и PostgreSQL использовались в тестировании? Какие были конфигурации баз данных?»
Мы пробовали разные СУБД актуальных версий.
Например, СУБД Oracle тестировалась 2-3 года назад, но постоянно не тестируется. Мы оценили её возможности несколько лет назад. PG тестируется чаще и до 15-й версии.
 
«Есть ли вероятность, что Oracle теперь работает быстрее?»
В нашей жизни возможно все. Хотя есть предположение, что Oracle довольно сложно это сделать из-за внутренней архитектуры.
 
«На каком оборудовании в какой ОС выполнялись тесты?»
Детали о тестировании можно найти в здесь и здесь.
 
«Можно ли бесплатно попробовать SOQOL в моей системе?»
Конечно. Бесплатно для личного использования можно скачать здесь или посмотреть онлайн в сравнении с другими СУБД здесь.
 
«Установлены ли цены для рынка США?»
Цены едины для всех стран с учётом текущего курса рубля. Получить информацию можно по запросу на сайте soqol.ru
 
«Спасибо большое! Очень обстоятельно. Интересно пощупать руками.» «Вы проделали очень большую и нужную работу. Удачи в дальнейшем продвижении и развитии продукта.»
 
Спасибо всем и каждому за внимание, помощь, вопросы.
Если среди материала этой публикации нет ответа на ваш вопрос, пишите в комментариях. Мы ответим :)
 
И летим дальше!

Материалы прошедшего вебинара

🔹 видео — https://vk.com/video/@soqoldb?z=video-212694425_456239019%2Fln-7QlQXF3yrRdbZk6pc6%2Fpl_-212694425_-2
🔹 презентация — https://vk.cc/cwqsFv

Через 5 минут начинаем. Если забыли зарегистрироваться, но хотите послушать — ссылка: https://relex.ktalk.ru/eq60j3o4ohlj?pinCode=8125

В одной из прошлых публикаций мы сравнивали реализацию строковых типов данных в нескольких СУБД и в SoQoL. Сегодня взглянем на числовые типы.
 
Для сравнения, как обычно, возьмём наиболее популярные СУБД (Oracle21, PostgreSQL15, MS SQL Server 2022) и SoQoL.
 
Итак, поехали. Рассмотрим самые популярные группы типов:
 
Целочисленные:
Oracle21: NUMBER. Типы SMALLINT, INTEGER, INT реализованы через NUMBER (38, 0). Для значения требуется от 1 до 22 байт.
PostgreSQL15: SMALLINT, INTEGER, BIGINT. Размер значения каждого типа соответственно 2, 4 и 8 байт.
MSSQL Server: TINYINT, SMALLINT, INT, BIGINT. Для значения каждого типа требуется соответственно 1, 2, 4, 8 байта.
 
Дробные числа с заданной точностью:
Oracle21: NUMBER(precision, scale). NUMERIC [(precision [, scale])] и DECIMAL [(precision [, scale])] реализованы как синонимы типа NUMBER [(precision [, scale])]. Для значения требуется от 1 до 22 байт.
PostgreSQL15: NUMERIC(precision, scale), DECIMAL(precision, scale). Размер значения каждого типа переменный.
MSSQL Server: DECIMAL(precision, scale) и NUMERIC(precision, scale). Для значения требуется от 5 до 17 байт, в зависимости от величины точности.
 
Вещественные:
Oracle21: FLOAT, DOUBLE PRECISION, REAL. Для значения требуется от 1 до 22 байт.
PostgreSQL15: REAL, DOUBLE PRECISION, размер значения каждого типа соответственно 4 и 8 байт.
MSSQL Server: FLOAT, DOUBLE. Для значения этих типов требуется соответственно 4 и 8 байт.

Кроме озвученных числовых типов данных в упомянутых СУБД есть дополнительные типы. Например: UINT128, INT128 в Oracle21, SMALLSERIAL, SERIAL, BIGSERIAL в PostgreSQL15, MONEY, SMALLMONEY в MSSQL Server.

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

А что в SoQoL?

Целочисленные:
SMALLINT, INTEGER, INT, BIGINT реализованы как синонимы типа NUMBER (38,0)
Дробные числа с заданной точностью:
NUMERIC [(precision [, scale])],
DECIMAL [(precision [, scale])] реализованы как синонимы типа NUMBER [(precision [, scale])]
Вещественные:
FLOAT [(p)] — числовой тип данных с плавающей запятой и двоичной точностью, которая может варьировать от 1 до 126 двоичных разрядов. По умолчанию точность составляет 126 двоичных разрядов или 38 десятичных знаков. Значение FLOAT представляется внутри в виде NUMBER [(precision [, scale])].
DOUBLE PRECISION — числовой тип данных с плавающей запятой и двоичной точностью 126 разрядов.
REAL — числовой тип данных с плавающей запятой и двоичной точностью 63 разряда или 19 десятичных знаков.
 
Для значений любого числового типа в SoQoL требуется от 1 до 22 байт.

Как видно, SoQoL использует NUMBER как универсальный числовой тип данных. Эта гибкость упрощает работу с числовыми данными и устраняет необходимость в преобразовании типов данных.

А почему ещё SoQoL выбрал поддержку расширенного типа данных NUMBER с множеством вариантов точности и масштаба (кстати, такой подход подобен Oracle)?

Мы увидели, что:
1. Возможность хранить числовые значения с произвольной точностью и масштабом обеспечивает максимальную гибкость и точность при работе с числовыми данными.
2. Поддержка экспоненциальной записи позволяет представлять очень большие или очень малые числа в компактном формате.
3. Использование различных методов сжатия и кодирования позволяют оптимизировать хранение значений NUMBER, что экономит дисковое пространство и улучшает производительность.

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

Какие из характеристик числовых типов данных были критичны в ваших задачах и какие решения в этом случае вы принимали?

Мы приглашаем всех желающих

23 апреля в 14:00 на вебинар
«ТЕХНИЧЕСКИЙ ОБЗОР СУБД SoQoL»

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

Вебинар проведёт Михаил Бакланов – руководитель департамента СУБД компании РЕЛЭКС.

Здесь нужно зарегистрироваться, после чего мы пришлём ссылку на вебинар.

Регистрируйтесь, пишите свои вопросы и приходите!