PGConf.Russia 2018

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

Во что может вылиться желание не платить за винду 1С-нику? Есть ли жизнь без COM-а (консоли сервера 1С нет, но есть RAS; ODBC из 1С как вызывать)? Гарем постгресов, адресация и нюансы. i9-7900x и Linux, жизнь без turboboost 3. Планирование дисковых ресурсов. Как побороли падения OC CentOS.

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

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

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

Как бэкапировать PostgreSQL? Как хранить сделанные бэкапы? Как валидировать бэкап? Как валидировать PostgreSQL и можно ли ему вообще доверять? Можно ли доверять твоему инструменту? Как сделать всю эту паранойю удобной и производительной, если СУБД не помогает в этом деле? На какие компромиссы можно идти и на какие ни в коем случае нельзя? Создавая свой инструмент бэкапирования, мы были вынуждены искать ответы на эти и многие другие вопросы, о чем и хотелось бы рассказать.