Продолжаем экспериментировать с форматом: в этом выпуске нет раздела Релизы, но несколько релизов разбросаны по соответствующему контексту.
Люди
Список коммитеров прирос Даниэлем Густафссоном (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):
Мы не раз рассказывали о 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, так и без).
Напомним: это расширение 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() и оператор @@ — как в обычном полнотекстовом поиске. Ведь ген — это своеобразный текст.
Для облачной 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-канале конференции
Например:
Внедрение HighLoad BI на PostgreSQL в крупнейших корпорациях: опыт ГК Luxms (Дмитрий Дорофеев и Сергей Шестаков)
Greenplum в корпоративной аналитической платформе Сбера (Дмитрий Добров)
Сдвигаем тестирование БД влево (Николай Самохвалов)
Can Postgres scale like DynamoDB? (Álvaro Hernández, OnGres)
Protecting your data with Patroni and pgbackrest (Federico Campoli, Kamedata)
Комментариев нет:
Отправить комментарий