title

text

PGConf.Russia 2018

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

Темы встречи

  • PostgreSQL на переднем крае: большие данные, интернет вещей, блокчейн
  • новое в PostgreSQL и вокруг: развитие PostgreSQL и его экосистемы
  • PostgreSQL в реальных системах: архитектура, миграция, эксплуатация
  • Использование PostgreSQL в платформе 1С
  • PostgreSQL в геоинформационных системах (GIS)
  • более
    0 участников
  • 0 докладчиков
  • 0
    минут общения
  • 54 доклада
  • оффлайн
    формат

Доклады

Архив докладов

PGConf.Russia 2018
  • Дмитрий Сарафанников
    Дмитрий Сарафанников Яндекс Разработчик

    Ни для кого не секрет, что статистика не переносится при мажорном обновлении. Для небольших и не сильно нагруженных баз это не проблема, можно быстро собрать новую статистику. Но у нас есть базы объемом порядка 5ТБ и нагрузкой порядка 100k rps, для которых это стало большой проблемой: взлетая без статистики, реплики даже не могли накатывать WAL. В своем докладе расскажу, на какие хитрости мы пошли, чтобы произвести обновление этих баз в условиях требований 100% доступности read only, о том, какие ошибки допустили, и о том как эти ошибки мучительно исправляли. Результатом этих ошибок стало расширение pg_dirty_hands, в котором мы будем собирать различные хаки, которые можно назвать «фол последней надежды».

  • Константин Книжник
    Константин Книжник Postgres Professional Ведущий разработчик

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

    • Большие накладные расходы на распаковку записей.
    • Затраты на интерпретацию запроса (Постгрес интерпретирует план выполнения запроса)
    • Поддержка работы с абстрактными типами
    • Недостатки PULL модели выполнения запроса
    • Издержки MVCC

    Все эти проблемы могут быть в большой степени решены за счёт использования векторного исполнителя запросов, который за одну операцию в состоянии обработать целый блок (вектор) значений. В этом докладе описывается способ добавления векторных операций в Посгрес, с помощью стандартного механизма расширения Посгреса, без внесения изменений в ядро. Такие механизмы Посгреса как UDT (определяемые пользователем типы), FDW (абстракция внешнего поставщика данных), расширения исполнителя запросов позволяют реализовать в Постгресе вертикальный таблицы, с которыми можно работать как с обычными таблицами. Но на порядки быстрее благодаря использованию векторных операций.

  • Eren Basak
    Eren Basak Citus Data Software Development Engineer

    В Postgres есть возможность восстановления данных на момент времени (PITR), которая позволяет нам "отправляться" в прошлое. В этом докладе мы обсудим, какие существуют основные сценарии использования этой функциональности, как подготовить базу данных к восстановлению на момент времени, настроив хорошую систему бэкапов и транcляции WAL-файлов, а также рассмотрим конкретные примеры. Мы подробнее остановимся на том, как применять PITR на распределенных системах и кластерах с шардингом, затронув типичные проблемы подобных конфигураций, такие как разница во времени, и предложим возможные способы их решения - например, двухфазный коммит и pg_create_restore_point.

  • Wiktor Brodło
    Wiktor Brodło Adjust GmbH Системный администратор

    В своем выступлении я расскажу о том, как группа сисадминов набила шишки, пытаясь реанимировать петабайтный кластер баз данных Elasticsearch, и в конце концов решила заменить его проверенными технологиями: PostgreSQL, Kafka, немного Redis, много клея, и типичное сисадминское упрямство. Результатом стал Bagger - ответ сисадмина на вызов больших данных. Быстрое, надежное, устойчивое к отказам хранилище, используемое в основном для логирования временных событий. Bagger получил свое имя по названию серии ковшовых экскаваторов, одних из крупнейших наземных транспортных средств, когда-либо производимых человеком. Как эти экскаваторы прокапывают тонны материала, так и наш Bagger способен прокопаться через тонны данных.

Все доклады

Партнёры

PGConf.Russia 2018

Серебряный партнёр

Организационный партнёр

Информационные партнёры

Партнёр