← Back to notes

Базы данных для DevOps:
модели, репликация, согласованность

2026-04-26

#sql#nosql#replication#consistency#cap

Карта темы: модели данных, теоремы 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):

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):

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 и кэширование.

PostgreSQL: нативное партиционирование (с версии 10), Citus для distributed. MongoDB: встроенный sharding через mongos + config servers. Cross-shard запросы дорогие — проектировать схему с учётом shard key.

Модели согласованности

Уровень изоляции определяет, какие аномалии допустимы внутри транзакции. В PostgreSQL:

В распределённых системах — дополнительные модели:

  • 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 (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) в open-source PostgreSQL нет; коммерческий pg_tde от Percona и EDB добавляют его. Шифрование соединений — 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 (ОС-уровень или нативное)

Детальные заметки по темам:

Официальные источники:

  • 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/
Базы данных для DevOps: модели, репликация, согласованность | Aleksandr Suprun