Fossil/knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
knowledge-base/DATABASES.md
Stanislav Hubacek ef3c2f75b1 18.6.2026
2026-06-18 16:25:33 +02:00

16 KiB
Raw Permalink Blame History

🗄️ Databázová architektura

Klasifikace databází

Relační (SQL)

DB Licence Use case Detail
PostgreSQL Open source Univerzální, geospatial, analytika, AI POSTGRESQL.md
MySQL / MariaDB Open source Web, LAMP stack, e-commerce MYSQL.md
Microsoft SQL Server Proprietary Enterprise .NET, Windows ekosystém —
Oracle DB Proprietary Enterprise, finance, mainframe, RAC cluster ORACLE.md
Amazon Aurora Managed MySQL/PostgreSQL kompatibilní, cloud-native —

NoSQL

Typ DB Use case Detail
Document MongoDB, Couchbase JSON data, flexibilní schema MONGODB.md
Key-Value / Cache Redis, Memcached, DynamoDB Cache, session store, real-time REDIS.md
Wide-column Cassandra, ScyllaDB Time-series, IoT, velká data CASSANDRA.md
Vector Pinecone, Qdrant, Milvus, pgvector Embeddingy, RAG, sémantické vyhledávání VEKTOROVE-DB.md
Graph Neo4j, Dgraph Vztahy, doporučení, social grafy —

Storage enginy

Společné koncepty napříč databázemi: DATABAZOVE-ENGINY.md

Transaction isolation levels

Úroveň Dirty Read Non-repeatable Read Phantom Read Serialization Anomaly
Read Uncommitted Ano (možné) Ano Ano Ano
Read Committed Ne (prevence) Ano Ano Ano
Repeatable Read Ne Ne Ne (PostgreSQL: Ne) Ano
Serializable Ne Ne Ne Ne

Anomálie:

  • Dirty Read — čtení dat z necommitnuté transakce (data mohou být rollbacknuta)
  • Non-repeatable Read — stejný dotaz vrátí jiná data (jiná transakce mezitím updatovala řádek)
  • Phantom Read — stejný dotaz vrátí nové řádky (jiná transakce insertla data splňující podmínku)
  • Serialization Anomaly — výsledek transakcí není ekvivalentní žádnému sériovému pořadí

PostgreSQL vs MySQL rozdíly

  • PostgreSQL: Read Uncommitted se chová jako Read Committed. Repeatable Read = Snapshot Isolation (zabraňuje i phantom reads). Serializable = SSI.
  • MySQL InnoDB: Repeatable Read používá next-key locking (zabrání phantom reads).

CAP teorém

V distribuovaném systému lze mít pouze 2 ze 3: Consistency, Availability, Partition tolerance.

V praxi: P je vždy vyžadováno, volíme mezi CP (konzistence) a AP (dostupnost).

PACELC rozšíření

PACELC rozšiřuje CAP o chování za normálních podmínek (bez partition):

  • Partition → Availability vs Consistency
  • Else (bez partition) → Latency vs Consistency
DB Partition volba Else volba
Cassandra AP (dostupnost) LC (nízká latence, eventual consistency)
DynamoDB (default) AP LC
MongoDB CP (primární) LC
PostgreSQL (single) CP CC
CockroachDB CP CC

Quorum detail

  • R (read quorum) + W (write quorum) > N (replication factor)
  • Typické: N=3, R=2, W=2 (toleruje 1 node down)
  • Sloppy quorum — při nedostupnosti nodu, data dočasně uložena na jiném nodu
  • Hinted handoff — dočasný zápis na jiný node s hintem, při obnově se data přenesou

Replikace

Typ Popis Latence
Synchronní Zápis potvrzen až po replikaci na všechny nod Vysoká, ale konzistentní
Asynchronní Zápis potvrzen ihned, replikace na pozadí Nízká, možný data loss
Semi-synchronní Potvrzení od majority nodů Kompromis

Topologie

  • Leader-Follower (Master-Slave) — čtení z replic
  • Leader-Leader (Multi-master) — zápis na více nodů
  • Quorum-based — R + W > N (Cassandra, DynamoDB)

Sharding

Distribuce dat napříč uzly podle shard klíče.

                     ┌─────────┐
                     │  Proxy  │
                     │  Router │
                     └────┬────┘
               ┌──────────┼──────────┐
          ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
          │Shard A │ │Shard B │ │Shard C │
          │ 0-100  │ │101-200 │ │201-300 │
          └────────┘ └────────┘ └────────┘

Metody

Metoda Popis Výhoda Nevýhoda
Hash-based shard_id = hash(key) % N Rovnoměrná distribuce Ztráta range dotazů
Range-based Data dle rozsahu (A-M, N-Z) Zachovává řazení Hot spots
Consistent hashing Hash ring, vnodes Min. přeuspořádání při změně počtu shardů Složitější

Routing

  • Proxy-based — aplikace jde na proxy, ta routuje (Vitess, ProxySQL, mongos)
  • Client-side — aplikace ví, na který shard jít
  • DNS-based — každý shard má vlastní endpoint

Data consistency patterns

Pattern Popis Příklad
Strong consistency Po zápisu každý read vidí nejnovější data Single DB, Raft, Spanner
Eventual consistency Po zápisu se data časem propagují DNS, DynamoDB (default), Cassandra
Read-after-write Autor svůj zápis vždy vidí (ostatní eventual) Sociální sítě, komentáře
Causal consistency Kauzálně závislé operace viděny ve správném pořadí COPS, Orbe, MongoDB (causal clusters)
Monotonic reads Nevidíte starší data po tom, co jste viděli novější Cassandra (MONOTONIC_READ consistency)
Monotonic writes Zápisy od jednoho clienta v pořadí Queue-based, single leader

Migrace dat

Schema migrace

V1__initial_schema.sql
V2__add_users_table.sql
V3__add_email_index.sql
V4__add_orders_table.sql

Zero-downtime migrace

  1. Expand — přidání nového sloupce/tabulky (aplikace toleruje oba stavy)
  2. Migrate — backfill dat, update aplikace na nové schema
  3. Contract — odstranění starého sloupce/tabulky

Nástroje

Nástroj Jazyk Strategie Zero-downtime Rollback
Flyway Java (multi-lang CLI) Versioned SQL Omezeně (jen additive) undo (limited, enterprise)
Liquibase Java (multi-lang CLI) Changesets (XML/YAML/JSON/SQL) Ano (changeset design) rollback <count>
Alembic Python Auto-generation, versioned Ano (branching) downgrade
Prisma Migrate TypeScript Declarative schema → diff Ano (shadow DB) migrate diff
gh-ost Go Triggerless online DDL (MySQL) Ano (binlog stream) Ne (progresivní)
pgroll Go Online schema migrace (PG) Ano (views, multiple versions) Ano (okamžitý)

SQL Antipatterns

Na základě More SQL Antipatterns (Karwin, 2026) — 14 nových antipatternů:

Language antipatterns

Antipattern Problém Řešení
Fear of JOINs Manuální párování v aplikaci místo JOIN Používat JOIN správně
Relational Division Hledání množin v WHERE Relační dělení (subquery s GROUP BY/HAVING)
Pagination via OFFSET OFFSET je O(n) — čím větší offset, tím pomalejší Keyset pagination (WHERE id > last_seen)
Non-Sargable queries Funkce na sloupci v WHERE (WHERE YEAR(date) = 2026) Přepsat na range podmínku

Optimization antipatterns

Antipattern Problém Řešení
Premature denormalization Denormalizace bez důvodu Měřit, pak optimalizovat
JSON overuse JSON jako univerzální řešení Použít JSON jen pro skutečně flexibilní data
Cacheless transactions Spoléhání na query cache (v MySQL 8 odstraněna) Application-level caching

Application antipatterns

Antipattern Problém Řešení
Polling Pravidelné dotazování na změny LISTEN/NOTIFY, Kafka, Change Data Capture
Transaction encapsulation Každý model si spravuje vlastní transakci Unit of Work pattern
Fear of deadlocks Snaha o prevenci všech deadlocků Mitigace, ne prevence
Data hoarding Ukládání všeho navždy Data retention politiky, archívace

Mini-antipatterny

  • LIMIT bez ORDER BY — nedeterministické výsledky
  • NATURAL JOIN — křehký, implicitní join condition
  • N+1 queries — dotaz v cyklu místo JOIN/batch
  • Redundantní indexy — duplicitní/překrývající se indexy zbytečně zpomalují zápisy

Designing Data-Intensive Applications (2. vydání)

Kleppmann, Riccomini (2026) — zásadně přepracované vydání.

Novinky oproti 1. vydání

Oblast Co je nové
Cloud-native Storage = object store (S3, Blob), nikoliv lokální disk. Separace control/data/compute plane
AI workloads Vektorové indexy, DataFrames jako datový model, batch processing pro training data
Local-first software DuckDB, PGlite, SQLite — databáze běžící na laptopu/edge, sync při připojení
Formal methods Randomizované testování, formální verifikace (důležité pro AI-generovaný kód)
Legal & ethics GDPR, etika prediktivní analytiky, bias, accountability algoritmů
Streaming → SQL views Materialize, incremental view maintenance — streamování jako SQL

Klíčové principy (nemění se)

Spolehlivost (Reliability), škálovatelnost (Scalability), udržovatelnost (Maintainability) — tři pilíře dobrých datových systémů.

Apache Iceberg Lakehouse

Na základě Architecting an Apache Iceberg Lakehouse (Merced, 2026):

Co je data lakehouse

Architektura kombinující flexibilitu a nízkou cenu data lake (object storage) s výkonem a governance data warehouse. Apache Iceberg je open source table format.

Iceberg metadata architektura

Table metadata (.metadata.json)
    └── Snapshot manifest list
            └── Manifests (file-level stats)
                    └── Data files (Parquet/ORC/Avro)

Klíčové vlastnosti

Vlastnost Popis
ACID transakce Bezpečné concurrent read/write
Schema evolution Přidání/odebrání/přejmenování sloupce bez rewrite
Time travel Dotazování na historické snapshoty
Partition evolution Změna partition strategie bez rewrite dat
Hidden partitioning Automatické partition filtry (uživatel nemusí uvádět)
Multi-engine Spark, Flink, Trino, Dremio, Snowflake nad stejnými daty

Detailnější přehled Big Data ekosystému (HDFS, Spark, Flink, Trino, Delta Lake, Hudi) viz BIG-DATA.md.

Kdy použít Iceberg

  • Multi-tool přístup ke stejným governed datům
  • ACID na lake datech
  • Streamování + batch v jedné tabulce
  • Snížení duplicity (jedna canonical kopie místo ETL do warehouse)

Best practices

  • Connection pooling — PgBouncer, RDS Proxy, ProxySQL
  • Indexování podle query patternů — nemít zbytečné indexy
  • Read replicas pro reporting a analytiku
  • Backup & recovery — point-in-time recovery (PITR), pravidelné testy
  • Query monitoring — slow query log, pg_stat_statements, performance_schema
  • Encryption at rest & in transit
  • Migrace v CI/CD — součást pipeline, ne manuálně
  • Volba DB podle workloadu — neexistuje jedna univerzální DB (polyglot persistence)

Srovnání licenčních modelů databází

DB Licence Cena (self-hosted) Cena (managed cloud) Vendor lock-in Poznámka
PostgreSQL PostgreSQL license (MIT-like) $0 ~$0.10-1.00/hod (RDS, CloudSQL, Aurora) Nízký Plně open source, žádná omezení
MySQL GPL v2 / Commercial (Oracle) $0 (GPL) / ~$2 000/server/rok (commercial) ~$0.10-1.00/hod (RDS, PlanetScale) Střední (Oracle vlastní) GPL = nutnost uvolnit aplikaci? (závisí na distribuci)
MariaDB GPL v2 / Business Source $0 (GPL) ~$0.10-1.00/hod (SkySQL) Nízký Plně kompatibilní fork MySQL, žádný Oracle vliv
Oracle SE2 Proprietary (per core) ~$17 500/core + 22 % support/rok ~$1-5/hod (RDS, OCI) Vysoký Core factor 0.5 (EPYC/Xeon), max 16 threads
Oracle EE Proprietary (per core + options) ~$47 500/core + options + 22 % support ~$2-30/hod (OCI, RDS) Vysoký Options zdvojnásobují cenu (RAC, partitioning, compression)
SQL Server Standard Proprietary (per core + CAL) ~$1 000/core + $200/CAL ~$0.20-1.00/hod (Azure SQL) Střední Windows Server license nutná navíc
SQL Server Enterprise Proprietary (per core + CAL) ~$7 000/core + $200/CAL ~$1-5/hod (Azure SQL) Střední AlwaysOn, partitioning, in-memory OLTP
MongoDB SSPL (Community) / Commercial (Enterprise) $0 (Community) / ~$10k/server/rok (Enterprise) ~$0.10-5.00/hod (Atlas) Střední SSPL omezuje managed cloud služby
Redis RSALv2 + SSPL (7.4+) / BSD (Valkey) $0 (Valkey) ~$0.10-1.00/hod (ElastiCache, Memorystore → Valkey) Nízký (Valkey) Redis 7.4+ změna licence → fork Valkey
Cassandra Apache 2.0 $0 ~$0.10-1.00/hod (Keyspaces, Amazon Managed) Nízký Plně open source, žádná omezení
ScyllaDB Apache 2.0 (OSS) / Enterprise $0 (OSS) / Enterprise subscription ~$0.50-3.00/hod (ScyllaDB Cloud) Nízký (OSS) Enterprise: monitoring, security, support
CockroachDB BSL (Business Source License) / Enterprise $0 (core) / Enterprise subscription ~$0.50-3.00/hod (CockroachDB Cloud) Střední BSL: po 3 letech se mění na MIT. Enterprise: multi-region, backup

Klíčová doporučení:

  • Nejnižší TCO: PostgreSQL (žádná licence, nejširší cloud podpora)
  • Nejvyšší vendor lock-in: Oracle (PL/SQL, proprietary options, drahá migrace)
  • License risk: Redis (změna licence) → používejte Valkey pro nové projekty
  • Cloud-native licensing: MongoDB Atlas, CockroachDB Cloud, ScyllaDB Cloud — pay-per-use, žádná správa licencí

Zdroje

Odkazy, knihy a standardy: sources/databases/sources.md

Doporučená literatura

Kniha Autoři ISBN Klíčový přínos
Database Internals Alex Petrov 978-1492040346 Hloubkový výklad storage engine (B-Tree, LSM-Tree, WAL, MVCC), distribuované systémy
Designing Data-Intensive Applications (2nd ed.) Kleppmann, Riccomini — Cloud-native, AI, local-first, formal methods
High Performance MySQL (4th ed.) Schwartz, Zaitsev, Tkachenko 978-1492075292 MySQL architektura, schema/index optimalizace
Expert Oracle Architecture (3rd ed.) Kyte, Kuhn 978-1484249602 Oracle architektura, RAC, Data Guard, tuning
AI-Ready PostgreSQL 18 Kumar, Linster — PostgreSQL jako unified platform pro AI
More SQL Antipatterns Bill Karwin (2026) — 14 antipatternů, keyset pagination
Vector Databases Borwankar (2026) — Embeddings, vektorové indexy, RAG
Architecting an Apache Iceberg Lakehouse Merced (2026) — Lakehouse architektura, Iceberg metadata

Poslední revize: 2026-06-03

Reference in New Issue View Git Blame Copy Permalink