Как я перестал беспокоиться и перенес 60K строк из 150 процедур PL/SQL в Postgres.

В докладе рассказывается об опыте переноса серверного приложения, работающего на полигоне железных дорог от Калининграда до Хабаровска, с Oracle 11g Standard Edition на ванильный PostgreSQL 11.5.
На момент начала миграции база данных насчитывала порядка 200 хранимых процедур на языке Oracle PL/SQL общим объемом порядка 60000 строк (которые создавались с 2006 года, т.е. уже более 12 лет), около 250 таблиц и 50 Гбайт данных.
Доклад содержит описание сопровождавших этот процесс приключений, приятных и неприятных открытий, а также пролог, эпилог и хэппи-энд.

Повествование ведется от лица пользователя Oracle, открывающего для себя Postgres.

Новые разработки для PostgreSQL: аппаратные технологии энергонезависимой памяти и SQL-акселераторы на ПЛИС в 2020

Серверные технологии не стоят на месте и иерархия хранения и обработки данных стремительно меняется. В приходом в 2019 году принципиально новой памяти Intel® OptaneTM DC persistent memory типовой сервер получил возможность конфигурироваться с терабайтами прямо адресуемой памяти или использовать эти модули как сверхбыстрый энергонезависимый кэш. Параллельно, активно ведется работа по переносу части операций СУБД c ядер ЦПУ на акселераторы на базе ПЛИС.

Odyssey: архитектура, настройка, мониторинг

Совсем недавно мы выпустили версию 1.0 нашего пулера соединений Odyssey. Он призван решить проблемы управления соединениям высоконагруженных инсталляций PostgreSQL. В этом докладе я хотел бы рассказать об архитектуре и эксплуатации Одиссея. Также будут затронуты проблемы, которые были решены в достаточно длинном переходе между 1.0rc и 1.0.

Make Your PostgreSQL 10x Faster on Cloud in Minutes

Cloud storage has some unique characteristics compared to traditional storage mainly because it is virtualized and controlled by software. One example is that AWS EBS shows higher throughput with larger I/O size up to 256 KiB without hurting latency. Hence, a user can get only about 4 MiB/sec with 1,000 IOPS EBS volume if the I/O request size is 4 KiB, whereas a user can get about 250 MiB/sec if the I/O request size is 256 KiB. This is because EBS consumes one I/O in a given IOPS budget for every I/O request regardless of the I/O size (up to 256 KiB). Unfortunately, PostgreSQL cannot exploit the full potential of cloud storage because PostgreSQL has designed without considering the unique characteristics of cloud storage.

In this talk, I will introduce the AppOS extension that improves the throughput of a write-intensive workload by 10x by transparently making PostgreSQL cloud storage-native. AppOS works like a storage driver that efficiently exploits the characteristics of cloud storage, such as I/O size dependency to storage throughput and latency, atomic write support in cloud block storage, and fast, but non-durable local SSDs. To do this, AppOS comprises a Linux-compatible file I/O stack including virtual file system, page cache, block I/O layer, cloud storage driver. On top of the file I/O stack, syscall module supports registering pre- and post-handler for file I/O-related system calls in order to transparently work without modifying PostgreSQL codes.

I will focus on presenting key use cases and performance results of the AppOS extension after explaining the internals. Specifically, I will show the performance results of OLTP and some batch workloads using standard benchmarking tools like pgbench and sysbench. I will also present performance results and implications on multiple clouds including AWS, GCP, and Azure.