Обратился к нам клиент с просьбой обновить PostgreSQL до самой свежей версии, а заодно и научить его китайскому.
Точнее, оптимизировать процесс полнотекстового поиска на китайском, ибо тормозило все это дело нещадно.

Ниже описано как это нами было сделано.
Сразу перейдем к делу.

Массивы являются мощным средством программирования, часто используемом разработчиками, как в Java так и PL / PgSQL. Интерфейсы потенциально могут стать сложнее, например, когда два из них пытаются и общаются друг другом. В этом разделе рассматривается, как можно написать простой код, который использует java.sql.Array интерфейс для вставки, извлечения, и обновления массивов в PostgreSQL.

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

CREATE TABLE city_example (
country TEXT, 
cities TEXT[]
);

Теперь мы будем использовать JDBC интерфейс для добавления, получения и изменения данных в этой таблице.

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

Один из наших клиентов, эксплуатирующий PostgreSQL под большой нагрузкой, столкнулся с проблемой, связанной с переполнением счетчика транзакций (xid wraparound), причем выхода из нее штатными средствами не существовало. Мы решили проблему с помощью хирургического вмешательства и выпустили патч, предотвращающий возникновение таких ситуаций в будущем.

В этой заметке мы расскажем, как и почему может произойти проблема и как ее не допустить.

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

Этой статьей мы начинаем цикл заметок об использовании PostgreSQL в Microsoft Azure.

Первая статья будет об установке и настройке кластера PostgreSQL:

• Знакомство с ресурсами Azure
• Управление через azure cli
• Выбор подходящего хранилища
• Сборка классической связки ведущий-ведомый в одной группе доступности

Что это и зачем нужно?

Предположим у вас есть крупное новостное издание, у которого много разных типов материалов.

Для каждого типа материала существует своя модель: Topics::Article, Topics::Online, Topics::NewsItem и так далее. У них будут одинаковыми большинство полей, такие как заголовок, обложка, текст, авторы. Различие только в нескольких специфичных полях, уникальных для каждого типа топика.

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

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

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

Данные в журнал пишутся до того как пользователь базы данных получит сообщение об успешном применении изменений. Этот журнал называется журналом упреждающей записи (Write-Ahead Log или просто WAL), а файлы журнала хранятся в каталоге pg_xlog. Также периодически PostgreSQL сбрасывает измененные аккумулированные данные из оперативной памяти на диск. Этот процесс согласования данных называется контрольной точкой (checkpoint). Контрольная точка выполняется также при каждом штатном выключении PostgreSQL.

Информация о том, с какими внутренними значениями завершилась контрольная точка, хранится в файле global/pg_control и потому этот файл должен быть доступен СУБД еще до момента восстановления данных. Если PostgreSQL отключается нештатно, то изменения из файлов журнала (pg_xlog) применяются к файлам БД, начиная с позиции последней контрольной точки. Этот процесс называется восстановлением данных.

В файле pg_control находится информация:

• версия формата control-файла,
• контрольная сумма записанных в этот файл данных,
• версия формата файлов БД,
• уникальный идентификатор экземпляра БД,
• текущее состояние: работает/остановлен,
• позиция в журнале, соответствующая запущенной и предыдущей контрольным точкам,
• текущая ветвь времени (timeline),
• максимальный видимый номер транзакции (xid),
• максимальный номер внутреннего счетчика объектов (oid),
• время создания,
• и многое другое.

Посмотреть содержимое pg_control можно при помощи утилиты pg_controldata:

$ pg_controldata /var/lib/pgsql/9.5/data

pg_control version number:            942
Catalog version number:               201510051
Database system identifier:           6242923005164171508
Database cluster state:               in production
pg_control last modified:             Fri Apr 29 01:00:00 2016
Latest checkpoint location:           EEAF/BAA5520
Prior checkpoint location:            EEAF/BAA5440
...
Latest checkpoint's NextXID:          7/876524573
Latest checkpoint's NextOID:          264355612
Latest checkpoint's NextMultiXactId:  134512401
Latest checkpoint's NextMultiOffset:  547842659
...

На обучающих занятиях по PostgreSQL, и на продвинутом, и на базовом курсах, я часто сталкиваюсь с тем фактом, что обучающиеся практически ничего не знают о том, насколько мощными могут быть индексы по выражениям (если они вообще знают об их существовании). Так что позвольте мне сделать для Вас небольшой обзор.

Сегодня давайте поговорим о преимуществах Postgres перед другими системами с открытым кодом. Эту тему мы обязательно раскроем более подробно на PG Day'16 Russia, до которой осталось всего два месяца.

Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.

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

Сразу же предупрежу о велосипедности выдаемого здесь на обозрение. Если прочтение заголовка вызывает лишь с трудом подавляемый возглас «Твою мать, только не новый таксон ORM!», то лучше наверное воздержаться от дальнейшего чтения, дабы не повышать уровень агрессии в космологическом бульоне, в котором мы плаваем. Виной появлению данной статьи явилось то, что в кои-то веки выдался у меня отпуск, в течение которого решил я попробовать себя на поприще написания блогопостов по околохабровской тематике, и предлагаемая тема мне показалась вполне для этого подходящей. Кроме того, здесь я надесь получить конструктивную критику, и возможно понять чего же еще с этим можно сделать этакого интересного. В конце будет ссылка на github-репозиторий, в котором можно посмотреть код.

Всем привет!
После долгого перерыва блудный Python Meetup снова с нами. На долгожданной мартовской встрече сообщества любителей и профессионалов языка программирования Python обсуждались животрепещущие темы: противостояние Python и Erlang, а также дополнительные возможности PostgreSQL.
Видеозаписи выступлений под катом. Приятного просмотра!

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

Сам проект написан на Django, в качестве бекенда — PostgreSQL. В самом начале работы было решено, по крайней мере, частично отказаться от использования Django ORM в пользу «сырого» SQL и хранимых процедур. Другими словами, почти вся бизнес-логика вынесена на уровень базы данных. Сразу скажу, что готовить ORM я умею, но в данном случае требовалось производить многоступенчатые вычисления, связанные с множеством выборок, а это лучше делать на сервере БД и не таскать промежуточные данные в приложение.

Столкнувшись с необходимостью поддержания структуры базы данных вручную, без приятностей Django Migrations, я выяснил, что вручную писать инкрементальные SQL патчи возможно, но трудно уследить за зависимостями объектов БД. К примеру, когда функции, которая используется где-то еще, добавляешь еще один аргумент, простого CREATE OR REPLACE недостаточно — ее нужно сначала DROP, а потом CREATE. При этом нужно предварительно удалить зависимые от нее функции, а потом создать заново (а если от этих функций еще кто-то зависит, тогда надо и их пересоздать).

Под катом краткое описание возможностей в виде туториала. Встречайте — Sqlibrist.

Мы продолжаем готовиться к PG Day’16 и знакомить вас с интересными возможностями PostgreSQL.

В предыдущих постах этой серии я говорил о том, как читать вывод EXPLAIN и что означает каждая строка (операция/узел).

В заключительном посте я постараюсь объяснить, почему Постгрес выбирает «Операцию X», а не «Операцию Y».

Иногда вам нужно определить какому файлу на диске соответствует таблица. У вас имеется путь, полный цифр, такой как base/16499/19401 и вы хотите разобраться в нем. Вы можете смотреть на сообщение об ошибке, которое упоминает имя файла, например:

ERROR:  could not read block 11857 of relation base/16396/3720450: read only 0 of 8192 bytes

Конференция PG Day’16 с каждым днем всё ближе, а мы продолжаем публиковать серию статей Hubert Lubaczewski об анализе explain и его основных операциях.

В этом, надеюсь, предпоследнем посте серии я расскажу об оставшихся наиболее распространенных операциях, которые вы можете встретить в выводе explain.

В мануале есть всё. Но чтобы его целиком прочитать и осознать, можно потратить годы. Поэтому один из самых эффективных методов обучения новым возможностям Postgres — это посмотреть, как делают коллеги. На конкретных примерах. Эта статья может быть интересна тем, кто хочет глубже использовать возможности postgres или рассматривает переход на эту СУБД.

Описание

В данной статье рассматривается пример настройки Active/Passive кластера для PostgreSQL с использованием Pacemaker, Corosync. В качестве дисковой подсистемы рассматривается диск от системы хранения данных (CSV). Решение напоминает Windows Failover Cluster от Microsoft.

Технические подробности:
Версия операционной системы — CentOS 7.1
Версия пакета pacemaker — 1.1.13-10
Версия пакета pcs — 0.9.143
Версия PostgreSQL — 9.4.6
В качестве серверов(2шт) — железные сервера 2*12 CPU/ 94GB memory
В качестве CSV(Cluster Shared Volume) — массив класса Mid-Range Hitachi RAID 1+0

Подготовка узлов кластера

Стек рассматриваемых технологий: Postgresql 9.3, Python 2.7 с установленным модулем «psycopg2».

Проблема

Как часто в вашей практике приходилось сталкиваться с задачей обработки таблиц большого объема (более 10 млн. записей)? Думаю вы согласитесь, что данная задача является довольно ресурсоемкой как в плане времени обработки, так и задействованных ресурсов системы. Сегодня я постараюсь показать альтернативный способ решения задачи.

Предложение:

В СУБД Postgresql есть прекрасный оператор для работы с большими объемами информации, а именно «COPY». Применение данного оператора позволяет нам читать и записывать огромные объемы информации в таблицу. В данной статье мы будем рассматривать режим чтения.

Согласно документации оператора «COPY» нам доступны несколько режимов чтения в файл либо в поток STDOUT, а также различные форматы, в том числе и «csv». Как раз его мы и постараемся использовать с максимальной пользой.

В своей работе вы используете MySQL, Postgres или Mongo, а может даже Apache Spark? Хотите знать с чего начинались эти проекты и куда они движутся сейчас? В этой статье я представлю соответствующую визуализацию