title

text

Á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 всего за несколько минут!

Видео

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

  • 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 и ее возможности.

  • Александр Никитин
    Александр Никитин ЗАО ЦФТ Администратор баз данных
    22 мин

    Неочевидные моменты процесса копирования и переноса баз данных и кластеров PostgreSQL

    Копирование и перенос баз данных и кластеров PostgreSQL, казалось бы, что может быть проще?

    Однако, практика показывает, что даже в таких простых действиях можно запутаться. Во время доклада я покажу какие подводные камни могут подстерегать вас в процессе копирования/переноса баз данных и кластеров PostgreSQL. Попробуем ускорить эти операции, посмотрим, с какими неожиданными проблемами вы можете столкнуться при выполнении этих, казалось бы, простых действий.

  • Арсений Шер
    Арсений Шер Postgres Professional Разработчик
    45 мин

    Консенсус, Postgres, Мультимастер

    Postgres Pro Multimaster - это расширение Postgres (и набор патчей для ядра), обеспечивающее высокую доступность (HA) со строгой согласованностью и масштабируемостью чтения. Он образует симметричный кластер без общего доступа, синхронно реплицирующий данные и автоматически выполняющий аварийное восстановление. В течение последнего года мы приложили значительные усилия, чтобы убедиться и доказать, что согласованность сохраняется во всех сценариях. Новая версия, которая будет выпущена как часть Postgres Pro Enterprise 13, использует алгоритм Paxos для определения результата транзакции и оригинальный протокол, управляющий процессом восстановления; мы использовали TLA+ и TLC model checker для проверки его правильности. Я расскажу, как все это работает и почему в некоторых случаях multimaster может быть привлекательной альтернативой традиционным HA решениям на основе потоковой репликации.

    Multimaster теперь имеет открытый исходный код и доступен по адресу: https://github.com/postgrespro/mmts

    Чтобы сделать доклад менее узкоспециализированным и более привлекательным для широкой аудитории, в первой части я расскажу о том, как в целом современные СУБД (в основном так называемые NewSQL СУБД) обеспечивают отказоустойчивость. В частности, я остановлюсь на следующих моментах:

    что такое строго согласованная СУБД и какие накладные расходы с этим связаны; что такое распределённый консенсус, Paxos, Raft; как они здесь помогают?

    Я не буду пытаться объяснять какие-либо алгоритмы построчно; это едва ли осмысленно с учетом ограничений по времени, и на эту тему есть много полезной литературы. Цель здесь скорее в том чтобы познакомить с областью и задать в ней ориентиры.

  • Алексей Фадеев
    Алексей Фадеев Sibedge Старший разработчик .NET, евангелист Postgres.
    22 мин

    Multicorn Foreign Data Wrapper против plpython

    Технология Multicorn позволяет разрабатывать FDW на языке Python, что гораздо проще и быстрее создания FDW на языке C. Однако есть и обратная сторона, Multicorn FDW хорошо работают с примитивными условиями WHERE, но на чуть более сложных случаях возникают трудности, про которые я расскажу. Случаи будут рассмотрены на примере моего Multicorn FDW для получения данных OpenStreetMap. Так же я покажу примеры использования одного и того же кода в Multicorn FDW и функции на plpython, в том числе сравнение производительности. В заключение поделюсь своими выводами, когда лучше использовать plpython, а когда Multicorn FDW.