Карта темы: модели данных, теоремы CAP/PACELC, репликация, шардирование, согласованность, backup и безопасность.
Модели данных
Реляционные (SQL)
Строгая схема, ACID-транзакции, JOIN и агрегации. Индексы, MVCC, WAL. PostgreSQL часто выбирают для OLTP, когда важны SQL, транзакции и расширяемость.
Документные (NoSQL document)
Гибкая схема, денормализованные документы, горизонтальное масштабирование. MongoDB: multi-document ACID-транзакции с 4.0 (replica set) и 4.2 (sharded cluster); retryable writes — с 3.6, retryable reads — с 4.2.
PostgreSQL + JSONB + GIN-индексы позволяет хранить документы внутри реляционной базы — полезный компромисс, когда схема частично динамична.
Key-value
Максимальная скорость доступа по ключу. Redis — in-memory store: кэш, очереди (List, Stream), счётчики, сессии, rate limiting. Данные хранятся в RAM; персистентность — через RDB-снапшоты и/или AOF-лог.
Колоночные (columnar)
Данные хранятся по столбцам или семействам столбцов, что помогает с компрессией и scan-ами по большим объёмам. ClickHouse и Redshift — OLAP columnar-системы; Cassandra — wide-column, masterless, с настраиваемой согласованностью.
Подробнее о выборе между SQL и NoSQL: SQL vs NoSQL.
CAP и PACELC
Теорема CAP (Brewer, 2000): в распределённой системе при сетевой партиции (P) нельзя одновременно гарантировать Consistency (C) и Availability (A). Партиция неизбежна в реальных сетях, поэтому выбор — CP или AP.
- CP (PostgreSQL с синхронной репликацией, etcd, Zookeeper): при партиции система отказывает от доступности, но не теряет консистентность.
- AP (Cassandra, CouchDB, MongoDB с
w:1): при партиции продолжает обслуживать запросы, но допускает stale reads или конфликты.
PACELC — расширение CAP: даже без партиции существует trade-off между Latency и Consistency. Cassandra — PA/EL (высокая доступность, низкая задержка). PostgreSQL sync replication — PC/EC (строгая консистентность, выше задержка).
ACID и BASE
ACID — гарантии транзакций в реляционных БД (PostgreSQL):
| Свойство | Механизм в PostgreSQL |
|---|---|
| Atomicity | WAL: транзакция целиком или никак |
| Consistency | Constraints, foreign keys |
| Isolation | MVCC + уровни изоляции (Read Committed, Repeatable Read, Serializable) |
| Durability | WAL fsync перед ack клиенту |
BASE — модель для систем, где часть гарантий согласованности ослаблена ради доступности и latency:
- Basically Available: система стремится отвечать даже при частичных отказах.
- Soft state: состояние может меняться без входящих записей (репликация дорабатывает).
- Eventually consistent: данные сойдутся к согласованному состоянию при отсутствии новых записей.
Cassandra, MongoDB со слабыми write concerns, Redis с async replica — примеры режимов с eventual consistency. MongoDB гарантирует атомарность на уровне одного документа; multi-document ACID-транзакции доступны отдельно.
Репликация и шардирование
Репликация PostgreSQL
PostgreSQL поддерживает два типа репликации (официальная документация: High Availability):
| Physical | Logical | |
|---|---|---|
| Scope | Весь кластер (байт в байт) | Выбранные таблицы |
| Cross-version | Нет | Да |
| DDL | Реплицируется автоматически | Вручную |
| Standby | Read-only | RW |
| Use case | HA, read scaling | CDC, миграция версий |
Streaming replication: primary пишет WAL, standby получает и применяет. synchronous_commit задаёт, ждать ли локальный flush, remote write/flush или remote apply. Без synchronous_standby_names remote-режимы не ждут standby. При sync replication RPO зависит от выбранного quorum и отказов; если требуемых sync standby нет, commits будут ждать. Для нескольких standby используют кворум: synchronous_standby_names = 'ANY 2 (s1,s2,s3)'.
Детали: PostgreSQL replication и failover.
Репликация MongoDB
MongoDB Replica Set: Primary (RW) + Secondary (репликация через Oplog — capped collection) + опционально Arbiter (только голос, без данных). Election по Raft-подобному протоколу, большинство голосов (majority); electionTimeoutMillis = 10000 по умолчанию. Максимум 50 узлов в replica set, из них до 7 голосующих.
Write concern: w: 1 — подтверждение только от primary (риск rollback при failover); w: "majority" — подтверждение большинством; j: true добавляет ожидание журнала у подтверждающих узлов. Read preference: primary (свежие данные), secondary (возможен replication lag), nearest (минимальная задержка).
Детали: MongoDB репликация и согласованность.
Шардирование
Шардирование оправдано, когда один узел упирается в write throughput, объём данных или операционные окна. До него обычно проверяют индексы, партиционирование таблиц, read replicas и кэширование.
| Стратегия | Плюс | Минус |
|---|---|---|
| Range | Простота, эффективные range-запросы | Hotspots при неравномерном распределении |
| Hash | Равномерное распределение | Нет range-запросов, дорогой resharding |
| Directory | Гибкость маппинга | SPOF справочника |
PostgreSQL: нативное партиционирование (с версии 10), Citus для distributed. MongoDB: встроенный sharding через mongos + config servers. Cross-shard запросы дорогие — проектировать схему с учётом shard key.
Модели согласованности
Уровень изоляции определяет, какие аномалии допустимы внутри транзакции. В PostgreSQL:
| Уровень | Что предотвращает |
|---|---|
| Read Uncommitted | В PostgreSQL ведёт себя как Read Committed (dirty reads невозможны) |
| Read Committed (default) | Dirty reads |
| Repeatable Read | Dirty + non-repeatable reads; snapshot на всю транзакцию |
| Serializable (SSI) | Все аномалии; overhead ~5–10% |
В распределённых системах — дополнительные модели:
- Linearizability (MongoDB
readConcern: linearizable): строжайшая, каждая операция атомарна в глобальном порядке. - Causal consistency: чтение видит все записи, причинно предшествующие ему.
- Eventual consistency: данные сойдутся, но в любой момент могут быть stale.
HA и автофейловер: Patroni
Patroni автоматизирует HA PostgreSQL через DCS. Поддерживаемые DCS: etcd (рекомендован, в т.ч. v3 API), Consul, ZooKeeper, Kubernetes API, Exhibitor. Механизм: leader key в DCS с TTL; при истечении — election, winner промоутируется в primary. DCS outage → primary демотирует себя (безопасный сценарий).
Ключевые инструменты:
patronictl list # статус кластера
patronictl switchover # плановое переключение
patronictl failover # аварийное переключение
patronictl reinit # пересоздать репликуpg_rewind позволяет бывшему primary стать репликой без полного копирования данных. Требует либо wal_log_hints = on, либо включённых data checksums (initdb --data-checksums); также full_page_writes = on. Watchdog (/dev/watchdog) — hard fencing при зависании процесса Patroni.
Детали: Patroni HA PostgreSQL.
Backup и восстановление
Репликация ≠ backup: DROP TABLE реплицируется мгновенно на все standbys.
| Метод | PITR | Применение |
|---|---|---|
pg_dump | Нет | Миграции версий, selective restore |
pg_basebackup | С WAL archive | Base для PITR, инициализация реплики |
| WAL-G / Barman | Да | Production |
PITR (Point-in-Time Recovery): base backup + непрерывный WAL archive → восстановление на любой момент. Цели восстановления: recovery_target_time, recovery_target_name (именованная точка через pg_create_restore_point()), recovery_target_lsn, recovery_target_xid, recovery_target = 'immediate'.
RPO для PITR зависит от частоты и надёжности доставки WAL в архив; для async standby — от replication lag. Sync replication может дать RPO около 0 только в пределах выбранного quorum и при корректном failover. RTO = время восстановления base backup + replay WAL.
Backup нужно регулярно проверять восстановлением: без restore drill неизвестны фактические RTO/RPO.
MongoDB backup: mongodump / mongorestore (логический), снапшоты файловой системы с db.fsyncLock(), MongoDB Atlas Backup (continuous). Oplog-based PITR доступен в MongoDB Atlas и при самостоятельной настройке oplog tailing.
Шифрование at-rest
PostgreSQL: шифрование на уровне файловой системы (LUKS, dm-crypt) или облачного провайдера (AWS EBS encryption, GCP CMEK). Встроенного TDE (Transparent Data Encryption) в vanilla PostgreSQL по-прежнему нет; open-source pg_tde от Percona (GA 1.0 в 2025, WAL-шифрование в 2.0) требует Percona Server for PostgreSQL, коммерческий вариант — EDB TDE. Шифрование соединений — TLS (ssl = on, ssl_cert_file, ssl_key_file).
MongoDB: встроенное шифрование at-rest через WiredTiger Encrypted Storage Engine (доступно в MongoDB Enterprise и Atlas). Community-редакция — шифрование на уровне ОС/диска. TLS между узлами replica set — обязателен в production.
Redis: нет встроенного шифрования at-rest. Решение — LUKS/dm-crypt на уровне ОС, либо Redis Enterprise. TLS поддерживается с Redis 6 (tls-port, tls-cert-file).
Итог и карта тем
Базы данных
├── Модели: SQL → PostgreSQL, NoSQL → MongoDB, Key-value → Redis, Columnar → Cassandra/ClickHouse
├── Теоремы: CAP (CP vs AP) → PACELC (latency vs consistency)
├── Гарантии: ACID (SQL) ↔ BASE (AP NoSQL)
├── Репликация: physical/logical (PG), oplog (Mongo), async replication (Redis)
├── HA: Patroni + etcd для PG; Replica Set election для Mongo; Sentinel/Cluster для Redis
├── Шардирование: range / hash / directory — последнее средство
├── Backup: pg_dump < pg_basebackup < WAL-G+PITR; репликация ≠ backup
└── Безопасность: TLS everywhere + шифрование at-rest (ОС-уровень или нативное)Детальные заметки по темам:
- SQL vs NoSQL: инженерный выбор
- PostgreSQL репликация и failover
- Patroni HA для PostgreSQL
- MongoDB репликация и согласованность
Официальные источники:
- PostgreSQL Documentation — High Availability: https://www.postgresql.org/docs/current/high-availability.html
- PostgreSQL Documentation — WAL: https://www.postgresql.org/docs/current/wal-intro.html
- MongoDB Manual — Replication: https://www.mongodb.com/docs/manual/replication/
- MongoDB Manual — Write Concern: https://www.mongodb.com/docs/manual/reference/write-concern/