Архитектура PostgreSQL
Тема дорожной карты · PostgreSQL
PostgreSQL — реляционная СУБД с открытым исходным кодом, основанная на процессной модели: каждое клиентское соединение обслуживается выделенным серверным процессом, порождённым центральным процессом postmaster, что обеспечивает изоляцию сеансов и повышает отказоустойчивость. Область разделяемой памяти — буферный кэш, или shared_buffers, — хранит часто используемые страницы данных, чтобы SQL-запросы могли обслуживаться без обращения к диску при каждом запросе; журнал упреждающей записи (WAL) фиксирует каждое изменение до его применения к файлам данных, гарантируя долговечность и обеспечивая восстановление на момент времени. Механизм хранения PostgreSQL организует данные в 8-килобайтных страницах кучи и использует многоверсионное управление параллельным доступом (MVCC), позволяющее читателям и записывающим потокам работать без взаимной блокировки — архитектурное решение, лежащее в основе транзакционных гарантий PostgreSQL. Фоновые рабочие процессы — запускатель autovacuum, контрольная точка и WAL-писатель — работают непрерывно, поддерживая работоспособность и производительность базы данных. Понимание архитектуры PostgreSQL помогает инженерам настраивать параметры конфигурации, диагностировать узкие места и проектировать надёжно масштабируемые системы.
Как это работает
Архитектура PostgreSQL начинается с понимания PostgreSQL как закалённой в бою open-source RDBMS со строгим следованием SQL-стандартам, MVCC-конкурентностью, ACID-транзакциями и богатой типизацией (массивы, JSONB, ranges, геометрические типы, пользовательские через расширения). Кластер Postgres — один работающий postmaster + per-connection backend-процессы; БД живут внутри одного кластера; схемы внутри БД; таблицы, view, sequences внутри схем. Wire-протокол стабилен и задокументирован.
Когда применять
PostgreSQL — дефолтная реляционная БД для любого нового проекта: JSON + реляционка + full-text + расширения в одном движке, MIT-подобная лицензия, без vendor lock-in. MySQL — только если унаследовали деплой. SQLite — когда реально single-host + низкая конкурентность. Managed Postgres (Yandex Managed PostgreSQL, RDS, Cloud SQL) — когда бекапы + HA + мониторинг начинают есть инженерное время.
Типичные ошибки
Ловушки Архитектура PostgreSQL: расчёт, что Postgres "сам масштабируется" без тюнинга (shared_buffers, work_mem, max_connections дефолты крошечные); MySQL-измы (LIMIT m, n нестандартен — используйте LIMIT n OFFSET m); пустой template1-extensions (CREATE EXTENSION per-DB); не выучили EXPLAIN (ответ на большинство "почему медленно" — в плане). Прочтите официальный туториал от и до.