Приглашаем вас на пятый митап сообщества Database Internals. В программе пять докладов от основателей и разработчиков  YDB, Picodata, Tarantool, openGauss и CedrusData.

Мероприятие пройдет офлайн на секции конференции ISPRAS Open по адресу Москва, Раменский бульвар, д. 1. Кластер «Ломоносов». При очном участии обязательно наличие паспорта.

ВАЖНО! Для участия в мероприятии пройдите регистрацию на сайте конференции ISPRAS Open

Программа

13:00 — 14:00 Эволюция архитектуры СУБД на примере YDB,  Андрей Фомичев, Яндекс, основатель и руководитель YDB

14:00 — 15:00 Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata, Константин Осипов, Picodata, основатель Picodata

15:00 — 16:00 Оптимизация подсказками: ускоряем запросы, не изменяя планировщик. Сергей Зинченко, OpenGauss, Инженер

16:00 — 16:30 Кофе брейк

16:30 — 17:30 Панельная дискуссия: Перспективы создания модульного оптимизатора запросов. Павел Велихов, Владимир Озеров, Денис Пономарёв, Тимур Сафин, Максим Смяткин

17:30 — 18:30 Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData

Доклады

Эволюция архитектуры СУБД на примере YDB

Андрей Фомичев, Яндекс, основатель и руководитель YDB

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

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

У автора богатый опыт непосредственной разработки и руководства таких разных систем, как XML база данных, KV хранилище, Map-Reduce система и Distributed SQL Database. 

Blue/green deploy для хранимых процедур в кластерной СУБД на примере Picodata

Константин Осипов, Picodata, основатель Picodata

Баталии вокруг использования хранимых процедур в СУБД кажется поутихли, и корпоративные архитекторы пришли к консенсусу: хранимые процедуры вредны. Сложности внедрения, обновления, отладки, и сильная зависимость от вендора СУБД и синтаксического сахара перевесили преимущества в производительности и масштабируемости. Немногочисленные сторонники хранимых процедур перешли в мире смарт-контрактов и резидентных СУБД. Одной из таких СУБД является СУБД Picodata — распределённая, гиперконвергентная СУБД совместимая с PostgreSQL по синтаксису и клиент-серверному протоколу. Нам в Picodata пришлось переизобрести хранимые процедуры для кластерного развёртывания. Как обеспечить консистентное обновление кода хранимой процедуры без простоя во всём кластере? Как провести миграцию данных при развёртывании новой версии модуля? Какими должны быть лучшие практики использования хранимых процедур в мире agile и continuous delivery? О наших ответах на эти вопросы я расскажу в своём докладе.

Оптимизация подсказками: ускоряем запросы, не изменяя планировщик.

Сергей Зинченко, OpenGauss, Инженер

Рассмотрим возможности и основные сложности метода оптимизации запросов с использованием подсказок. Затем проследим путь от постановки задачи до архитектур современных ML-based решений. Особое внимание уделим проблеме деградации производительности в существующих решениях и представим новый оптимизатор, разработанный для её решения. В заключении путем сравнительного анализа ответим на вопрос: «От чего пришлось отказаться в нашем оптимизаторе для повышения надежности?».

Columnar In-Memory в Tarantool: зачем нужно строить еще одну колоночную СУБД, да еще и в памяти?

Николай Карлов, VK, Head of Innovations, tarantool.io

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

А что если нам нужно выполнять аналитические запросы, но с очень высокой интенсивностью с миллисекундными задержками? 

В этом докладе затронуты вопросы: где возникают такие задачи, как они привели к идее разработки HTAP-СУБД c колоночной обработкой данных в оперативной памяти, причем здесь OLAP-кубы, антифрод, скоринг и AI&ML

Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData. 

Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData

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

В докладе мы рассмотрим практические аспекты реализации переписывания запросов на основе материализованных представлений в CedrusData — аналитическом движке для обработки больших данных на основе open-source проекта Trino. Наше ключевое наблюдение заключается в том, что высокая сложность реализации во многом обусловлена (1) желанием решить проблему в общем виде и (2) недостаточной готовностью отдельных компонентов продукта (например, внутреннее представление планов, подсистема управления метаданными). Правильная приоритизация продуктовых потребностей и активное исправление недостатков ядра продукта позволили нам реализовать функционал переписывания запросов в объеме, достаточном для покрытия ключевых потребностей наших заказчиков.

Мы расскажем, какие продуктовые соображения позволили нам корректно расставить приоритеты и сократить объем разработки. Далее мы рассмотрим, как пошагово добавляли в продукт переписывание простых SELECT-PROJECT-FILTER запросов, затем агрегатов и кубов и, наконец, JOIN. Мы также обсудим, как исправляли неожиданные проблемы legacy кода Trino, и как искали практические решения сложных комбинаторных проблем, таких как быстрый выбор кандидатов для переписывания запроса.

Полезные ссылки

• Telegram-чат сообщества: https://t.me/databaseinternalschat
• Анонсы предстоящий событий: https://databaseinternals.timepad.r...

ВАЖНО! Для участия в мероприятии пройдите регистрацию на сайте конференции ISPRAS Open