В предыдущей статье мой коллега Дмитрий Васильев описал настройку интеграции PostgreSQL с MySQL и описал, как более эффективно выполнять некоторые запросы.

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

Нередко бывает так, что в большом проекте в силу тех или иных причин — зачастую исторических, хотя бывает по-всякому — его части могут использовать различные СУБД для хранения и поиска критически важных данных. В числе прочего, этому разнообразию способствует конкуренция и развитие технологий, но, так или иначе, взаимодействие между СУБД описывает стандарт SQL/MED 2003 (Management of External Data), который вводит определение Foreign Data Wrappers (FDW) и Datalink.

Первая часть стандарта предлагает средства для чтения данных как набора реляционных таблиц под управлением одного или нескольких внешних источников; FDW также может представлять возможность использовать SQL-интерфейс для доступа к не SQL данным, таким, как файлы или, например, список писем в почтовом ящике. Вторая часть, Datalink, позволяет управлять удаленным SQL-сервером.

Эти две части были реализованы еще в PostgreSQL 9.1 и называются FDW и dblink соответственно. FDW в PostgreSQL сделан максимально гибко, что позволяет разрабатывать wrapper'ы для большого количества внешних источников. В настоящее время мне известны такие FDW, как PostgreSQL, Oracle, SQL Server, MySQL, Cassandra, Redis, RethinkDB, Ldap, а также FDW к файлам типа CSV, JSON, XML и т.п.

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

Свершилось!

Расширение pg_variables

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

Решение обычно выглядит вполне прямолинейным — сначала получаем список, скажем, пользователей, потом для них строим требуемый результирующий набор; потом опять получаем список пользователей и строим второй набор; и все бы хорошо, если бы построение такого списка не оказывалось бы достаточно затратной операцией — и, таким образом, если на основании этого списка надо построить несколько результатов, то получается, что этот список надо получить несколько раз со всеми сопутствующими накладными расходами. Очевидным решением этой проблемы кажутся временные таблицы, и это действительно так; к сожалению, с ними связан ряд не самых приятных особенностей — для каждой временной таблицы требуется создавать файл (а при уничтожении таблицы — удалять его). Кроме того, эти таблицы, разумеется, не видны для процессов автовакуума и, следовательно, не очищаются автоматически, и по ним не собирается статистика. Что еще хуже, при наличии длительных активных транзакций может происходить неограниченный рост системного каталога; более того, кеш операционной системы заполняется данными о созданных файлах для временных таблиц, что ведет к общей деградации производительности.

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

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

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

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

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

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

Для обеспечения отказоустойчивости СУБД 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
...

select * from $1 where ...;

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

Привет всем!

Всем привет!

• Масштабируемость, производительность, безопасность PostgreSQL.
• Разработка ядра PostgreSQL. Внутреннее устройство. Текущие и будущие проекты.
• Живой опыт практического использования PostgreSQL в России и за рубежом. Внедрение, миграция, разработка приложений. Доклады «с полей».
• Кластер. Отказоустойчивые и масштабируемые системы на базе PostgreSQL
• PostgreSQL в России. Российское сообщество. Образование. PostgreSQL в задачах импортозамещения и достижения технологической независимости.

Аннотация

Введение