title

text

Alicja Kucharczyk
Alicja Kucharczyk Microsoft EMEA Global Blackbelt OSS Data Tech Specialist
Sushant Pandey
Sushant Pandey Microsoft 500032
13:00 03 марта
22 мин

История одной миграции

В данном рассказе мы хотим рассказать о том, как команда Microsoft, созданная из двух различных команд, работала над проектом, решала проблемы миграции, используя ora2pg, и смогла доказать, что Postgres Single Server может демонстрировать хорошую производительность наравне с Oracle Exadata. Мы расскажем о наших методах работы, а также о ряде основных проблем технического характера, с которыми мы столкнулись, включая миграцию выражений BULK COLLECT, иерархических запросов, курсорных выражений REF CURSOR и других, более сложных конструкций Oracle.

Наша история о практическом подтверждении гипотезы, которое доказало, что Postgres может демонстрировать такую же производительность, как Oracle Exadata. Схема мигрируемой БД была не самой простой. Скорее, наоборот. Код был нагружен динамическими запросами, выражениями BULK COLLECT, вложенными циклами, операторами CONNECT BY, глобальными переменными и множеством зависимостей. Инструмент Ora2pg очень помог нам с преобразованием схемы БД, но всё равно осталось много работы, которую можно было сделать только вручную. Оценки, которые мы получили благодаря инструменту, также оказались очень далеки от истины, поскольку требовалась не просто миграция кода, а изменение его архитектуры. В рамках нашего доклада мы рассмотрим следующие подтемы:

  • Как (не) работают оценки
  • Как мы справились с миграцией выражений BULK COLLECT
  • Почему мы избавились от выражений REF CURSOR
  • Как мы застряли на фазе тестирования одного из пакетов и как помощь друга помогла нам в решении этой проблемы.
  • Как мы справились с иерархическими запросами и детализацией иерархии

Видео

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

  • Yugo Nagata
    Yugo Nagata SRA OSS, Inc. Japan Chief Scientist
    45 мин

    Автоматическое инкрементальное обновление материализованных представлений

    Материализованное представление служит для хранения результатов запросов определения представления в БД, чтобы добиться более быстрого ответа на запрос. Однако данные в представлении устаревают после изменения базовых таблиц. Следовательно, для поддержания актуальности содержимого необходимо обновлять представление. В PostgreSQL есть команда REFRESH MATERIALIZED VIEW для обновления материализованного представления, но эта команда вычисляет его содержимое с нуля, что неэффективно в случаях, когда изменяется только небольшая часть базовой таблицы.

    Инкрементальное обновление представлений (IVM) - это метод эффективного обновления материализованных представлений, который вычисляет и применяет к материализованным представлениям только инкрементальные изменения вместо повторного вычисления. Эта функциональность требуется для быстрого обновления материализованных представлений, но еще не реализована в PostgreSQL.

    Поэтому мы разработали IVM для PostgreSQL и предлагаем реализовать его в качестве основной функции. Патч сейчас обсуждается в списке рассылки hackers. Наша реализация делает возможным автоматическое инкрементальное обновление материализованных представлений при изменении базовой таблицы. Вам не нужно писать собственную триггерную процедуру для обновления представлений. После продолжительной работы нашей команды текущая реализация IVM поддерживает некоторые возможности аггрегации, подзапросы, соединение одной таблицы (self-join), внешние соединения (outer join) и CTE (предложения WITH) в запросе определения представления. Результат оценки производительности с использованием запросов TPC-H показывает, что наша реализация IVM может обновлять материализованное представление в 200+ раз быстрее, чем повторное вычисление с помощью команды REFRESH.

    В данном докладе мы опишем нашу реализацию IVM и ее возможности.

  • Федор Сигаев
    Федор Сигаев Postgres Professional технический директор
    Антон Дорошкевич
    Антон Дорошкевич ИнфоСофт Руководитель Отдела-ИТ
    45 мин

    1С:Предприятие + Постгрес = ...

    В диалоге технического директора Postgres Professional, ведущего разработчика PostgreSQL Федор Сигаев и известного 1С-эксперта Антон Дорошкевич обсудят имеющиеся проблемы эксплуатации 1С на Постгресе и их возможные решения.

  • Álvaro Hernández
    Álvaro Hernández OnGres Founder
    180 мин

    Как преобразовать Postgres в облачную платформу

    Сводится ли развёртывание Postgres на Kubernetes к простой перераспаковке в контейнере? Или Postgres может использовать другой cloud-native софт для более качественной интеграции с K8s? Мы поговорим об этом на данном мастер-классе и продемонстрируем несколько примеров на StackGres:

    • Как преобразовать Postgres в контейнер без инициализации с несколькими контейнерами-"прицепами" для создания пула соединений, резервного копирования, агентов и т.п.
    • Определение высокоуровневых CRD в качестве единого API для взаимодействия с Postgres оператором.
    • Использование авторизации на основе K8s RBAC для аутентификации пользователя веб-интерфейса управления.
    • Использование Prometheus для мониторинга; сборка узла, использование экспортёров и Postgres, и PgBouncer.
    • Проксирование трафика Postgres traffic через Envoy. Завершение работы Postgres SSL с помощью плагина Envoy, который также экспортирует метрики "проводного" протокола в Prometheus.
    • Использование Fluentbit для сбора логов Postgres и их пересылки в Fluentd, который хранит их в централизованной постгрессовой базе данных.

    Во время мастер-класса вы сможете повторить все действия на собственном Kubernetes-кластере и с лёгкостью пройти путь от новичка до профи в Postgres на Kubernetes! Вы сможете создавать собственный Postgres-as-a-Service на Kubernetes всего за несколько минут!

  • Андрей Фефелов
    Андрей Фефелов Mastery.pro Технический директор
    22 мин

    Как обфусцировать базу в Postgres для задач нагрузочного тестирования веб-приложений

    Postgres - отличная база данных для высоконагруженных веб-приложений. В свою очередь для таких веб-приложений периодически встает задача нагрузочного/стресс тестирования. Кроме очевидных сложностей: эмуляции рабочего окружения близкого к продуктовому и генерации трафика есть задача подготовки базы данных для тестового окружения. В эпоху борьбы за приватность персональных данных (152-ФЗ, GDPR, HIPAA) использование базы с прода выглядит плохой идеей. Выход один - обфусцировать данные.

    Существуют различные инструменты для обфускации данных в Postgres. В докладе я расскажу, какие из них мы выбрали и почему, с какими трудностями столкнулись во время использования, насколько удачно решили задачу.

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