First batch

2026-06-03 22:42:43 +02:00
parent c6fa0bff6a
commit 95d1839f05
31 changed files with 3527 additions and 485 deletions
--- a/DATABASES.md
+++ b/DATABASES.md
@@ -4,23 +4,29 @@

 ### Relační (SQL)

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

 ### NoSQL

-| Typ | DB | Use case |
-|-----|----|----------|
-| Document | MongoDB, Couchbase | JSON data, flexibilní schema |
-| Key-Value | Redis, DynamoDB | Cache, session store, real-time |
-| Wide-column | Cassandra, ScyllaDB | Time-series, IoT, velká data |
-| Graph | Neo4j, Dgraph | Vztahy, doporučení, social grafy |
+| Typ | DB | Use case | Detail |
+|-----|----|----------|--------|
+| **Document** | MongoDB, Couchbase | JSON data, flexibilní schema | [MONGODB.md](MONGODB.md) |
+| **Key-Value / Cache** | Redis, Memcached, DynamoDB | Cache, session store, real-time | [REDIS.md](REDIS.md) |
+| **Wide-column** | Cassandra, ScyllaDB | Time-series, IoT, velká data | [CASSANDRA.md](CASSANDRA.md) |
+| **Vector** | Pinecone, Qdrant, Milvus, pgvector | Embeddingy, RAG, sémantické vyhledávání | [VEKTOROVE-DB.md](VEKTOROVE-DB.md) |
+| **Graph** | Neo4j, Dgraph | Vztahy, doporučení, social grafy | — |
+
+### Storage enginy
+
+Společné koncepty napříč databázemi: [DATABAZOVE-ENGINY.md](DATABAZOVE-ENGINY.md)
+
+---

 ## Transaction isolation levels

@@ -28,7 +34,7 @@
 |--------|-----------|---------------------|-------------|----------------------|
 | **Read Uncommitted** | Ano (možné) | Ano | Ano | Ano |
 | **Read Committed** | Ne (prevence) | Ano | Ano | Ano |
-| **Repeatable Read** | Ne | Ne | Ano (PostgreSQL: Ne) | Ano |
+| **Repeatable Read** | Ne | Ne | Ne (PostgreSQL: Ne) | Ano |
 | **Serializable** | Ne | Ne | Ne | Ne |

 **Anomálie**:
@@ -37,196 +43,22 @@
 - **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 specific
- **Read Uncommitted** se chová jako **Read Committed** (není implementováno)
- **Repeatable Read** v PG je **Snapshot Isolation** — zabraňuje i phantom reads
- **Serializable** v PG používá Serializable Snapshot Isolation (SSI) — detekce sériových konfliktů
+### PostgreSQL vs MySQL rozdíly

-## PostgreSQL detail
+- **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).

-### MVCC (Multi-Version Concurrency Control)
-
- Každá transakce vidí snapshot dat (transaction snapshot) z okamžiku startu
- Staré verze řádků (tuple) zůstávají v tabulce, označené jako `xmax` / `xmin`
- INSERT vytvoří nový tuple s `xmin = current_xid`
- DELETE označí tuple `xmax = current_xid` (nezmizí hned)
- UPDATE = DELETE old + INSERT new
- VACUUM fyzicky maže tuple starší než nejstarší aktivní snapshot
-
-### VACUUM a autovacuum
-
-| Parametr | Popis | Výchozí |
-|----------|-------|---------|
-| `autovacuum_vacuum_threshold` | Min. mrtvých řádků pro spuštění | 50 |
-| `autovacuum_vacuum_scale_factor` | % z tabulky jako threshold | 0.2 (20 %) |
-| `autovacuum_analyze_threshold` | Min. změněných řádků pro ANALYZE | 50 |
-| `autovacuum_vacuum_cost_limit` | Limituje I/O vacuum (prevence zátěže) | 200 |
-| `autovacuum_naptime` | Interval mezi kontrolami | 1 min |
-| `deadlock_timeout` | Detekce deadlocků | 1 s |
-
-**Příznaky nedostatečného vacuum**:
- Růst tabulky (bloat) — staré tuple zabírají místo
- Zhoršení výkonu index scanů (VISIBLE MAP není aktuální)
- XID wraparound hazard — emergency vacuum (může zastavit DB)
-
-### WAL archiving a PITR
-
-```conf
-# postgresql.conf
-wal_level = replica                 # nebo logical
-archive_mode = on
-archive_command = 'aws s3 cp %p s3://backups/pg-wal/%f'
-```
-
- **WAL** (Write-Ahead Log) — append-only log všech změn
- **WAL archiving** — kontinuální záloha WAL segmentů (16 MB)
- **PITR** (Point-In-Time Recovery) — obnova k libovolnému okamžiku
-  1. Restore base backup (pg_basebackup)
-  2. Replay WAL archivů až k cílovému času
-  3. `recovery_target_time = '2026-06-03 10:30:00 UTC'`
-
-### Replication slots
-
- **Physical replication slot** — zaručuje, že WAL není smazán masterem, dokud ho replica nespotřebuje
- **Logical replication slot** — pro logickou replikaci (selectivní tabulky, transformace dat)
- **Riziko**: pokud replica spadne a slot není aktivní, WAL naroste na disku (disk full)
- Monitoring: `pg_replication_slots`, `pg_stat_replication`
-
-## 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)
-
-## Index types
-
-| Typ | Algoritmus | Use case | Operace | Poznámka |
-|-----|-----------|----------|---------|----------|
-| **B-tree** | Balanced tree | Většina dotazů — =, <, >, BETWEEN, IN, LIKE (prefix) | Rychlé vyhledávání, řazení | Výchozí v PostgreSQL, MySQL |
-| **Hash** | Hash table | Pouze = (equality) | Rychlé lookup | Malá velikost, nelze range dotazy |
-| **GiST** | Generalized Search Tree | Full-text, geometrie, intervaly, IP rozsahy | Rychlé: overlaps, contains, distance | GIST pro geometrii (PostGIS), full-text |
-| **GIN** (Generalized Inverted Index) | Inverted index | Pole, JSONB, full-text search | contains (@>), overlaps (&&) | Pomalý build, rychlé čtení |
-| **BRIN** (Block Range Index) | Min/Max per block range | Velké tabulky, data v pořadí (time-series) | Range dotazy na korelovaná data | Extrémně malý (tisíckrát menší než B-tree) |
-| **SP-GiST** | Space-partitioned GiST | Quad-tree, KD-tree, radix tree | Partitioned search | Geografické clustery, síťová data |
-
-## Index selection guide
-
-| Query pattern | Doporučený index | Příklad |
-|--------------|-----------------|---------|
-| `WHERE user_id = 123` | B-tree na `user_id` | Uživatelský lookup |
-| `WHERE status = 'active' AND created_at > '2026-01-01'` | Composite B-tree na `(status, created_at)` | Filtrace + range |
-| `WHERE data @> '{"key": "value"}'` | GIN na JSONB sloupec | JSONB dotazy |
-| `WHERE tags && ARRAY['urgent']` | GIN na pole | Tagy |
-| `WHERE position <@> POINT(50, 14) < 1000` | GiST na geometry | Lokalitní dotazy |
-| `WHERE event_time BETWEEN '2026-06-01' AND '2026-06-02'` | BRIN na `event_time` | Time-series, logy |
-| `WHERE email = 'user@example.com'` | Hash na `email` | Equality only |
-
-## Query execution
-
-### Seq scan vs Index scan vs Bitmap scan
-
-| Typ | Popis | Kdy se používá |
-|-----|-------|---------------|
-| **Seq Scan** | Prochází všechny řádky tabulky | Velká část tabulky (>10 %), malá tabulka, žádný vhodný index |
-| **Index Scan** | Hledá v indexu, pak náhodný přístup k heap | Malá podmnožina dat (<5 %), selektivní dotazy |
-| **Index Only Scan** | Načítá data pouze z indexu (ne z heap) | Všechny potřebné sloupce jsou v indexu (covering index) |
-| **Bitmap Scan** | Kombinace více indexů → bitmapa → heap access | AND/OR podmínky na více indexovaných sloupcích |
-| **Bitmap Heap Scan** | Načítá řádky z bitmapy (srovnané) | AND/OR kombinace, ~5-20 % tabulky |
-
-### EXPLAIN ANALYZE
-
-```sql
-EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
-SELECT * FROM orders WHERE user_id = 456 AND created_at > '2026-01-01';
-
-- Výstup:
-- Index Scan using idx_orders_user_created on orders
--   Index Cond: ((user_id = 456) AND (created_at > '2026-01-01'::date))
--   Buffers: shared hit=3
--   Planning Time: 0.12 ms
--   Execution Time: 0.34 ms
-```
-
-Klíčové metriky: `Execution Time`, `Planning Time`, `Buffers` (hit/read/dirtied), `Rows Removed by Filter`, `Actual Time` (first...last)
-
-## Sharding
-
-Distribuce dat napříč uzly podle shard klíče.
-
-```
-                    ┌─────────┐
-                    │  Proxy  │
-                    │  Router │
-                    └────┬────┘
-              ┌──────────┼──────────┐
-         ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
-         │Shard A │ │Shard B │ │Shard C │
-         │ 0-100  │ │101-200 │ │201-300 │
-         └────────┘ └────────┘ └────────┘
-```
-
-### Hash-based sharding
-
-```
-shard_id = hash(shard_key) % number_of_shards
-```
-
-### Range-based sharding
-
- Data rozdělena podle rozsahu hodnot (např. uživatelé A-M, N-Z)
- Může vést k nerovnoměrnému rozdělení (hot spots)
-
-### Consistent hashing
-
-```
-Hash ring:
-   0 ─── shard A ─── hash(key1)
-         │
-   90 ─── shard B ─── hash(key2)
-         │
-  180 ─── shard C ─── hash(key3)
-         │
-  270 ─── shard D ─── hash(key4)
-```
-
- Minimalizuje přeuspořádání přidáním/odebráním nodu (pouze sousední shard)
- **Virtual nodes** (vnodes) — každý fyzický nod má více virtuálních bodů na ring (lepší distribuce)
- **Koordinační služba**: Cassandra (vnodes), Riak (vnodes), DynamoDB (Consistent Hashing)
-
-### Rebalancing
-
- **Ruční** — zastavit zápisy, přerozdělit data, restartovat
- **Automatické** — incremental migration (Cassandra vnodes)
- **Proxy-based** — Vitess (shard splitting), Citus (shard rebalancing)
-
-### Routing approaches
-
- **Proxy-based** — aplikace jde na proxy, ta routuje (Vitess, ProxySQL)
- **Client-side** — aplikace ví, na který shard jít
- **DNS-based** — každý shard má vlastní endpoint
+---

 ## CAP teorém

-V distribuovaném systému lze mít pouze 2 ze 3:
-
- **C**onsistency — všichni vidí stejná data
- **A**vailability — každý request dostane odpověď
- **P**artition tolerance — systém funguje i přes výpadek komunikace
+V distribuovaném systému lze mít pouze 2 ze 3: **C**onsistency, **A**vailability, **P**artition 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):
-
 - **P**artition → **A**vailability vs **C**onsistency
 - **E**lse (bez partition) → **L**atency vs **C**onsistency

@@ -242,82 +74,75 @@ PACELC rozšiřuje CAP o chování za normálních podmínek (bez partition):

 - **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 (nastolit konzistenci po obnově)
+- **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

-## Caching
+---

-| Vrstva | Nástroj | Use case |
-|--------|---------|----------|
-| Application cache | Redis, Memcached | Session, API response cache |
-| Database cache | Built-in | Query cache, buffer pool |
-| CDN cache | CloudFront, Fastly | Static assets, API responses |
-| HTTP cache | Varnish, nginx | Reverse proxy cache, ESI |
+## Replikace

-### Cache strategie
+| 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 |

-| Strategie | Popis | Use case |
-|-----------|-------|----------|
-| **Cache-aside** | Aplikace načte z cache, při miss jde do DB a naplní cache | Obecná |
-| **Read-through** | Cache sama načte z DB při miss | Jednoduché lookupy |
-| **Write-through** | Zápis jde do cache i DB zároveň | Konzistence |
-| **Write-behind** | Zápis do cache okamžitě, do DB asynchronně | Propustnost |
-| **Cache-aside (lazy loading)** | TTL + invalidace | Nejčastější |
+### Topologie

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

-**Data structures**:
+---

-| Struktura | Popis | Use case |
-|-----------|-------|----------|
-| **String** | Binární string (max 512 MB) | Cache hodnoty, session tokeny, counters |
-| **Hash** | Map field-value | Uživatelský profil, objekt v cache |
-| **List** | Linked list (push/pop na oba konce) | Queue (RPUSH/LPOP), log stream |
-| **Set** | Unikátní hodnoty (unordered) | Tags, deduplikace, memberships |
-| **Sorted Set** | Unikátní + score (řazení) | Leaderboardy, rate limiting, timeouts |
-| **Bitmap** | Bitové pole | Feature flagy, daily active users |
-| **HyperLogLog** | Approximate cardinality (12 KB = 2^64) | Unikátní návštěvníci (error < 1%) |
-| **Stream** | Append-only log (Kafka-like) | Event store, messaging |
+## Sharding

-**Eviction policies**:
+Distribuce dat napříč uzly podle shard klíče.

-| Policy | Popis | Use case |
-|--------|-------|----------|
-| **noeviction** | Chyba při zápisu když je plno | Transakční data, neztrácet |
-| **allkeys-lru** | LRU na všechny klíče | Obecná cache, standard |
-| **allkeys-lfu** | LFU na všechny klíče | Často přistupovaná data |
-| **volatile-lru** | LRU na klíče s TTL | Cache s expirací |
-| **volatile-ttl** | Nejblíž k expiraci | Krátkodobá data |
-| **allkeys-random** | Náhodný | Testování |
+```
+                     ┌─────────┐
+                     │  Proxy  │
+                     │  Router │
+                     └────┬────┘
+               ┌──────────┼──────────┐
+          ┌────▼───┐ ┌───▼────┐ ┌───▼────┐
+          │Shard A │ │Shard B │ │Shard C │
+          │ 0-100  │ │101-200 │ │201-300 │
+          └────────┘ └────────┘ └────────┘
+```

-**Redis Cluster vs Sentinel**:
+### Metody

-| Vlastnost | Redis Sentinel | Redis Cluster |
-|-----------|---------------|---------------|
-| **Škálování** | Read replicas (master + replica) | Data sharding (16384 hash slotů) |
-| **Auto-failover** | Ano (Sentinel) | Ano (gossip-based) |
-| **Multi-key ops** | Ano (transactiony na masteru) | Omezené (stejný hash slot) |
-| **Client komunikace** | Přes Sentinel (deprecated) | Cluster nodes redirect (MOVED/ASK) |
-| **Minimální uzly** | Master + Replica + 3 Sentinel | 3 masters (každý s replikou) |
-| **Use case** | Vysoká dostupnost, single shard | Multi-shard, horizontální škálování |
+| 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ší |

-### Connection pooling
+### Routing

-| Pooler | DB | Typ | Protokol |
-|--------|-----|-----|----------|
-| **PgBouncer** | PostgreSQL | Proxy (transaction/session) | PostgreSQL wire |
-| **RDS Proxy** | PostgreSQL, MySQL | Managed proxy | AWS |
-| **ProxySQL** | MySQL | Proxy (advanced routing) | MySQL wire |
-| **Odyssey** | PostgreSQL | Proxy (multithreaded) | PostgreSQL wire |
-| **pgpool-II** | PostgreSQL | Proxy (replication, load balancing) | PostgreSQL wire |
+- **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

-**PgBouncer režimy**:
- **Session pooling** — spojení drženo po celou dobu session (aplikace) → overhead
- **Transaction pooling** — spojení vráceno po dokončení transakce → efektivnější (vyžaduje bezstavovost)
+---
+
+## 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

-### Schéma migrace (PostgreSQL / MySQL)
+### Schema migrace

 ```
 V1__initial_schema.sql
@@ -332,7 +157,7 @@ V4__add_orders_table.sql
 2. **Migrate** — backfill dat, update aplikace na nové schema
 3. **Contract** — odstranění starého sloupce/tabulky

-### Nástroje detail
+### Nástroje

 | Nástroj | Jazyk | Strategie | Zero-downtime | Rollback |
 |---------|-------|-----------|--------------|----------|
@@ -343,41 +168,104 @@ V4__add_orders_table.sql
 | **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ý) |

-## 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 |
+## SQL Antipatterns

-## Storage engines — přehled
+Na základě *More SQL Antipatterns* (Karwin, 2026) — 14 nových antipatternů:

-### B-Tree vs LSM-Tree
+### Language antipatterns

-| Vlastnost | B-Tree | LSM-Tree |
-|-----------|--------|----------|
-| Zápis | In-place update (náhodný I/O) | Append-only (sekvenční I/O) |
-| Čtení | Rychlé (přímo v page) | Pomalejší (merge z více SSTable) |
-| Kompaktnost | Horší (page fragmentation) | Lepší (kompaktní SSTable) |
-| Write amplification | Nižší | Vyšší (kompakce) |
-| Read amplification | Nižší | Vyšší (bloom filtry pomáhají) |
-| Typické DB | PostgreSQL, MySQL (InnoDB) | Cassandra, RocksDB, LevelDB |
+| 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 |

-### Write-Ahead Log (WAL)
+### Optimization antipatterns

- Append-only log pro crash recovery
- Každá změna se zapíše do WAL před aplikací na data page
- Checkpoint = bod, od kterého je WAL při recovery potřeba
+| 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 |

-### MVCC (Multi-Version Concurrency Control)
+### Application antipatterns

- Každá transakce vidí snapshot dat v okamžiku startu
- Staré verze řádků zůstávají v tabulce (vacuum/GC)
- Izolační úrovně: Read Committed, Repeatable Read, Serializable
+| 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 |
+
+### 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

@@ -388,7 +276,48 @@ V4__add_orders_table.sql
 - **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](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*