"Хочешь ускорить запросы, построй индекс" – классический первый шаг по увеличению производительности в PostgreSQL. Вот только на практике можно встретить ситуацию, когда индексы в PostgreSQL есть, но тормоза никуда не делись. Не все индексы являются эффективными. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных. Давайте поговорим о пенальти на производительность, которое дает расположение данных: почему это происходит и как это можно предотвратить.
User
Хорошие новости для тех, кто всё ещё использует row-level локи в PostgreSQL
Для организации совместного доступа к данным в PostgreSQL программисты часто использую row-level локи. В статье поговорим об оверхеде, который получается от такого подхода и какие есть альтернативы. Давайте посмотрим, как можно поторопить слона!
Интеграция PostgreSQL с другими СУБД: делаем запросы в MySQL
Нередко бывает так, что в большом проекте в силу тех или иных причин — зачастую исторических, хотя бывает по-всякому — его части могут использовать различные СУБД для хранения и поиска критически важных данных. В числе прочего, этому разнообразию способствует конкуренция и развитие технологий, но, так или иначе, взаимодействие между СУБД описывает стандарт 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 и эффективно выполнять получающиеся запросы.
PostgreSQL: Случай в вакууме
Один из наших клиентов, эксплуатирующий PostgreSQL под большой нагрузкой, столкнулся с проблемой, связанной с переполнением счетчика транзакций (xid wraparound), причем выхода из нее штатными средствами не существовало. Мы решили проблему с помощью хирургического вмешательства и выпустили патч, предотвращающий возникновение таких ситуаций в будущем.
В этой заметке мы расскажем, как и почему может произойти проблема и как ее не допустить.
PostgreSQL в Azure. Часть 1
Этой статьей мы начинаем цикл заметок об использовании PostgreSQL в Microsoft Azure.
Первая статья будет об установке и настройке кластера PostgreSQL:
- Знакомство с ресурсами Azure
- Управление через azure cli
- Выбор подходящего хранилища
- Сборка классической связки ведущий-ведомый в одной группе доступности
Восстановление данных PostgreSQL после потери pg_control
Для обеспечения отказоустойчивости СУБД 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
...