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

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

Отношения (relations)

Если заглянуть внутрь таблиц и индексов, то окажется, что они устроены схожим образом. И то, и другое — объекты базы, которые содержат некоторые данные, состоящие из строк.

То, что таблица состоит из строк, не вызывает сомнений; для индекса это менее очевидно. Тем не менее, представьте B-дерево: оно состоит из узлов, которые содержат индексированные значения и ссылки на другие узлы или на табличные строки. Вот эти узлы и можно считать индексными строками — фактически, так оно и есть.

На самом деле есть еще некоторое количество объектов, устроенных похожим образом: последовательности (по сути однострочные таблицы), материализованные представления (по сути таблицы, помнящие запрос). А еще есть обычные представления, которые сами по себе не хранят данные, но во всех остальных смыслах похожи на таблицы.

Все эти объекты в PostgreSQL называются общим словом отношение (по-английски relation). Слово крайне неудачное, потому что это термин из реляционной теории. Можно провести параллель между отношением и таблицей (представлением), но уж никак не между отношением и индексом. Но так уж сложилось: дают о себе знать академические корни PostgreSQL. Мне думается, что сначала так называли именно таблицы и представления, а остальное наросло со временем.

Привет, Хабр! Этой статьей я начинаю серию циклов (или цикл серий? в общем, задумка грандиозная) о внутреннем устройстве PostgreSQL.

Материал будет основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov. Смотреть видео не все любят (я точно не люблю), а читать слайды, пусть даже с комментариями, — совсем «не то».

Конечно, статьи не будут повторять содержание курсов один в один. Я буду говорить только о том, как все устроено, опуская собственно администрирование, зато постараюсь делать это более подробно и обстоятельно. И я верю в то, что такие знания полезны прикладному разработчику не меньше, чем администратору.

Ориентироваться я буду на тех, кто уже имеет определенный опыт использования PostgreSQL и хотя бы в общих чертах представляет себе, что к чему. Для совсем новичков текст будет тяжеловат. Например, я ни слова не скажу о том, как установить PostgreSQL и запустить psql.

Вещи, о которых пойдет речь, не сильно меняются от версии к версии, но использовать я буду текущий, 11-й «ванильный» PostgreSQL.

Первый цикл посвящен вопросам, связанным с изоляцией и многоверсионностью, и план его таков:

1. Изоляция, как ее понимают стандарт и PostgreSQL (эта статья);
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Ну, поехали.

Мы продолжаем публиковать видео и расшифровки лучших докладов с конференции PGConf.Russia 2019. В первой части доклада Ивана Фролкова речь шла о непоследовательном именовании, о constraints, о том, где лучше сосредоточить логику — в базе или в приложении. В этой части вас ждет разбор обработки ошибок, конкурентного доступа, неотменяемых операций, CTE и JSON.



Расскажу такую историю. Наш клиент говорит: «Медленно работает база, а наше приложение занимается обслуживаем населения. Мы боимся, что нас тут поднимут на вилы». Выяснилось, что у них было очень много процессов в состоянии idle in transaction. Приложение начало транзакцию, ничего не делает, но и транзакцию не завершает. Если вы взаимодействуете с какими-то внешними сервисами, то, в принципе, это нормальная ситуация. Другое дело, что если у вас состояние idle in transaction длится долго (больше минуты уже подозрительно), то это плохо потому, что PostgreSQL очень не любит долгие транзакции: VACUUM не сможет почистить все те строки, которые он мог бы увидеть, и долго висящая транзакция эффективно блокирует VACUUM. Начинают разбухать таблицы, индексы становятся всё менее эффективными.

Чуть более месяца назад в Москве состоялась крупнейшая конференция постгресового сообщества PGConf.Russia 2019, собравшая в МГУ свыше 700 человек. Мы решили выложить видео и расшифровку лучших докладов. Выступление Ивана Фролкова с разбором типичных ошибок при работе с PostgreSQL было отмечено лучшим на конференции, поэтому мы начнем с него.

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



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

Главный вывод, который я смог сделать из того, что я видел, довольно неожиданный: фактически любое приложение при должной настойчивости можно заставить работать. Был замечательный проект (я не могу упоминать все компании, с которыми мы работали), в котором еще более замечательное приложение создавало таблицы миллионами. Выглядело это так: в понедельник система работает неплохо, а уже в пятницу она практически не работает. На выходные дни запускают VACUUM FULL, и в понедельник она опять работает хорошо. Оказывается, над PostgreSQL можно вот так издеваться, и всё это довольно долго будет жить и работать. Другой товарищ сделал странную вещь: у него всё было построено на триггерах, процедур не было вообще. То есть большую часть таблиц трогать нельзя, сделать что-либо не получалось, но и эта база жила.

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

Новости

Microsoft приобрела Citus Data

Безусловно, главная новость в мире PostgreSQL. Об этом есть сообщение на сайте Citus, равно как и на сайте MS.

Postgres Pro Enterprise Certified

СУБД Postgres Pro Enterprise получила сертификат ФСТЭК, и теперь в наборе Postgres Pro есть и «Сертифицированная версия Postgres Pro Enterprise». До этого сертификат, необходимый для работы с персональными данными, имела только Postgres Pro Standard («Сертифицированная версия Postgres Pro»). Подробности на сайте.

credativ: PostgreSQL Competence Center

Германская фирма credativ, до того известная в Европе и Азии, приобрела фирму OmniTI, чтобы выйти на американский рынок. credativ специализируется на развертывании и поддержке проектов open source. Теперь в США откроется PostgreSQL Competence Center, который будет заниматься высококритичными проектами и поддерживать БД в течение всего их жизненного цикла.

Предлагаем вашему вниманию перевод статьи Джозефа Хеллерштейна «Looking Back at Postgres», опубликованной в соответствии с международной лицензией Creative Commons «С указанием авторства» версии 4.0 (CC-BY 4.0). Авторы оставляют за собой право распространять эту работу на личных и корпоративных веб-сайтах с надлежащей ссылкой на источник.

Перевод выполнен Еленой Индрупской. От себя добавлю, что «программист, который отчаянно хотел построить систему с многоверсионностью» — судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.

Аннотация

Это воспоминание о проекте Postgres, выполняемом в Калифорнийском университете в Беркли и возглавляемом Майком Стоунбрейкером (Mike Stonebraker) с середины 1980-х до середины 1990-х годов. В качестве одного из многих личных и исторических воспоминаний, эта статья была запрошена для книги [Bro19], посвященной награждению Стоунбрейкера премией Тьюринга. Поэтому в центре внимания статьи — руководящая роль Стоунбрейкера и его мысли о дизайне. Но Стоунбрейкер никогда не был программистом и не мешал своей команде разработчиков. Кодовая база Postgres была работой команды блестящих студентов и эпизодически—штатных университетских программистов, которые имели немного больше опыта (и только немного большую зарплату), чем студенты. Мне посчастливилось присоединиться к этой команде в качестве студента в последние годы проекта. Я получил полезный материал для этой статьи от некоторых более старших студентов, занятых в проекте, но любые ошибки или упущения являются моими. Если вы заметили какие-либо из них, пожалуйста, свяжитесь со мной, и я постараюсь их исправить.

PGConf.Russia 2019 не за горами — 4 февраля мастер-классы, 5-6го — доклады. В этом году, как и в прошлом, конференция проводится на экономическом факультете МГУ. Активность докладчиков в период сбора докладов была заметно выше, чем в прошлые годы, так что программа будет интересной. Даже молчаливые 1С-ники подтянулись: первый раз (вместе с Инфостартом) удалось собрать целую секцию на тему «Postgres для 1С». Итак, что нас ждёт?

Мы продолжаем знакомить вас с самыми интересными новостями по PostgreSQL. В этом предновогоднем выпуске не будем утомлять вас длинным перечнем новостей. С Наступающим Новым Годом!

Релизы

pgAdmin4 3.6

В этой версии добавлены:

• из панели Properties можно дропать несколько объектов одновременно;
• можно импортировать из и экспортировать в определения серверов из базы и в базу данных конфигураций.

pgpoolAdmin 4.0.2

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

dbForge Studio for PostgreSQL v2.0

На этот раз devart выпустила Studio со Standard edition, в которой есть функциональность, не включенная в бесплатную версию Express. 30 дней можно пользоваться Standard edition бесплатно. О различиях Standard и Express можно почитать здесь.

VOPS-2.0

Вышла новая версия расширения PostgreSQL от Postgres Professional для эффективного исполнения векторных операций.

pg_probackup 2.0.25

Новая версия утилиты для бэкапа и восстановления, тоже от Postgres Professional

pgCluu 2.9

Новую версию этой программы на Perl для аудита производительности кластеров с PostgreSQL можно скачать здесь. pgCluu собирает статистику работы не только СУБД, но и системные ресурсы кластера.

postgres_dba 4.0

Вышла новая версия утилиты Николая Самохвалова для администрирования PostgreSQL. В ней появились три новых отчета: список расширений, настройка параметров PostgreSQL и Вакуум: что происходит прямо сейчас. И, конечно, доработки и исправления.

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

Релизы

PostgreSQL 11.1
Вместе с этой версией вышли также 10.6, 9.6.11, 9.5.15, 9.4.20 и 9.3.25 (это последний релиз 9.3). В этой версии есть изменения, связанные с безопасностью. Исправили выявленные ошибки. Прочитать о релизах можно здесь, а скачать здесь.


Postgres Pro Standard 11.1.1, 10.6.1, 9.6.11.1, 9.5.15.1, Postgres Pro Enterprise 10.6.1, 9.6.11.1

Эти релизы основаны на соответствующих ванильных версиях PostgreSQL и на предыдущих версиях Standard и Enterprise. В разделе «Замечания к выпуску» в соответствующей версии документации можно прочитать об отличиях от предыдущей версии семейства. Например, в Enterprise 10.6.1 и 9.6.11.1 добавлена поддержка операционной системы Astra Linux «Смоленск» 1.6 и улучшена стабильность автономных транзакций.

pgAdmin 4 version 3.5.

В этом релизе не только исправлены баги (11 штук), но и добавлены новые возможности. Среди них:

• Миграция с Bootstrap 3 на Bootstrap 4
• Можно останавливать сервисные процессы (Backup/Restore/Maintenance...)

Бинарники для Windows и macOS, а также для Python Wheel, Docker-контейнеры и тарболы с исходниками можно скачать отсюда. RPMы и DEBы должны появиться в репозиториях postgresql.org в ближайшие дни.

TimescaleDB 1.0

В анонсе говорится, что это версия годится для использования в промышленном режиме. Эта СУБД, ориентированная на работу с временнЫми рядами, выполнена как расширение для PostgreSQL. Можно запускать разные версии TimescaleDB с одним и тем же экземпляром PostgreSQL Ядро команды разработчиков — выпускники Принстонского Университета.

Спешу поделиться хорошей новостью: жизнь авторов статей про PostgreSQL и их читателей стала немного лучше.

Как знают все хаброписатели, для оформления исходного кода используется специальный тег <source>, который подсвечивает синтаксис. Не секрет также, что подсветка не всегда получается идеальной, и тогда авторы (которым не все равно, как выглядят их статьи) вынуждены заниматься самодеятельностью — расцвечивать свой код с помощью <font color=...>.

Особенно печально все было с PostgreSQL, поскольку подсветка охватывала более или менее стандартный SQL и категорически не понимала специфики нашей СУБД. Шло время, Алексей boomburum старательно исправлял мои font-ы на source (а я — обратно), пока не стало очевидно, что подсветку надо чинить. Наконец Далер daleraliyorov подсказал выход: добавить поддержку PostgreSQL в библиотеку highlightjs, которой пользуется Хабр. И вот — готово, встречайте.