Продолжаем экспериментировать с форматом: в этом выпуске нет раздела Релизы, но несколько релизов разбросаны по соответствующему контексту.

Люди

Список коммитеров прирос Даниэлем Густафссоном (Daniel Gustafsson, Greenplum, из Стокгольма) и Джоном Найлором (John Naylor, 2ndQuadrant=EDB)

Даниэль: я использую, разрабатываю и продвигаю open source последние 15 лет, фокусируясь в основном на PostgreSQL и curl. Сейчас я работаю в Greenplum. Я контрибьютор PostgreSQL и работаю над кодом ядра PostgreSQL. А ещё над веб-сайтом, там я коммитер. Кроме программистских дел, я ещё и организую международные конференции: Nordic PGDay, FOSDEM, PGDay и PostgreSQL Conference Europe.

Джон не любит, видимо, говорить о себе. В корпоративном блоге есть парочка его статей.

Интервью: Брин Льюэллин

Брин (Bryn Llewellyn) в своё время ушёл из Oracle в YugaByte, и об этом его с пристрастием расспрашивают. Брин занимается в компании документацией, которая, по его словам, более развитая, с бОльшим количеством примеров, которые придумывает Брин (мне она, честно говоря, не показалась удобной). И это занятие его более чем устраивает: объясняя, понимаешь глубже. К тому же, всегда можно порезвиться, придумывая интересные примеры.

Самое актуальное для сообщества — горизонтальная масштабируемость Postgres. В YugaByte решают (или уместней сказать «обходят»?) эту проблему «единственным разумным путём: код PostgreSQL используется как „верхняя половина“, C-слой для операций с SQL. А „нижняя половина“ заменена полностью — это югабайтовский код, обеспечивающий внутреннюю масштабируемость с распределённостью на глобальном уровне и с внутренней отказоустойчивостью. Там схема распределённых транзакций реплицирует все сохраняемые данные, используя произвольно высокий фактор репликации (то есть настолько большой, насколько нужно). Описание этой двухэтажной архитектурной схемы лучше начать со статьи в югабатовском блоге: Distributed PostgreSQL on a Google Spanner Architecture — Storage Layer. А потом уже смотреть постгресовый слой.» YugaByte доступен в открытых кодах на гитхабе.

Что раздражает Брина в Postgres? Прежде всего то, что PL/pgSQL не поддерживает вложенные подпрограммы и пакеты — в отличие от Oracle. Из-за этого почти невозможно создавать модульный софт, с повторным использованием компонент, а куда без этого в больших проектах.

Статьи

Почему мы перешли с Oracle на PostgreSQL, и как это сделать

Опыт перехода с Oracle 12 на Postgres Pro Standard 13. Волнующая тема, соответственно более полусотни комментариев. В том числе от Сбера: «В Сбере тоже есть адекватные менеджеры и миграция с Oracle на PG идет полным ходом, в ближайшем времени постараемся опубликовать статью с нашим опытом.»

Статья богата на ссылки. Автор, plotn1 (Плотников?) предлагает перед чтением его статьи глянуть, чего энтерпрайзу в PostgreSQL не хватает. Кстати, если лень или некогда, можно глянуть нашу сводку «нехваток» в Postgresso 31.

Автор также ссылается на доклады и мастер-классы PGConf.Russia, советует начать вот с этого доклада о миграции с Oracle: Как я перестал беспокоиться и перенес 60K строк из 150 процедур PL/SQL в Postgres Анатолия Анфиногенова из АО “ВНИИЖТ”. А по ходу дела сверяться с Сопоставление типов данных Oracle с PostgreSQL Дэвида Рейдера (David Rader).

С чего надо было мигрировать:

Данные в Oracle 12. «Стек приложения — java/kotlin вперемежку, spring, разумеется hibernate. Часть приложений подняты на glassfish, часть автономны на spring boot. Такое вот наследие.»

Мигрировали на Postgres Pro Standard 13 на RedOS 7.2 «Муром». Инструмент — ora2pg, он выдал рабочий скрипт создания таблиц. Но все первичные ключи получились numeric(22), пришлось переделывать на int8. Несоответствию типов в Oracle и Postgres в статье посвящено немало места — опыт, полезный для многих.

Перегоняли данные через расширение oracle_fdw, но оно с полпинка не установилось. Автор рассказывает интересный эпизод: он создал тикет в гитхабе автору расширения. Разработчик, вопреки ожиданиям, за день выпустил новую версию, которая устанавливалась без проблем.

Поскольку в Postgres Pro Standard не входит pgpro_scheduler (он входит в Enterprise), то использовали для запуска репликации pg_cron.

Для переписывания сложных функций использовали расширение orafce (Oracle’s Compatibility Functions and Packages). Вместо оракловых древовидных запросов использовали CTE. Настраивали производительность при помощи PGTune.

К слову, вот новый релиз ora2pg на гитхабе неутомимого Жиля Дароля (Gilles Darold):

Ora2Pg 22.1

Database Lab 2.4

Мы не раз рассказывали о Database Lab Engine в Postgresso, в том числе в Postgresso 26, где говорили о DLE 2.0, давали ссылку на полуторачасовой Вторник, на котором Николай Самохвалов и Артём Картасов обсуждали DLE. Вот ещё повод: релиз 2.4.

Database Lab это инструмент для клонирования больших баз, чтобы тестировать или отлаживать запросы или совершенствовать приложения — в не критичном окружении. Но это «тонкие» клоны, поэтому они создаются быстро, и работать с ними удобно.

В 2.4 появились два важных инструмента:

• DB Migration Checker. Он автоматизирует тестирование миграционных проектов в стиле CI/CD (то есть непрерывной интеграции / непрерывного развертывания);
• модуль Terraform для разворачивания DLE в AWS в «логическом» режиме развёртывания. При этом исходная база PostgreSQL может быть физически расположена где угодно.

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

pg_validate_extugprade 1.0.0beta

Плодовитый Жульен Руо (Julien Rouhaud) придумал инструмент-расширение для тестирования расширений после их обновления соответствующими скриптами. Нишевый продукт, как он сам говорит, для тех, кто разрабатывает и поставляет расширения. pg_validate_extugprade проверяет, создадут ли ваши скрипты, если вы установите расширение версии X, и затем обновите до Y, точно те же объекты, что появятся при установке сразу версии Y. И выдаст список отличий, если они есть. Код открытый, написано на RUST, совместимо с PostgreSQL 9.2 — 14.

Empire ERP. Занимательная бухгалтерия: PostgreSQL

Владимир Номхоев aka nomhoi предлагает развлечься бухгалтерией. У статьи предыстория. Начиналось всё, как ни странно, с AI Cup — с конкурса программистов, пишущих игры-стратеги с использованием искусственного интеллекта. Но оттуда взят, видимо, только программный фреймворк — в том числе с Python, конечно, и дополненный C++. До этого в статье Empire ERP. Занимательная бухгалтерия: главная книга, счета, баланс набросали прототип ERP, там же прописаны требования, а в этой статье базу уже берут готовой с гитхаба. Всё собирается в докере.

В конце статьи Владимир утверждает, что вот, мол, всю логику модуля «Бухгалтерия» можно создать на стороне сервера базы данных и создать SQL API. Насчёт «всей» не берусь судить. А в самом-самом конце неожиданное возвращение к ИИ: оказывается, большие учёные планируют планирование ERP-задач поручить тоже ИИ (глава Automated Planning).

Потоковый захват изменений из PostgreSQL/MySQL с помощью Apache Flink

Александр Сергеенко из компании «Неофлекс», демонстрирует реализацию паттерна Change Data Capture (CDC) средствами Apache Flink.

Тема, как мне кажется, не очень многим постгресистам знакомая. Больше, наверное, кафкианцам. В статье есть вполне информативная теоретическая часть. «CDC можно представить в виде ETL-процесса, где „E“ отвечает за анализ лога базы данных, „T“ – по обыкновению занимается преобразованиями и агрегациями событий, а „L“ – транслирует полученные агрегаты или сырые события потребителю.» Логи в контексте ETL возникают немного неожиданно, и действительно WAL используется. В статье много незнакомых мне терминов вроде event-carried state transfer или event sourcing.

Дальше уже строятся схемы работы CDC с участием Postgres.

В результате упрощений схемы взаимодействия c Postgres остаётся Flink CDC Connectors — набор коннекторов для MySQL и PostgreSQL, разработанный Alibaba и Ververica, который позволяет подключаться к логам БД прямо из Flink-джоба (задания).

Собирается демонстрационный проект — сценарий захвата изменений из WAL PostgreSQL — как docker compose, в котором:

• PostgreSQL – собственно, мастер-источник изменений;
• Elasticsearch – для записи результатов и промежуточных событий;
• Kibana – для визуализации содержимого индексов Elasticsearch;
• Job Manager кластера Apache Flink (в количестве одной штуки) – для управления кластером Flink;
• Task Manager кластера Apache Flink (в количестве одной штуки) – для выполнения DAG-графа операторов CDC-джоба.

Готовый docker-compose.yml можно скачать из гитхаба. Дальше начинаются уроки труда: «реализуем несложный сценарий захвата изменений из WAL PostgreSQL, приправленный объединениями, агрегацией, стеком ELK и целым кластером Flink, правда в миниатюре.»

Streaming JSON Data into Postgres with Open Source Kafka Sink Connectors

Пол Бребнер (Paul Brebner, Instaclustr) в части 6 (здесь начало) с Кафкой добрался до Postgres. Но кафкианских ужасов не дождались: всё интегрируется и взаимодействует. Instaclustr, где работает Пол, приобрела компанию Credativ, и теперь managed PostgreSQL на их «дорожной карте», отсюда и тяга разобраться в потрохах этого решения.

Итак, в этой статье PostgreSQL будет замещать Elasticsearch, а Apache Superset — Kibana, родственницу Elastic, в фазе анализа и визуализации.

Опуская промежуточные этапы, заметим, что для сброса данных в Postgres нужны Kafka Connect PostgreSQL Sink Connectors. Их несколько, в том числе опенсорсные. Огорчившись видом давно не обновляемых коннекторов, сбрасывающих поток JSON-ов в Postgres, Пол выбирает те коннекторы, что работают через JDBC-драйверы:

• IBM Kafka Connect sink connector for JDBC,
• Aiven Connect JDBC Connector,
• Apache Camel JDBC Kafka Sink Connector.

Спойлер: успеха удалось добиться только с кастомизированным под задачу IBM-коннектором.

Статья написана легко и даже весело. С интересными ссылками-отступлениями-отвлечениями:
Postgres как машина Тьюринга.

Головоломка Ханойская башня, реализованная на Postgres.
GTS2 — игра-стратегия на PostgreSQL + pl/python.

Кстати, о JDBC: встречайте JDBC 42.2.23.

Plv8-build: the easiest way to install PLV8 extension to current PostgreSQL release version

Алексей Фадеев со своими коллегами из компании sibedge поработали над пакетами для установки plv8 в Postgres 13. Теперь установить можно за считанные секунды — авторы предлагают проверить: вот для Linux, вот в Докере.

На эту работу, признаётся Алексей, их подвигнула статья Ивана Панченко aka x-wao PostgreSQL: Серверное программирование на «человеческом» языке (PL/Perl, PL/Python, PL/v8) годовалой давности.

Опыт хранения IP-адресов в PostgreSQL

Пишет некто slava-a из компании Karuna («мы лучшая компания в твоей жизни» — примерно всё, что можно узнать из профиля). Тема, однако, любопытная: в Postgres имеются типы данных inet/cidr для хранения IP-адресов. Создаётся табличка и к ней GiST-индекс. Чтобы найти, из какой страны IP, приходится строить функцию с циклом. На табличке с 1 млн адресов она отрабатывает почти за секунду.

Но оказывается, что есть расширение ip4r и оно даёт выигрыш в скорости выполнения поискового запроса в 20 раз. Дальше там есть ещё и про возможности гео-модуля для nginx.

Низкоуровневое обнаружение (LLD) в Zabbix через SQL-запросы

В блоге компании Galas Software («Интегратор, который работает исключительно с системами мониторинга») появилась статья, в которой для мониторинга используется расширение pg_stat_monitor от Percona (собирают из исходников). Он работает с pg_stat_statements, но агрегирует информацию. Когда в инструментах мониторинга анализируют информацию pg_stat_statements, обычно возникает вопрос сброса этой информации — когда и как. В pg_stat_monitor:

• собирается статистика и объединяется в корзину (агрегат);
• корзина собирается и хранится заданный период времени;
• когда время истекает, pg_stat_monitor сбрасывает всю накопленную статистику и начинает собирать её заново.

Простенько и со вкусом?

Читаются данные через Zabbix. Это почти мейнстрим. mamonsu, например, работает как активный агент (Zabbix Trapper). В статье создают шаблон в Zabbix для работы по ODBC, добавляют макросы к Zabbix, создают мастер-элемент данных, получают вывод в JSON и совершают ещё некоторые действия.

Мониторинг PostgreSQL. Расшифровка аудиочата Data Egret и Okmeter

Владимир Гурьянов, разработчик okmeter (на хабре он с построк-эротическим ником magvai69) опубликовал в блоге компании Флант («DevOps-as-a-Service, Kubernetes, обслуживание 24×7») расшифровку беседы с Алексеем Лесовским и Ильёй Космодемьянским из Data Egret.

Оглавление:

• Кто такие DBA, и чем они занимаются.
• Мониторинг БД и популярные системы.
• Ошибки при мониторинге баз данных.
• Сотрудничество Data Egret и Okmeter.
• Как Data Egret делятся знаниями и опытом.
• Об участии в Open Source-проектах.
• Аутсорсинг DBA и мониторинга.
• О важности soft skills для DBA.
• Вопросы слушателей

Postgres Observability

Истинное наслаждение нажимать на кнопочки номеров версий в произведении Алексея Лесовского Postgres Observability. При переходе с 13 на 14 кое-что меняется. Хотя куда меньше, чем 9.6 => 10. А при 10 => 11 в Observability не меняется вообще ничего. Но это буковки. Сама схема изменилась только 1 раз: в 12 => 13 серый прямоугольник Shared buffers поделился, отдал серый кусочек SLRU Caches. Но, может, я что-то пропустил. Поправьте.

Noisia 0.1.1. Harmful workload generator for PostgreSQL

Вредный генератор нагрузки. Нет, всё же Генератор Вредоносной Нагрузки. Это создание Алексея Лесовского умеет генерировать нагрузку, провоцирующую дедлоки, транзакции, которые ничего не делают, и запросы, которые сбрасывают на диск временные файлы. Зачем? Что не убивает, делает сильней (после настройки). Не пытайтесь повторить тесты без понимания возможных последствий: никаких гарантий, чистый шампанский риск.

Набор тестов на писан на Go. В версии 0.1.1 (до этого был только один релиз — 0.1.0) Go обновлён до версии 1.16.

Почему PostgreSQL тормозит: индексы и корреляция данных

Дмитрий Васильев, aka vadv, Ozon Tech, пишет о том, почему индексы не всегда ускоряют. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных, точнее: о статистической корреляции между физическим порядком строк и логическим порядком значений столбца.

Дмитрий создаёт табличку с полями:

corr — последовательно заполняемым числами от 1 до 10 000 и uncorr — рандомными значениями uuid_generate_v4() (для чего устанавливается расширение uuid-ossp). В поле correlation представления pg_stats это соответствует значениям 1 и ~0 соответственно. По corr и uncorr создаются индексы и далее исследуются средствами расширения pageinspect. В uncorr данные разбросаны по страницам, и в худшем случае придётся прочитать с диска почти столько страниц (совершить пропорциональное количество IOPS), сколько собираемся вернуть строчек. Дмитрий натравливает на индекс CLUSTER, и получает выигрыш по IOPS в 50 раз.

Ближе к финалу Дмитрий рассказывает о полюбившемся ему ULID (UniversallyUnique LexicographicallySortable Identifier), который лишён недостатков UUID. Его можно использовать при секционировании: generate_ulid(now()) и constraint дадут возможность планировщику выбирать правильную секцию при построении запроса, если в запросе участвует время.

Using GDB To Trace Into a Parallel Worker Spawned By Postmaster During a Large Query

Блогеры High Go начинали с простеньких заметок в жанре 4 dummies, но, чем дальше, тем глубже, засучив рукава, забираются под капот Postgres. Кэри Хуань (Cary Huang) — канадский разработчик High Go, сейчас перерабатывает функциональность, связанную с видимостью записи. И вот он столкнулся с тем, что его код не отрабатывает корректно только в одной ситуации: когда запрос запускает несколько параллельных процессов (workers). Часть данных пропадает из-за того, что ядро считает их невидимыми, в то время как другая часть видима. Чтобы выяснить, что происходит с патчем, он запускал GDB, отслеживая порожденные параллельные процессы и проверяя видимость записей. И решил поделиться опытом использования GDB в этой ситуации.

Вместо вступления автор отсылает к своей же статье об использовании GDB: How to Analyze a PostgreSQL Crash Dump File, а мы ещё и нескромно напомним о нашей с Александром Коротковым статье, где проблемы с параллелизмом исследуются ещё и с perf и флейм-графами: Параллелизм в PostgreSQL: не сферический, не конь, не в вакууме.

Поскольку ухватить PID форкнутого процесса не так просто (он может завершиться раньше, чем мы увидим PID), Кэри внедряет брейкпоинт в код функции RegisterDynamicBackgroundWorker и ParallelWorkerMain. После прерывания и нашего continue дебаггер напишет номер нового процесса и будет отслеживать уже его. А дальше — по вкусу.

Control Runaway Postgres Queries With Statement Timeout

Статья Крейга Керстинса (Craig Kerstiens, Crunchy Data) посвящена всего одному параметру: statement_timeout, который, правда, может задаваться на разных уровнях: запрос/пользователь/база данных.

Настройка таймаута может оказаться критичной в ситуации, когда:

• интенсивная бизнес-логика или отчёты требуют сканирования большого числа записей и происходит агрегация;
• миграция базы данных, изменяющая очень много записей;
• плохо написанные запросы, когда JOIN трогает миллионы записей;
• расходящиеся рекурсивные запросы.

Для какого-нибудь сверхдолгоиграющего миграционного запроса можно задать в сессии:

SET statement_timeout = '30m';

Для обычных хватает и

ALTER DATABASE mydatabase SET statement_timeout ='60s';

Менее сфокусированные рекомендации по тюнингу базы есть у коллеги Крейга — Тома Шварца (Tom Swartz) — Optimize PostgreSQL Server Performance Through Configuration. В статье Крейга попалась ещё одна любопытная ссылка: Range Types & Recursion: How to Search Availability with PostgreSQL.

Benchmarking CentOS vs Rocky Linux with Postgres

Динеш Кумар (Dinesh Kumar, MigOps) проверяет производительность на наборах тестов Phoronix:

• компилятор;
• процессор;
• память;
• диск;
• стресс (stress-ng);
• PostgreSQL (pgbench);
• (stress-ng + pgbench)

Результат: Rocky на всех тестах чуть быстрее => можно пересаживаться с CentOS на Rocky.

dbForge Schema Compare for PostgreSQL v.1.2

В новой версии этого визуального пакета для сравнения схем, который разрабатывает и поддерживает компания devart с штаб-квартире в Чехии и разработчиками из Украины, появились:

• Object Filter, с ним можно разворачивать базу, исключая объекты при синхронизации в соответствии с условиями, заданными в фильтре;
• экспорт отчёта в форматы HTML, Excel и XML;
• дополнительные пре- и пост-синхронизационные скрипты, которые отрабатываются в начале и в конце синхронизации схем;
• поддержка материализованных представлений в Amazon Redshift;
• возможность работать с облаком Heroku;
• новые косметические возможности: расцвечивать несоответствия кода в окне Text Compare (diff).

Accessing PostgreSQL databases in Go

Статья Эли Бендерского (Eli Bendersky), знакомого любителям Go — серию его статей Разработка REST-серверов на Go перевели и выложили на хабр, например, в блоге компании RUVDS.com. В этой статье автор рассматривает несколько вариантов доступа:

• библиотека database/sql с драйвером pq,
• драйвер и тулкит pgx,
• пакет sqlx.

Эти варианты пробуют на демо-базе. Есть и общие соображения по поводу (не)использования ORM в Go.

Increasing Max Parallel Workers Per Gather In Postgres

Майкл Кристофидес (Michael Christofides), составляющий половину команды pgMustard, не только выступил на PgDay с докладом EXPLAIN: beyond the basics, но и опубликовал, в числе прочего, эту заметку о параметрах при распараллеливании запросов. Там нет ни глубокомысленных рассуждений об оптимальном распараллеливании на многоядерных и многоузловых машинах, не балует он диаграммами производительности. Но зато есть полезные ссылки: сама тема уж очень актуальна — лишнее напоминание не помешает.

Он же напоминает о существовании parallel_setup_cost, parallel_tuple_cost, min_parallel_table_scan_size, min_parallel_index_scan_size, например (об этом есть здесь).

Майкл ссылается на Как работают параллельно выполняемые запросы (How Parallel Query Works), советует глянуть справочные материалы и ссылки на сайте postgresqlco.nf и послушать семинар PostgreSQL Parallelism Do’s and Don’ts Себастьяна Дресслера (Sebastian Dressler) из swarm64 на канале Postgres Conference. А вот там действительно есть и разбор планов, и сравнение времени выполнения в зависимости от настроек, удачные и неудачные запросы с точки зрения параллелизма. И вообще в swarm64 (о которой мы немного писали в Postgresso 32, 30, 21) обзавелись парой дюжин видео об ускорении параллельных запросов (как с их FPGA, так и без).

PG-Strom 3.0

Напомним: это расширение PostgreSQL, которое поддерживает GPU. В этой версии:

• появилась поддержка NVIDIA GPUDirect Storage (cuFile);
• несколько PostGIS-функций можно гонять на GPU;
• поддержка GpuJoin с индексом GiST;
• механизм GPU Cache переделан;
• появилась поддерка кастомных типов данных/функций/операторов для GPU, но пока в экспериментальном режиме;
• лицензия переехала с GPLv2 на PostgreSQL.

Интересная, странная тема: казалось бы, распараллеливание вычислений — что может быть актуальней? Но базы не слишком охотно параллелятся, и такие проекты как Strom (или Swarm64) явно не в фокусе внимания. Видны периферийным db-зрением.

Modern data analysis with PostgreSQL – JSONB throws Window functions out the…

А вот это пишет Томас Рихтер (Thomas Richter) уже из самой Swarm64. По мотивам реальных событий. Томас начинает с изложения традиционного подхода к анализу заказов/доставок в электронном магазине, а именно: к двум таблицам — orders (заказов) и order_shipment_status (статусов доставки заказов). Они соединяются по order_id в отношении один-ко-многим. Далее Томас выуживает пропавшие заказы с помощью запроса с оконными функциями. Всё работает, но запрос такой дорог.

Томас человек современный, поэтому он вместо двух таблиц просто добавляет колонку типа jsonb со статусами в таблицу заказов orders. Он использует json-операторы @>, ->, ->>, || и GIN-индекс. Вместо соединения двух таблиц мы теперь просто обновляем поле в таблице в соответствующей строке. Он, кстати, считает, своей растущей популярностью Postgres обязан таким вот современным возможностям.

Cut Out the Middle Tier: Generating JSON Directly from Postgres

Пол Рамси (Paul Ramsey, Crunchy Data) предлагает убирать генерацию JSON из промежуточных слоёв Web-сайтов, где это можно — а такое случается часто — и использовать средства самого PostgreSQL, благо они уже довольно развиты. Начинает Пол с row_to_json(), потом json_agg(), но это разминка: дальше Пол, используя запросы с CTE, формирует вложенные структуры JSON на выходе, которые отражают взаимосвязь таблиц. Postgres может генерить самые разнообразные JSON, которые можно сразу отдавать приложению, а иногда даже конечному пользователю.

Наш отдел образования рекомендует прекрасную книгу Г.Домбровской, Б.Новикова и А.Бейликовой на эту тему: PostgreSQL Query Optimization: The Ultimate Guide to Building Efficient Queries. В ней они развивают идею о преодолении несоответствия между реляционной и объектно-ориентированной моделью данных с помощью транспортного уровня, для которого удобно использовать JSON. И вот тут-то генерация и разбор JSON внутри базы данных очень важны. ДМК Пресс активно работает над переводом, книга скоро выйдет на русском языке.

Гибридное использование RDBMS и NoSQL подходов для обработки транскриптомных данных

Что такое транскриптома я пока не разобрался, но точно, что и PostgreSQL 12, и JSON здесь используются для вполне актуальных биотехнологических задач. Для нас, читателей, тут важно, что надо хранить в БД и структурированную, и слабо структурированную информацию таким образом, чтобы удобно было составлять разнообразные, иногда сложные запросы. К десяткам и сотням тысяч генетических последовательностей в результате секвенирования, надо дать свободный и удобный доступ широкому кругу биологов — пусть ищут, что им нужно.

Некоторые данные вполне вписываются в реляционную модель данных, но в общем случае невозможно заранее полностью декларировать структуру данных, которая будет получена в результате обработки лабораторных результатов. То, что плохо структурируется, хранится в столбцах типа jsonb. Для таких данных столбцы индексировали как GIN. Запросы к таким данным используют операторы -> и ->>.

Самое интересное, что для поиска используется и тип ts_vector, для чего в ход идут функция to_tsvector() и оператор @@ — как в обычном полнотекстовом поиске. Ведь ген — это своеобразный текст.

DB Connection Calculator

Для облачной PaaS-платформы Heroku, в которую входит и Heroku Postgres придумали калькулятор — Heroku Database Connection Calculator — вы задаёте движочками количество dyno (dyno — это такие херокские контейнеры для приложений, они бывают web dynos и worker dynos), воркеров, процессов и тредов и получаете количество нужных соединений. В плане Heroku Postgres количество соединений ограничено 500, но можно запустить PGBouncer. Калькулятор сделали для Heroku в Rails Autoscale.

Конференции

PG Day'21 Russia

Записи докладов #PGDayRussia 2021 доступны на YouTube-канале конференции

Например:

• Что нового в плане мониторинга в PostgreSQL Алексей Лесовский
• Алгоритмы и структуры данных: PostgreSQL Edition (Андрей Бородин)
• Возможности интеграции PostgreSQL с ClickHouse (Ксения Сумарокова)
• Инты, массивы, внешние ключи, наследование (Иван Панченко)
• Миграция в облако: технологии, люди и процессы (Всеволод Грабельников)
• Внедрение HighLoad BI на PostgreSQL в крупнейших корпорациях: опыт ГК Luxms (Дмитрий Дорофеев и Сергей Шестаков)
• Greenplum в корпоративной аналитической платформе Сбера (Дмитрий Добров)
• Сдвигаем тестирование БД влево (Николай Самохвалов)
• Can Postgres scale like DynamoDB? (Álvaro Hernández, OnGres)
• Protecting your data with Patroni and pgbackrest (Federico Campoli, Kamedata)