Свободная система управления базами данных PostgreSQL не только предоставляет высокопроизводительный движок для выполнения запросов, но и может быть расширена с помощью расширений, которые могут добавлять новые типы данных (например, для ГИС‑расширений или астрономических координат), дополнительные типы индекса и возможности поиска (например, полнотекстовый поиск), сбор статистики, поддержку новых языков для встроенных функций и многое другое. Большой список существующих расширений может быть найден по этой ссылке. В этой статье мы рассмотрим один из возможных вариантов по созданию собственного расширения для PostgreSQL с использованием библиотеки pgx.

Большие данные — вещь относительная. Посмотрите на любого блогера: он генерирует кучу данных, в его телефоне десятки, а то и сотни гигабайтов изображений и видео. Если он не может обработать их с помощью подручных средств, их вполне можно считать большими данными.

При этом оцифрованная Библиотека конгресса в США совсем маленькая, хранить ее у себя дома может любой. Телескопы, на которых работают в Америке, могут производить несколько десятков терабайт за одну ночь. А радиотелескоп, размер которого квадратный километр, будет производить петабайты.

Уже несколько лет назад я столкнулся с проблемой производительности 1С на PostgreSQL в некоторых запросах, которые на MS SQL выполнялись относительно быстро. Тогда же выяснилось, что в 99% случаев такие запросы можно оптимизировать так, что они начинают выполняться даже быстрее, чем на MS SQL, всего навсего добавлением нужных индексов во временные таблицы.

В большинстве учетных систем, типа нашего СБИС, рано или поздно возникает проблема быстрого отображения реестра, в который по просьбам бизнес‑пользователей накручено несколько комбинируемых фильтров с очень редкой выборкой, ну никак не ложащихся в вашу красивую структуру базы данных и индексов базовой таблицы реестра — что‑нибудь типа "список продаж покупателям, чей день рождения выпадает на 29 февраля".

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

В этом номере самое интересное за январь начало февраля 2023. В том числе, конечно, о релизах

PostgreSQL 15.2 и Postgres Pro Enterprise 15.1.1

Продолжаем следить за новинками 16-й версии. В начале февраля завершился четвертый коммитфест. Что нового нас ждет впереди?

Напомню, что самое интересное из первых трех коммитфестов можно прочитать в предыдущих статьях серии: 2022-07, 2022-09, 2022-11.

Репликация PostgreSQL с опережающей записью (WAL) — ключевая концепция в высоконагруженных архитектурах, поскольку она позволяет создавать высокодоступные и отказоустойчивые системы баз данных.

Привет! Меня зовут Дима Вагин, я бэкенд-инженер в Авито. Сегодня расскажу, как мы работаем с БД PostgreSQL из Go. Покажу, какие библиотеки и пулеры соединений мы используем для доставки в код параметров подключения и как мы их настраиваем. А ещё расскажу про проблемы, к которым приводит отмена контекста, и о том, как мы с ними справляемся.

Шаблон backend сервера на Golang — часть 3 (Docker, Docker Compose, Kubernetes (kustomize)

Первая часть шаблона посвящена HTTP серверу.

Вторая часть шаблона посвящена прототипированию REST API.

Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).

Четвертая часть будет посвящена развертыванию в Kubernetes с Helm chart и настройке Horizontal Autoscaler.

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

Для корректного развертывания в Kubernetes, в шаблон пришлось внести изменения:

• способа конфигурирования — YAML, ENV, Kustomize
• подхода к логированию — переход на zap
• способа развертывания схемы БД — переход на liquibase
• добавление метрик prometheus

Ссылка на новый репозиторий.

Шаблон goapp в репозитории полностью готов к развертыванию в Docker, Docker Compose, Kubernetes (kustomize), Kubernetes (helm).

Настоящая статья не содержит детального описание используемых технологий

Содержание

1. Изменение подхода к конфигурированию
2. Добавление метрик prometheus
3. Изменение подхода к логированию
4. Развертывание схемы БД
5. Сборка Docker image
6. Сборка Docker-Compose
7. Схема развертывания в Kubernetes
8. Подготовка YAML для Kubernetes
9. Kustomization YAML для Kubernetes
10. Тестирование Kubernetes с kustomize

Сегодня открою вам Америку на основе данных OpenStreetMap в PostgreSQL15/PostGIS и моего проекта openstreetmap_h3. Запустим запрос и сравним время его выполнения на колоночном хранилище Citus в PostgreSQL и на стандартном в секционированной по H3 геоиндексу базе данных объемом 100GB.

Найдем top15 мест по застройке а Северной Америке и общую протяженность дорог, а также их тип и покрытие. Не буду перегружать публикацию логами программ, сфокусируемся на данных! Вы можете легко повторить все запросы самостоятельно на своем компьютере или ноутбуке.

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

Продолжим тему из публикации «Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap».

Сегодня визуализируем 15 мест где в России больше всего зданий. В этом нам поможет мой проект openstreetmap_h3 и PostgreSQL 15. На данный момент OpenStreetMap H3 единственное решение для импорта OSM данных партиционированных по H3 геоиндексу в PostgreSQL и Citus massive parallel processing. Сохраним данные в колоночное хранилище и посмотрим на план запроса для него.

В этой публикации мы будем агрегировать данные в большой таблице где нас интересуют для этих операций лишь два столбца и сможем извлечь пользу от этой модели данных на NVMe накопителе. Раньше я работал с колоночными базами данных AWS Redshift, Dremio, QuestDB и HeavyDB, но не смотря на их производительность, до функционала/протестированности и стабильности PostgreSQL им еще пока еще ох как далеко. Вот и отлично, попробуем получить все плюсы экосистемы PostgreSQL и колоночного хранилища citus. Вперед, к заветной цели на самых свежих версиях программ нашего аналитического стека!

 ORM (Object‑Relational Mapping) используется во многих языках программирования, в том числе и в 1С. Однако реализация высоконагруженных решений, приводит к мысли что разработчики ORM не учитывали ее влияния на производительность СУБД. Такая ситуация и в 1С и ORM на Java, и наверняка в других ORM.  В предыдущих частях показана глубина проблемы

Концепция ORM как двигатель прогресса — выдержит ли ее ваша СУБД? / Хабр (habr.com)

Концепция ORM как двигатель прогресса – выявит слабое место Вашей СУБД / Хабр (habr.com)

В этой части предложено решение со стороны СУБД (MS SQL , Oracle, Postgres)

Зачем же обычному человеку информация из прошлой публикации "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap"? Если надоело в пятницу читать мемасики и лайкать фотографии котиков в соцсетях, то можно задаться глобальными проблемами аналитики и посчитать протяженность дорог России. Ведь не за горами времена автомобилей с автопилотами... Это конечно не 42, как ответ на главный вопрос жизни, вселенной и всего такого, но результаты будут тоже достаточно лаконичными.

Для этого нам понадобится ноутбук или обычный десктоп, несколько десятков гигабайт свободного места, установленный docker, JVM 11+, maven и мой проект openstreetmap_h3. Анализировать геоданные мы будем с помощью PostgreSQL 15.1, PostGIS 3.3.2, H3 4.1.1. Исходные данные из проекта OpenStreetMap, запросы к БД не претендуют на правильность и качество исходных данных в масштабе страны нам не известно! Данная публикация является грубой интерпретацией данных OSM в первом приближении и не претендует на истинность и неопровержимость. Так же как не стоит верить оценке Хабра на чтение статьи в 127 минут, что сильно превышает реальные 5 минут, которые вы потратите на ознакомление с публикацией.

Данная статья посвящена способам повышения производительности PostgreSQL и EDB Postgres Advanced Server (EPAS) с 10 по 13 версии. Мы начнём с аппаратного обеспечения и будем двигаться вверх по стеку, оставив напоследок SQL-запросы. 

Продолжу рассказ "Как поместить весь мир в обычный ноутбук: PostgreSQL и OpenStreetMap" секретами о геоданных OpenStreetMap, на которых множество компаний построили бизнес но не все делятся подробностями... Что ж, сегодня приоткроем завесу!

База данных в PosgreSQL после загрузки из дампа занимает больше 587 GB. Это уже по меркам СУБД большая база и одна огромная таблица на каждый тип объектов не сработает. Для управляемости такие данные надо секционировать, хорошо что PostgreSQL поддерживает декларативное секционирование данных. Осталось лишь придумать как разделить географические данные. После поисков и сравнений мне на помощь пришла иерархическая гексагональная геопространственная система индексирования H Все это было реализовано в моем проекте openstreetmap_h3 для быстрой обработки и загрузки мира в базу.

Привет, Хабр! В этом посте мы поговорим о том, как происходит подключение к внешней СУБД для BI-платформы Visiology, а также разберем ситуации, когда это действительно нужно. Под катом — подробный разбор возможностей SQL backend, которым может воспользоваться сегодня фактически каждый пользователь Visiology. Кроме этого мы остановимся на нюансах подключения различных СУБД, а также обсудим, в каких ситуациях можно “сесть на два стула” и получить как скорость расчетов, так и поддержку бигдаты для очень больших объемов данных.

Тема с testcontainer-ами относительно не новая, первые статьи на англоязычных ресурсах встречаются с 2016 года, но не смотря на это, до сих пор на просторах веба крайне мало гайдов для их развертывания из коробки. В большинстве своем это туториалы, где собрана солянка из зависимостей и аннотаций, которые мало того, что не нужны, но еще и могут запутать разработчика, решившего  с ними познакомиться. В этой статье я опишу свой практический кейс по развертыванию тестовых контейнеров для базы данных PostgreSQL. Основная задача их использования - быстрый deploy нужного сервиса в контейнере за небольшое время. В дополнении для наглядности запустим туда FlyWay миграции.