PostgreSQL *

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

Когда человек раньше говорил что он контролирует весь мир, то его обычно помещали в соседнюю палату с Бонапартом Наполеоном. Надеюсь, что эти времена остались в прошлом и каждый желающий может анализировать геоданные всей земли и получать ответы на свои глобальные вопросы за минуты и секунды. Я опубликовал Openstreetmap_h3 — свой проект, который позволяет производить геоаналитику над данными из OpenStreetMap в PostGIS или в движке запросов, способном работать с Apache Arrow/Parquet.

Первым делом передаю привет хейтерам и скептикам. То что я разработал — действительно уникально и решает проблему преобразования и анализа геоданных используя обычные и привычные инструменты доступные каждому аналитику и датасаенс специалисту без бигдат, GPGPU, FPGA. То что выглядит сейчас простым в использовании и в коде — это мой личный проект в который я инвестировал свои отпуска, выходные, бессонные ночи и уйму личного времени за последние 3 года. Может быть я поделюсь и предысторией проекта и граблями по которым ходил, но сначала я все же опишу конечный результат.

Первый пост не претендует на монографию, начну с краткого обзора...

В статье рассказываем, как оптимизировать базу данных PostgreSQL на примере Linux на IBM Z. Опираясь на представленные примеры, вы шаг за шагом узнаете, какие опции и параметры конфигурации улучшат установку PostgreSQL с точки зрения:

Приветствую!

На прошлом шаге мы дошли до входной точки Postgres. Сегодня мы пройдемся по ней до главного цикла. Будут рассмотрены:

— Модули для работы с файлами и файловой системой

— Как SIGUSR1передает множественные значения

— Реализации хэш‑таблиц

— Представление и хранение GUC

и многое другое.

Можно ли найти конкретного человека, жившего в XVII веке? Выражаясь современным языком «пробить по базам». Оказывается, архивные документы хранят массу информации об обычных людях того периода. Однако существует ряд сложностей, не позволяющих обычному исследователю добраться до этой информации. Во-первых, нужно пройти определённую процедуру по получению доступа в архив. Во-вторых, не всегда можно выйти на нужный документ, используя так называемый научно-справочный аппарат – различные описи и реестры документов, имеющиеся в архиве. Наконец, не имея навыков чтения документов XVII века, которые написаны скорописью, почти нереально ознакомиться с его содержанием.

Данные проблемы предполагается решить с помощью создания базы данных служилых людей XVII века. Об этом небольшая история.

Как всё начиналось.

Привет! Меня зовут Дмитрий и вот уже более 10 лет я изучаю историю южных уездов России XVII века. Территориально – это современные Белгородская, а также соседние Воронежская, Курская, Липецкая и другие области. Населены они были тогда так называемыми служилыми людьми – они получали здесь в качестве служебного жалования земельные наделы, которые сами и обрабатывали. В XVIII веке их потомки стали однодворцами, а затем государственными крестьянами. Большая часть населения Курской, Воронежской и соседних губерний XIX века происходят из тех самых служилых людей XVI–XVII веков.

Summary: Сотрудники Лиги Цифровой Экономики Юлия Крашеница, DBA PostgreSQL, Андрей Ходус, ведущий эксперт, и Елена Жикривецкая, старший эксперт PostgreSQL, рассказали об особенностях миграции с системы управления базами данных Oracle на PostgreSQL и возникших сложностях, а еще поделились своим опытом их решения.

В статье описывается один из способов обновления дистибутива операционной системы с работающим кластером баз данных Postgres Pro Standard версии 11. В дальнейшем, для краткости кластер баз данных Postgres Pro Standard 11 будем называть Postgrespro, Centos7 - Centos, а AlmaLinux8 - Almalinux. Способ заключается в том чтобы настроить физическую репликацию Postgrespro между разными дистрибутивами операционной системы с последующим переводом слейва в режим мастера. При чтении множества статей о настройке физической репликации я нигде не встречал упоминание о том, что так делать нельзя. Естественно, что архитектура Centos и Almalinux должны совпадать, а так же должны совпадать мажорные версии Postgrespro.

Сегодняшняя задача вполне традиционна для любых учетных систем - поиск записей, содержащих максимальное значение по каждому из ключей. Что-то вроде "покажи мне последний заказ по каждому из клиентов", если переводить в прикладную область.

Кажется, что тут и споткнуться-то негде в реализации - но все оказывается совсем не тривиально.

Резервное копирование является одной из основных задач администрирования баз данных. Отсутствие бэкапа может привести к катастрофическим последствиям при эксплуатации базы данных. Однако недостаточно только настроить регулярное создание резервных копий, необходимо также регулярно проверять созданные копии на способность к восстановлению БД. В этой статье мы поговорим от том, как правильно настраивать резервное копирование в БД PostgreSQL.

У нас не подгорит!

Как PostgreSQL хранит большие значения столбцов? Какие явные и неявные ограничения есть у существующего механизма хранения? Что за проблемы вызваны этими ограничениями? И как можно решить эти проблемы, и расширить возможности PostgreSQL? Об этом, и чуть больше - данная статья.

Даже самый простой SQL запрос можно выполнить по-разному. Но из всех вариантов СУБД нужно выбрать оптимальный, как же это сделать? Неужели придётся перебрать все возможные варианты? Давайте разбираться.

В этой статье поговорим о Greenplum — СУБД, основанной на PostgreSQL. Разберём её общую архитектуру, способы хранения данных, а также перечислим проблемы, с которыми можно столкнуться в ходе эксплуатации.

Эта статья описывает реализацию 64–битных счётчиков транзакций (XID, ксидов) в СУБД Postgres Pro Enterprise, которая создана на основе свободной, опенсорсной объектно–реляционной СУБД Postgres. Она ориентирована на тех, кто имеет практический опыт в работе с СУБД Postgres Pro Enterprise, но будет интересна и тем, кто интересуется развитием СУБД Postgres, так как описывает сравнение этих двух систем. Статья также описывает устройство таблиц на диске и организацию формата хранения данных отношений.

Postrges старается быть максимально гибким в конфигурации, чтобы удовлетворить запросы как можно большего числа своих пользователей. Большинство параметров, например, таких, как: размер страницы BLCKSZ (по умолчанию 8 кБ), размер сегмента SEGSIZE (по умолчанию 1 Гб), могут быть изменены при сборке Postgres.

Хотелось бы сразу обозначить, что мы будем рассматривать 64–битный вариант сборки Postrges, в котором все параметры имеют значение по умолчанию. Также мы не будем углубляться в мультитранзакции. Для целей этой статьи будет достаточным предположения, что они в данном контексте аналогичны "обычным" транзакциям.

Мы выложили наш вариант реализации в сообщество, а также занимаемся активным продвижением его в сообществе разработчиков Postgres. Он не на 100% идентичен коду, используемому в Postgres Pro Enterprise (в частности, там ксиды всё ещё образуют кольцо), но общая идея такая же, как изложена в статье. На текущий момент патч ожидает ревью. Мы верим, что этот патч положительно скажется на удобстве использования и устойчивости Postgres, надеемся, что он будет принят сообществом в ближайшем будущем. Тем не менее по этому вопросу предстоит ещё много работы. Поэтому мы будем благодарны всем желающим и небезразличным за посильное участие в его развитии.

PostgreSQL 16: Часть 3 или Коммитфест 2022-11

Вышел очередной обзор Павла Лузанова. Самое интересное из первых коммитфестов можно прочитать в предыдущих статьях серии: 2022-07 (ru / en), 2022-09 (ru / en).

Postgres-сообщество и образование

Что для вас PostgreSQL-комьюнити?

Живёт своей жизнью затея Райана Буза (Ryan Booz) - его Пятнецы (PGSQL-Phridays). На 3-м этапе этого флеш-моба ход Пэта Райта (Pat Wright). В отличие от обычных пятниц и PG-пятнец Шона Томаса, PGSQL-пятнецы случаются раз в месяц, и эта, 3-я пятнеца в 2022-м последняя. И вот вопрос: желающих приглашают ответить на вопрос: What is the PostgreSQL community to you?

Привет! Я Андрей Непряхин, руководитель направления QA в AGIMA. Вот уже год как мы работаем над мобильным приложением платформы Финуслуги, созданной Московской биржей. Это первая и единственная платформа личных финансов в России. За этот год мы освоили целый ряд новых технологий, поняли, как обеспечивать качество крупного финтех-проекта, но главное — научились работать в огромной команде. Как мы сделали процесс тестирования измеримым, а взаимодействие с разработчиками прозрачным — расскажу в этой статье.

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

Мы на пальцах рассмотрим что такое шардирование, как оно помогает в масштабировании и даже рассмотрим тот самый этап «роста».

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

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

Продолжаем изучать исходный код PostgreSQL

В этот раз исследуем главный цикл сервера:

- Принятие входящих подключений;

- Проверка окружения;

- Обработка упавших воркеров.