title

text

Алена Рыбакина
Алена Рыбакина Postgres Professional Разработчик
А
Андрей Лепихов
: декабря
40 мин

Перепланирование безнадежных запросов в реальном времени

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

Слайды

Слайды доступны участникам мероприятия, выполнившим вход в личный кабинет.

Видео

Видео доступно участникам мероприятия, выполнившим вход в личный кабинет

Другие доклады

  • Владимир Сердюк
    Владимир Сердюк Общество с ограниченной ответственностью «Кластерные технологии Софтпоинт» Ген. директор
    40 мин

    Распределение транзакционной нагрузки в кластере серверов СУБД

    Данный доклад представляет собой описание концепции и прототипа кластера СУБД, работающего по принципу Master-Master. Проблема синхронизации данных в таких системах ни в одном тиражном решении до сих пор не решена, поэтому масштабирование для OLTP-систем, где транзакционная нагрузка сильно превалирует над аналитической, решается до сих пор только усилением аппаратной части – добавить ядер/процессоров, добавить памяти, что зачастую бывает не самым рациональным решением. Напомню, что задача распределения аналитической нагрузки решается относительно просто с помощью создания дополнительных реплик и перенаправления запросов на чтение вне транзакций на другие реплики. В случае же транзакционной нагрузки, если применять аналогичный подход, возникают коллизии, например, типа «писатель-писатель», которые, если их не учитывать, могут привести к неверным данным в транзакциях. Концепция кластера распределённых вычислений на первый взгляд звучит просто: «Все запросы на изменение данных выполняются мгновенно на всех нодах (серверах кластера), а чтение выполняется локально». Специальный прокси-агент распарсивает запросы, и выполняет запросы на чтение локально, а запросы на изменение перенаправляются параллельно и асинхронно на все остальные ноды кластера. Все изменения выполняются в системе зеркальных распределённых транзакций , которыми управляет координатор распределённых транзакций. Несмотря на простоту концепции и формулировки, возникает множество технических проблем, которые нигде ранее не были решены. В случае высокого параллелизма и конкуренции ресурсов порядок запросов на разных серверах может изменяться, что, в свою очередь, может приводить к изменению состава данных и к распределенным взаимоблокировкам. Также возникают сложности с падением линейной скорости примитивных операций. И, не решив проблемы оптимизации, данное решение сразу не подойдет для большинства систем. Одними из целевых показателей промышленного решения будет являться подключение до 20-и серверов в кластер с линейной просадкой времени операций не более чем на 10 % .

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

  • Виктор Васильев
    Виктор Васильев Postgres Professional Архитектор решений
    20 мин

    Snapshot Standby с BTRFS в работе с PostgreSQL

    В докладе будет рассмотрена функциональность файловой системы BTRFS позволяющая реализовать Snapshot Standby в работе с PostgreSQL. В первой части доклада будет поверхностно рассказано про BTRFS, а во второй части доклада будут рассмотрено несколько кейсов использования Snapshot Standby на примерах.

  • Константин Ващенков
    Константин Ващенков xsquare.ru Тех дир
    20 мин

    Миграция с Oracle APEX/Forms на Эльбрус e2k. Проблемы. Производительность

    Расскажем об опыте миграции с Oracle Forms / Apex на платформу x86 Расскажем об опыте последующий миграции решений на Эльбрус e2k Расскажем об производительности / масштабируемости (БД/количестве пользователей)

    На примере НПФ Корпорации "Ростех" / НПФ ПАО "Ростелеком"

  • Владлен Пополитов
    Владлен Пополитов Postgres Professional разработчик программного обеспечения
    40 мин

    Зачем мне векторная база данных, если уже есть PostgreSQL?

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