Database Internals Meetup №5
Meetup №5: доклады + панельная дискуссия на секции СУБД конференции ISPRAS Open
Пятый митап российского сообщества разработчиков СУБД и распределенных систем. Доклады от основателей и ведущих разработчиков YDB, Picodata, Tarantool, openGauss и 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 решений. Особое внимание уделим проблеме деградации производительности в существующих решениях и представим новый оптимизатор, разработанный для её решения. В заключении путем сравнительного анализа ответим на вопрос: «От чего пришлось отказаться в нашем оптимизаторе для повышения надежности?».
Перспективы создания модульного оптимизатора запросов
Павел Велихов (YDB), Тимур Сафин (Huawei GaussDB), Владимир Озеров (CedrusData), Максим Смяткин (Яндекс), Денис Пономарев (openGauss)
Переписывание запросов на основе материализованных представлений в аналитической системе CedrusData.
Владимир Озеров, Александр Блажков, генеральный директор и разработчик CedrusData
Пользовательские запросы в аналитических системах часто содержат повторяющиеся вычисления над медленно изменяющимися данными. Материализованные представления позволяют уменьшить TCO аналитической системы за счет переиспользования результатов повторяющихся подзапросов. Несмотря на то, что алгоритмы выбора материализованных представлений для запросов описаны достаточно давно, данный функционал до сих пор отсутствует во многих аналитических системах.
В докладе мы рассмотрим практические аспекты реализации переписывания запросов на основе материализованных представлений в CedrusData — аналитическом движке для обработки больших данных на основе open-source проекта Trino. Наше ключевое наблюдение заключается в том, что высокая сложность реализации во многом обусловлена (1) желанием решить проблему в общем виде и (2) недостаточной готовностью отдельных компонентов продукта (например, внутреннее представление планов, подсистема управления метаданными). Правильная приоритизация продуктовых потребностей и активное исправление недостатков ядра продукта позволили нам реализовать функционал переписывания запросов в объеме, достаточном для покрытия ключевых потребностей наших заказчиков.
Мы расскажем, какие продуктовые соображения позволили нам корректно расставить приоритеты и сократить объем разработки. Далее мы рассмотрим, как пошагово добавляли в продукт переписывание простых SELECT-PROJECT-FILTER запросов, затем агрегатов и кубов и, наконец, JOIN. Мы также обсудим, как исправляли неожиданные проблемы legacy кода Trino, и как искали практические решения сложных комбинаторных проблем, таких как быстрый выбор кандидатов для переписывания запроса.