First batch

2026-06-03 22:42:43 +02:00
parent c6fa0bff6a
commit 95d1839f05
31 changed files with 3527 additions and 485 deletions
--- a/.DS_Store
+++ b/.DS_Store
--- a/CASSANDRA.md
+++ b/CASSANDRA.md
@@ -0,0 +1,135 @@
 # 🐘 Cassandra & ScyllaDB
 ## Přehled
 Apache Cassandra je distribuovaná wide-column NoSQL databáze navržená pro vysokou dostupnost a lineární škálovatelnost bez single point of failure. Inspirována Amazon Dynamo paperem (2007) a Google Bigtable. ScyllaDB je C++ reimplementace kompatibilní s Cassandra protokolem, s drasticky nižší latencí a vyšší propustností.
 ## Architektura (Dynamo-inspired)
 ### Consistent hashing
 Data rozdělena na hash ringu, každý node zodpovídá za rozsah tokenů:
 ```text
   0 ─── node A ─── hash(key1)
         │
   90 ─── node B ─── hash(key2)
         │
  180 ─── node C ─── hash(key3)
         │
  270 ─── node D ─── hash(key4)
 ```
 - Přidání/odebrání nodu ovlivní jen K/N klíčů (díky virtual nodes)
 - **Virtual nodes** (vnodes) — každý fyzický node má ~100-200 tokenů na ringu (rovnoměrnější distribuce)
 ### Quorum (N, R, W)
 - N = replication factor (typicky 3)
 - R = read quorum (typicky 2)
 - W = write quorum (typicky 2)
 - Podmínka: R + W > N (pro strong-ish konzistenci)
 - **Sloppy quorum** — při nedostupnosti nodu, data dočasně uložena na jiném
 - **Hinted handoff** — dočasný zápis s hintem, při obnově se data přenesou
 ### Gossip protocol
 Decentralizované šíření membership informací — každý node periodicky komunikuje s 1-3 náhodnými nodes. Žádný centrální bod selhání.
 ### Vector clocks
 Zachycení kauzality verzí objektu. Při konfliktu (partition merge) se vrací obě verze — aplikace merguje.
 ### Merkle trees
 Anti-entropy — strom hashů pro detekci divergence mezi replikami. Rychlá detekce, které rozsahy dat jsou rozdílné.
 ### Write path
 ```text
 Client → Coordinator → [1. Write to commit log (disk)]
                       [2. Write to memtable (RAM)]
                       [3. Acknowledge client]
                       → [4. Flush memtable → SSTable (periodicky)]
                       → [5. Compaction (merge SSTables)]
 ```
 ### Read path
 ```text
 Client → Coordinator → [1. Check bloom filter]
                       [2. Check row cache / key cache]
                       [3. Read from SSTable (disk)]
                       [4. Merge with memtable]
                       [5. Repair if stale (read repair)]
 ```
 ## Cassandra vs ScyllaDB
 | Vlastnost | Cassandra | ScyllaDB |
 |-----------|-----------|----------|
 | **Jazyk** | Java (JVM) | C++ (seastar framework) |
 | **Architektura** | Thread-per-connection | Shared-nothing, CPU sharding |
 | **Latence** | 5-20 ms (typicky) | 1-3 ms (typicky) |
 | **Propustnost** | Dobrá | 5-10× vyšší na stejný HW |
 | **GC pauzy** | Ano (JVM) | Ne (žádný GC) |
 | **NUMA** | OS-dependent | Nativní NUMA aware |
 | **Workload** | Standardní | High-throughput, real-time |
 | **Cena** | Open source | Open source + Enterprise |
 ## Data model
 - **Keyspace** = namespace (analogie DB)
 - **Table** = definice sloupců (ne schema-less)
 - **Partition key** = hash klíč pro distribuci na ringu
 - **Clustering columns** = řazení v rámci partition
 - **Primary key** = Partition key + Clustering columns
 ## Doporučení — v čem je Cassandra lepší
 | Oblast | Cassandra | Konkurence | Proč Cassandra |
 |--------|-----------|------------|----------------|
 | **Zápisová propustnost** | Lineární škálování, žádný master bottleneck | PostgreSQL (master writes) | Každý node zapisuje, žádný single point of failure |
 | **Dostupnost** | AP z CAP — vždy zapisovatelná | MongoDB (CP, primary down = read-only) | "Always-writeable" filozofie |
 | **Multi-DC** | Nativní, režim per DC | CockroachDB (komplexní) | Jednoduchá konfigurace, latency-tolerant |
 | **Time-series** | Wide-row model, TTL, compaction | InfluxDB (specializovaná) | Lze kombinovat s dalšími workloady |
 | **IoT / sensor data** | Lineární škálování, žádný master | MongoDB (sharding komplexní) | Předvídatelný výkon při růstu |
 | **Geografická distribuce** | Nativní multi-DC, hinted handoff | Spanner (vendor lock-in) | Open source, žádná závislost |
 ### Kdy použít Cassandra / ScyllaDB
 - **IoT / sensor data ingest** — miliony zápisů/s, žádné ztráty
 - **Time-series v masivním měřítku** — metriky, logy, event data
 - **Uživatelské activity history** — zápisově těžké workloady
 - **Multi-DC aplikace** — data dostupná v každé lokalitě
 - **Doporučovací systémy** — wide-row model pro "co viděl uživatel"
 - **Message / event store** — high-throughput append s TTL
 ### Kdy použít něco jiného
 - **Relace, JOINy, transakce** → PostgreSQL (Cassandra nemá JOINy, omezené transakce)
 - **Full-text search** → Elasticsearch
 - **Agregace / OLAP** → ClickHouse (Cassandra není analytická DB)
 - **Malá data (< 100 GB)** → PostgreSQL (Cassandra overhead se nevyplatí)
 - **Časté ready podle vedlejších klíčů** → DynamoDB (SADA indexy) — Cassandra má omezené secondary indexy
 ### ScyllaDB specific
 ScyllaDB je výhodná když:
 - Potřebujete 5-10× vyšší propustnost na stejném HW
 - Máte latency-sensitive workload (real-time scoring, ad-tech)
 - Chcete eliminovat JVM/GC problémy
 - Potřebujete předvídatelný výkon (P99 < 5 ms)
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 ### Doporučená literatura
 | Paper / Kniha | Autoři | Popis |
 |---------------|--------|-------|
 | Dynamo: Amazon's Highly Available Key-value Store (SOSP 2007) | DeCandia et al. | Zakladatelský paper pro Cassandra architekturu |
 | Cassandra: The Definitive Guide (3rd ed.) | E. Hewitt | Komplexní průvodce nasazením a provozem |
 *Poslední revize: 2026-06-03*
--- a/CICD.md
+++ b/CICD.md
@@ -60,7 +60,7 @@ on:
    branches: [main]
 env:
-  NODE_VERSION: "20"
+  NODE_VERSION: "22"
 jobs:
  lint:
@@ -78,7 +78,7 @@ jobs:
    needs: lint
    strategy:
      matrix:
-        node-version: [18, 20, 22]
+        node-version: [22, 24]
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
@@ -142,14 +142,14 @@ variables:
 lint:
  stage: lint
-  image: node:20
+  image: node:22
  script:
    - npm ci
    - npm run lint
 test:
  stage: test
-  image: node:20
+  image: node:22
  needs: ["lint"]
  script:
    - npm test
@@ -205,7 +205,67 @@ lint ──→ test ──→ build ──→ deploy-staging ──→ deploy-pr
 | Ansible | Imperative/Config | YAML |
 | Chef/Puppet | Config mgmt | Ruby DSL |
-### Terraform detail
+### Infrastructure as Code (2. vydání) — Kief Morris
 Klíčová reference pro navrhování a provozování dynamické cloudové infrastruktury pomocí IaC. Kniha je tool-agnostic — zaměřuje se na vzory a postupy, ne na konkrétní nástroje.
 #### Tři základní praktiky
 | Praktika | Popis |
 |----------|-------|
 | **Define everything as code** | Veškerá infrastruktura definovaná v kódu, version control, repeatabilita |
 | **Continuously test and deliver** | Každá změna prochází pipeline s automatickými testy |
 | **Small, independent pieces** | Malé, volně provázané komponenty — snadnější změna a testování |
 #### Principy cloudové infrastruktury
 - **Systems reproducible** — infrastructure can be recreated from code at any time
 - **Systems disposable** — instance mohou být zničeny a znovu vytvořeny
 - **Systems consistent** — všechny prostředí identická (žádné snowflake servery)
 - **Processes repeatable** — automatizace namísto manuálních postupů
 - **Design always changing** — infrastruktura se neustále vyvíjí (není build-and-forget)
 #### Anti-vzory (pitfalls)
 | Anti-vzor | Popis |
 |-----------|-------|
 | **Snowflake server** | Každý server jiný, nelze reprodukovat |
 | **Configuration drift** | Ruční změny → odchylky od definovaného stavu |
 | **Server sprawl** | Příliš mnoho serverů bez správy |
 | **Fragile infrastructure** | Křehká infrastruktura — změny často rozbijí systém |
 | **Automation fear** | Strach z automatizace → ruční zásahy |
 #### Struktura knihy (4 části)
 1. **Foundations** — rámec nástrojů a technologií pro cloud platformy
 2. **Working with infrastructure stacks** — definice, provisionování, testování a CD změn infrastruktury
 3. **Working with servers and application runtime platforms** — provisionování a konfigurace serverů a clusterů
 4. **Working with large systems and teams** — workflow, governance, architektonické vzory pro více týmů
 #### Organizace IaC kódu
 | Vzor | Popis |
 |------|-------|
 | **Monorepo** | Jeden repozitář pro vše — build-time integrace, vhodný pro malé týmy |
 | **Microrepo** | Samostatný repozitář pro každý projekt — izolace, vhodný pro velké týmy |
 | **Domain organization** | Organizace kódu podle doménových konceptů (ne podle technologií) |
 **Doporučení:**
 - Infrastruktura a aplikace mohou být ve stejném nebo odděleném repozitáři záleží na organizační struktuře (Team Topologies)
 - Konfigurační soubory per-environment (test, staging, production) ukládat v rámci projektu
 - Testy patří k projektu, integrační testy mohou být v samostatném projektu
 - Infrastrukturní kód by neměl přímo deployovat aplikace — použít OS packaging (RPM, deb)
 #### Expand-Contract pattern pro změny infrastruktury
 Stejný princip jako u databázových migrací:
 1. **Expand** — přidat nový resource (nestará verze stále běží)
 2. **Migrate** — přesunout traffic / závislosti na nový resource
 3. **Contract** — odstranit starý resource
 Zabraňuje výpadkům při refaktorování infrastruktury.
 ## Terraform detail
 #### State locking mechanism
@@ -278,11 +338,95 @@ terraform fmt     → Formátování HCL
 - State locking (DynamoDB, Consul)
 - Workspaces pro oddělení prostředí
 ### Terraform: Up and Running (3rd ed.) — Yevgeniy Brikman
 Praktický průvodce Terraformem od zakladatele Gruntwork. 3. vydání (2022) přidává přes 100 stran nového obsahu, aktualizaci z Terraform 0.12 na 1.2 a dvě nové kapitoly.
 #### Co je nového ve 3. vydání
 | Novinka | Popis |
 |---------|-------|
 | **Kapitola: Secrets management** | Správa tajemství s Terraformem — Vault, AWS Secrets Manager, KMS, OIDC, `sensitive` proměnné |
 | **Kapitola: Multiple providers** | Práce s vícero regiony, účty, cloudy včetně Kubernetes (AWS EKS) |
 | **Terraform 1.0+** | Backward compatibility promise, stabilita, HashiCorp IPO |
 | **Provider versioning** | `required_providers` blok + `terraform.lock.hcl` (lock file) |
 | **Module iteration** | `count` a `for_each` na modulech (od Terraform 0.13) |
 | **Variable validation** | `validation {}` bloky, `precondition` / `postcondition` |
 | **Refactoring** | `moved` bloky — bezpečný refactoring bez ruční manipulace se state |
 | **CI/CD security** | OIDC autentizace, isolated workers pro `terraform apply` |
 #### Secrets management s Terraformem
 ```hcl
 # Proměnná označená jako sensitive — nikdy se nezobrazí v logu
 variable "db_password" {
  type      = string
  sensitive = true
 }
 # Čtení secrets z AWS Secrets Manager
 data "aws_secretsmanager_secret" "db" {
  name = "production/db/master"
 }
 data "aws_secretsmanager_secret_version" "db" {
  secret_id = data.aws_secretsmanager_secret.db.id
 }
 ```
 **Doporučená hierarchie bezpečnosti:**
 1. **OIDC** — nejbezpečnější, bez creds na CI serveru (GitHub Actions → IAM role)
 2. **IAM role** — instance profile (EC2, ECS, EKS)
 3. **Environment variables** — omezené, riziko úniku v logu
 4. **Isolated workers** — oddělený worker s admin permissions, API pouze `plan`/`apply`
 #### Testing Terraform kódu
 | Vrstva | Nástroje | Popis |
 |--------|----------|-------|
 | **Static analysis** | `terraform validate`, `tflint`, `tfsec`, `checkov` | Analýza kódu bez běhu |
 | **Plan testing** | `conftest` + OPA (Rego), `terraform plan` parse | Validace plánu proti policy |
 | **Unit tests** | Terratest (Go), `terraform fmt`, `terraform validate` | Testování modulů izolovaně |
 | **Integration tests** | Terratest (Go) | Skutečné provisionování + assert |
 | **End-to-end tests** | Terratest | Plný stack, smoke testy |
 #### Policy enforcement
 ```rego
 # OPA / conftest — zakázat veřejné S3 bucket
 package main
 deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  resource.change.after.acl == "public-read"
  msg = sprintf("%s must not be public", [resource.address])
 }
 ```
 #### Production-grade checklist dle Brikmana
 1. **Small modules** — jeden modul = jedna věc (single responsibility)
 2. **Composable modules** — moduly se dají skládat do větších celků
 3. **Testable modules** — každý modul má testy (Terratest)
 4. **Releasable modules** — verzování (Git tagy, Terraform Registry)
 5. **Version control** — všechno v gitu, včetně `.terraform.lock.hcl`
 6. **Remote state** — S3 + DynamoDB nebo Terraform Cloud
 7. **CI/CD pipeline** — `plan` na MR, `apply` po merge do main
 8. **Secrets management** — žádné secrets v plaintextu v kódu
 9. **Policy as code** — OPA / Sentinel pro compliance
 10. **Sandbox prostředí** — každý vývojář má vlastní izolované prostředí
 #### Zlaté pravidlo (Golden Rule of Terraform)
 > **Master branch state musí být vždy v souladu s produkčním prostředím.**
 > Nikdy nespouštět `terraform apply` ručně lokálně na produkci — vždy přes CI/CD.
 ## Dockerfile best practices
 ```dockerfile
 # Multi-stage build
-FROM node:20-alpine AS builder
+FROM node:22-alpine AS builder
 WORKDIR /app
 COPY package*.json ./
 RUN npm ci --only=production
@@ -290,7 +434,7 @@ COPY . .
 RUN npm run build
 # Runtime stage — distroless
-FROM gcr.io/distroless/nodejs20-debian12
+FROM gcr.io/distroless/nodejs22-debian12
 WORKDIR /app
 COPY --from=builder /app/dist ./dist
 COPY --from=builder /app/node_modules ./node_modules
@@ -494,5 +638,17 @@ Nové nástroje: Harness (AI-native CD), GitLab 19.0 (agentic MR workflows, secr
 ## Zdroje
 Odkazy, knihy a standardy: [sources/cicd/sources.md](sources/cicd/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Klíčový přínos |
 |-------|--------|------|----------------|
 | The DevOps Handbook | Kim, Humble, Debois, Willis | 978-1942788003 | Principy CALMS (Culture, Automation, Lean, Measurement, Sharing), flow mapa, deployment pipeline |
 | Continuous Delivery | Humble, Farley | 978-0321601912 | Deployment pipeline, commit stage, acceptance tests, capacity testing, zero-downtime release |
 | CI/CD Design Patterns | Bajpai, Schildmeijer, Piwosz, Mishra | 978-1-83588-965-7 | 30+ návrhových vzorů pro CI/CD — pipeline patterns, GitOps, security, testing, deployment strategie |
 | DevOps Frameworks, Techniques, and Tools | Vijayakumaran, Kofler, Öggl, Springer | 978-1-4932-2670-2 | Rámec pro adopci DevOps, srovnání nástrojů (Jenkins vs GitLab vs GitHub Actions), techniky pro monitoring a observabilitu |
 - **Quality gates** — automated checks před každým povýšením do dalšího prostředí
 - **Pipeline visibility** — dashboard s aktuálním stavem všech pipeline (GitHub, GitLab, ArgoCD)
 *Poslední revize: 2026-06-03*
--- a/CLOUD.md
+++ b/CLOUD.md
@@ -38,6 +38,22 @@
 - **Data gravitace** — pohyb dat mezi cloudy je drahý a pomalý
 - **Monitoring** — jeden pane of glass napříč cloudy (Grafana, Datadog)
 ### Cloud Adoption Frameworks (CAF)
 Každý hlavní poskytovatel má vlastní Cloud Adoption Framework pro strukturovaný přístup k adopci cloudu:
 | Poskytovatel | Rámec | Zaměření |
 |-------------|-------|----------|
 | AWS | AWS CAF | 6 perspektiv: Business, People, Governance, Platform, Security, Operations |
 | Azure | Microsoft CAF | 8 metodik: Strategy, Plan, Ready, Migrate, Innovate, Govern, Manage, Secure |
 | GCP | Google CAF | 4 pilíře: Learn, Scale, Modernize, Operate |
 Multi-Cloud Administration Guide (Mulder, 2024) doporučuje kombinovat CAF rámce napříč poskytovateli pro jednotné governanční modely, zejména v oblastech:
 - **Interoperabilita** — standardizace API a IaC napříč cloudy (Terraform, Pulumi)
 - **Data governance** — jednotná politika pro data residency a životní cyklus dat
 - **Compliance automation** — automatizované audity napříč cloudy (AWS Config, Azure Policy, GCP Org Policies)
 - **Access management** — federace identit a centralizované RBAC
 ## Migrační strategie — 6 Rs
 | Strategie | Popis | Náročnost | Typický scénář |
@@ -128,7 +144,7 @@ Obdoby: Azure Well-Architected Framework, GCP Architecture Framework
 | **Storage optimized** | I4i, im4gn | 1:4 + NVMe | Transactional DB, data warehousing, Kafka | i4i.large ~$0.138/h |
 | **GPU / ML** | P5, g5, trn1 | GPU attach | AI training (P5), inference (g5), ML (trn1) | g5.xlarge ~$1.006/h |
-Viz [HARDWARE.md](HARDWARE.md#gpu-v-serverech) pro detail GPU modelů a konfigurací.
+Viz [GPU.md](GPU.md) pro detail GPU modelů a konfigurací.
 ### Úložiště
@@ -169,6 +185,29 @@ Region ┌───────────────────────
       └──────────────────────────────┘
 ```
 ## Disaster Recovery strategie
 ### DR strategie na AWS (od nejméně po nejvíce připravené)
 | Strategie | RTO | RPO | Náklady | Popis |
 |-----------|-----|-----|---------|-------|
 | **Backup & Restore** | hodiny | 24 h | Nízké | Pravidelné zálohy dat do S3/Glacier, obnova v DR regionu |
 | **Pilot Light** | desítky minut | minuty | Střední | Minimální běžící kopie (DB, core služby), škálování při failover |
 | **Warm Standby** | minuty | sekundy | Vysoké | Běží zmenšená kopie produkce, škálování při failover |
 | **Active-Active (Multi-Region)** | sekundy | < 1 s | Velmi vysoké | Plně aktivní ve více regionech, traffic routing (Route53, Global Accelerator) |
 Klíčové knihy k tématu:
 - **Engineering Resilient Systems on AWS** (Schwarz, Moran, Bachmeier, 2024) — praktické laby pro resilience vzory: back off and retry, multi-Region failover, circuit breaker, chaos engineering pomocí AWS Fault Injection Simulator
 - **Building Resilient Architectures on AWS** (2025) — data security, backup strategie, automace recovery plánů
 ### Chaos Engineering
 Cílené vnášení poruch do systému pro ověření odolnosti:
 - **AWS Fault Injection Simulator (FIS)** — spravované fault injection pro EC2, ECS, EKS, RDS
 - **Nástroje**: Chaos Mesh (Kubernetes), Gremlin, Litmus
 - **Postup**: definice hypotézy → provedení experimentu → měření dopadu → zlepšení systému
 - **Bezpečnost**: experimenty v izolovaném prostředí, safety controls, automatic rollback
 ## Cloud design patterns
 ### Strangler Fig
@@ -202,6 +241,50 @@ Ukládání stavu jako sekvence událostí (eventů), ne aktuálního stavu.
 - Výhody: audit trail, time travel, CQRS kompatibilita
 - Implementace: EventStoreDB, Kafka (log), DynamoDB + CDC
 ### Další cloudové patterny (Wilder — Cloud Architecture Patterns)
 | Pattern | Kategorie | Popis |
 |---------|-----------|-------|
 | **Horizontally Scaling Compute** | Škálovatelnost | Přidávání/odebírání instancí dle zátěže, elasticita |
 | **Queue-Centric Workflow** | Škálovatelnost | Decoupling komponent přes fronty (SQS, RabbitMQ), zpracování asynchronně |
 | **Auto-Scaling** | Škálovatelnost | Automatické škálování na základě metrik (CPU, memory, request count) |
 | **MapReduce** | Big Data | Distribuované zpracování dat (Hadoop, EMR, BigQuery) |
 | **Database Sharding** | Big Data | Horizontální partition dat napříč databázemi |
 | **Busy Signal** | Failure Handling | Graceful degradace při přetížení (HTTP 503, throttling, backpressure) |
 | **Node Failure** | Failure Handling | Detekce a automatické zotavení z výpadku výpočetního uzlu |
 | **Colocation** | Distribuovaní uživatelé | Umístění compute blízko datům pro snížení latence |
 | **Valet Key** | Distribuovaní uživatelé | Delegovaný přístup ke storage (SAS tokeny, S3 presigned URLs) |
 | **Multi-Site Deployment** | Distribuovaní uživatelé | Aktivní nasazení ve více geografických lokalitách |
 ## Evolutionary Architecture
 Definice (Ford, Parsons, Kua, 2022): *Evoluční architektura podporuje řízenou, inkrementální změnu napříč více dimenzemi.*
 ### Fitness Functions
 Automatizované kontroly architektonických charakteristik — obdoba testů pro architekturu:
 | Typ | Popis | Příklad |
 |-----|-------|---------|
 | **Atomic** | Kontroluje jednu metriku | Cyclomatic complexity < 10 |
 | **Holistic** | Kontroluje celkový systém | Latence end-to-end < 200 ms |
 | **Triggered** | Spouštěná událostí (CI/CD commit, deployment) | Ověření API kontraktu |
 | **Continous** | Běží nepřetržitě v produkci | Monitoring dependency freshness |
 | **Static** | Analýza kódu bez běhu | SonarQube, ESLint |
 | **Dynamic** | Analýza za běhu | Load testy, chaos experimenty |
 ### Principy evoluční architektury
 1. **Inkrementální změna** — malé, bezpečné změny díky CI/CD, deployment pipelines, zralému DevOps
 2. **Fitness funkce** — automatizovaná ochrana architektonických charakteristik (škálovatelnost, performance, bezpečnost)
 3. **Správa couplingů** — vědomá práce s propojením komponent (affinity, volatility, cykly)
 4. **Evoluční data** — databázové migrace jako first-class občan (evoluční schemata, expand-contract pattern)
 ### Antipatterny
 - **Big Design Up Front (BDUF)** — snaha navrhnout vše předem, ignoruje změny
 - **No Design at All** — absence architektonického myšlení, čistě emergentní design
 - **Premature Standardization** — zavedení standardů dříve, než je známe domény
 ## Hybrid cloud konektivita
 Viz také: [NETWORKING.md](NETWORKING.md) — síťová architektura (VPN, BGP, VPC design).
@@ -298,6 +381,68 @@ Organization Node
 - **Resource Manager** — hierarchie: Organization → Folder → Project → Resources
 - **Project limits** — max 30 projektů (lze navýšit), resources per project 10k
 ## 12-Factor App metodologie
 Metodologie pro building cloud-native aplikací (Heroku, 2011), rozšířená knihou **Multi-Cloud Handbook for Developers** (Natarajan, Jacob, 2024).
 | # | Faktor | Popis | Cloudová implementace |
 |---|--------|-------|----------------------|
 | 1 | **Codebase** | Jeden repozitář, mnoho deploymentů | Git + CI/CD pipeline |
 | 2 | **Dependencies** | Explicitní deklarace závislostí | package.json, requirements.txt, Docker image |
 | 3 | **Config** | Konfigurace v proměnných prostředí | Secrets Manager, Parameter Store, env vars |
 | 4 | **Backing services** | Závislé služby jako připojené zdroje | RDS, S3, Redis — připojení přes connection string |
 | 5 | **Build, release, run** | Striktní oddělení fází sestavení | CI/CD pipeline (GitHub Actions, GitLab CI) |
 | 6 | **Processes** | Aplikace jako bezstavové procesy | Horizontální škálování, session v Redis |
 | 7 | **Port binding** | Služba exportuje port, není vložena do serveru | Express, FastAPI, Spring Boot na vlastním portu |
 | 8 | **Concurrency** | Škálování pomocí procesního modelu | Horizontal Pod Autoscaler (K8s), EC2 Auto Scaling |
 | 9 | **Disposability** | Rychlý start a graceful shutdown | Health checks, SIGTERM handling, preStop hooks |
 | 10 | **Dev/Prod parity** | Co nejmenší rozdíl mezi prostředími | Docker, IaC (Terraform), stejné backing services |
 | 11 | **Logs** | Logy jako event streamy | stdout/stderr → CloudWatch, ELK, Datadog |
 | 12 | **Admin processes** | Administrativní úlohy jako one-off procesy | DB migrace, data backfill — spuštěno v izolaci |
 ### Rozšíření pro multi-cloud (Multi-Cloud Handbook for Developers)
 - **API-first design** — konzistentní API rozhraní napříč cloudy (REST, gRPC)
 - **Domain-Driven Design (DDD)** — ohraničené kontexty mapované na cloudové služby
 - **Service Mesh** — Istio, Linkerd pro observabilitu, traffic management a security napříč cloudy
 - **GitOps** — declarativní deployment s ArgoCD/Flux napříč Kubernetes clustery v různých cloudech
 ## Azure Cloud Native Architecture (mapová příručka)
 Na základě **The Azure Cloud Native Architecture Mapbook (2nd ed.)** (Eyskens, 2025) — 40+ architektonických map napříč doménami:
 ### Domény architektonických map
 | Doména | Klíčové služby Azure | Architektonické vzory |
 |--------|---------------------|----------------------|
 | **Infrastructure** | VNet, Azure Firewall, ExpressRoute, VPN Gateway | Hub-and-spoke, Virtual WAN, Private Link |
 | **Applications** | App Service, API Management, Service Bus, Functions | Event-driven, Strangler Fig, Backend for Frontend |
 | **Data** | Cosmos DB, SQL Database, Synapse, Data Lake | CQRS, Event Sourcing, Polyglot Persistence |
 | **Container Orchestrators** | AKS, Azure Container Apps, ACA | Sidecar, Ambassador, Adapter (service mesh) |
 | **AI** | Azure OpenAI, Cognitive Services, ML Studio | RAG, model fine-tuning, MLOps |
 | **Security** | Entra ID, Defender for Cloud, Key Vault, Sentinel | Zero Trust, Defense in depth, JIT Access |
 ### Využití Cloud Adoption Framework na Azure
 - **Strategy** — business case, katalog aplikací, racionalizace portfolia
 - **Plan** — landing zone design, governance baseline, subscription taxonomy
 - **Ready** — implementace landing zones (ALZ), Azure Policy, Networking, Identity
 - **Migrate** — assessment (Azure Migrate), rehost/replatform, test a cutover
 - **Govern** — cost management, policy enforcement, compliance monitoring
 ## Srovnání cloudových poskytovatelů
 Na základě **Cloud Computing: AWS, Azure, Google Cloud** (Sario, 2025):
 | Oblast | AWS | Azure | GCP |
 |--------|-----|-------|-----|
 | **Compute** | EC2, Lambda, ECS/EKS | VMs, Functions, AKS | GCE, Cloud Functions, GKE |
 | **Storage** | S3, EBS, EFS | Blob, Disk, Files | Cloud Storage, Persistent Disk, Filestore |
 | **Databáze relační** | RDS (MySQL, PG, SQL Server, Oracle, MariaDB) | SQL Database, MySQL/PostgreSQL | Cloud SQL (MySQL, PG, SQL Server) |
 | **Databáze NoSQL** | DynamoDB, ElastiCache | Cosmos DB, Redis Cache | Firestore, Bigtable, Memorystore |
 | **Message queue** | SQS, SNS | Service Bus, Queue Storage | Pub/Sub, Tasks |
 | **Observabilita** | CloudWatch, X-Ray | Monitor, Application Insights | Cloud Monitoring, Cloud Trace |
 | **AI/ML** | SageMaker, Bedrock | Azure ML, OpenAI | Vertex AI, AutoML |
 | **Cena (compute)** | On-demand, Reserved, Spot, Savings Plan | Pay-as-you-go, Reserved, Spot | On-demand, Committed Use, Spot |
 ## Best practices
 - Používejte **infrastructure as code** (Terraform, Pulumi, CDK)
@@ -313,3 +458,12 @@ Odkazy, knihy a standardy: [sources/cloud/sources.md](sources/cloud/sources.md)
 - **Cost tagging** — assign tags pro chargeback/showback (Environment, Team, Cost Center, Application)
 - **Automated compliance** — AWS Config, Azure Policy, GCP Org Policies pro guardrails
 - **Multi-account strategie** — AWS Control Tower, Azure Landing Zones, GCP Resource Hierarchy
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | The AI Cloud Infrastructure Blueprint | Thummarakoti, Vududala, Madupati, Kaushik | 978-1-041-16642-9 | End-to-end průvodce návrhem, deploymentem a správou AI systémů na cloudových platformách. Pokrývá public/private/hybrid/multi-cloud modely pro AI, infrastrukturu pro ML trénování a inferenci, MLOps. Cílová skupina: architekti, data scientists, DevOps. |
 | AWS for Solutions Architects (3rd ed.) | Shrivastava, Srivastav, Thakur | 978-1-83664-193-3 | Praktický průvodce AWS architekturou — compute (EC2, Lambda), storage (S3, EBS), databáze (RDS, DynamoDB), networking, security, Well-Architected Framework, migrace, cost optimization. Vhodné pro přípravu na AWS Solutions Architect certifikaci. |
 *Poslední revize: 2026-06-03*
--- a/CONNECTIVITY.md
+++ b/CONNECTIVITY.md
@@ -73,7 +73,7 @@
 | **Gen 5** | 16 Gbps | 16GFC | SFP+ | 10 km | Legacy SAN |
 | **Gen 6** | 32 Gbps | 32GFC | SFP28 | 10 km | Současný standard |
 | **Gen 7** | 64 Gbps | 64GFC | SFP56 | 10 km | Emerging, high-performance |
-| **Gen 8** | 128 Gbps | 128GFC | QSFP28 | 10 km | Budoucnost (2026+) |
+| **Gen 8** | 128 Gbps | 128GFC | QSFP28 | 10 km | Emerging (první produkční nasazení) |
 **HBA (Host Bus Adapter)**:
@@ -199,6 +199,72 @@ mpathconf --enable --with_multipathd y
 └─────────────────────────────────┘
 ```
 ### NVIDIA Mellanox ConnectX NICs
 NVIDIA Mellanox je přední výrobce NIC adaptérů pro AI/HPC a cloud datová centra.
 | Model | PCIe | Max rychlost | Form factor | Klíčové features |
 |-------|------|-------------|-------------|------------------|
 | **ConnectX-5** | PCIe 3.0 x16 | 100 GbE (dual) | HHHL | RoCE, NVMe-oF target offload, MPI offload |
 | **ConnectX-6 Dx** | PCIe 4.0 x16 | 200 GbE (1-port) / 100 GbE (2-port) | HHHL, OCP 3.0 | ASAP² vSwitch offload, IPsec/TLS inline crypto, AES-XTS, 215 Mpps DPDK |
 | **ConnectX-6 Lx** | PCIe 4.0 x8 | 25 GbE (dual) | HHHL, OCP 3.0 | RoCE, Secure Boot, low-power |
 | **ConnectX-7** | PCIe 5.0 x16 | 400 GbE (1-port) / 200 GbE (2-port) | HHHL | NDR InfiniBand + 400GbE, GPUDirect, SHARP |
 | **ConnectX-8** | PCIe 6.0 x16 | 800 GbE (1-port) / 400 GbE (2-port) | HHHL | XDR InfiniBand, sub-500ns latence, in-network computing, multi-host |
 **Platformy**: Spectrum-X Ethernet (end-to-end AI networking), Quantum InfiniBand, BlueField DPU.
 ### Broadcom Emulex FC HBA
 | Model | Rychlost | PCIe | Porty | Features |
 |-------|----------|------|-------|----------|
 | **LPe35000** (Gen 7) | 32 GFC | PCIe 3.0 x8 | 1-2 | NVMe-FC, T10-PI (DIF), SR-IOV, Silicon Root of Trust |
 | **LPe35002** (Gen 7) | 32 GFC | PCIe 3.0 x8 | 2 | NVMe-FC, Secure Boot, digitálně podepsaný firmware |
 | **LPe36000** (Gen 7) | 64 GFC | PCIe 4.0 x16 | 1-2 | První 64GFC HBA na trhu, 10M IOPS, 3× lepší latence než Gen 6 |
 **Klíčové vlastnosti**: podpora NVMe over FC, T10 DIF (Data Integrity Field), 10M MTBF, NIST SP 800-193 compliant. Gen 7 přináší až 10M IOPS a 3× nižší latenci oproti Gen 6.
 ### NVMe-oF specifikace
 NVMe over Fabrics (NVMe-oF) rozšiřuje NVMe protokol z lokálního PCIe na síťové transporty. První specifikace 1.0 vydána v červnu 2016, aktuálně součástí NVMe 2.3 (srpen 2025). Podporované transporty:
 | Transport | Specifikace | Use case |
 |-----------|------------|----------|
 | **NVMe over PCIe** | NVMe Base | Lokální NVMe SSD |
 | **NVMe over RDMA** (RoCE, InfiniBand, iWARP) | NVMe Transport | AI/ML, HPC, nejnižší latence <5 µs |
 | **NVMe over TCP** | NVMe Transport | Standardní Ethernet, bez RDMA, latence ~50 µs |
 | **NVMe over FC** (FC-NVMe) | INCITS T11 | Enterprise SAN, FC fabric |
 NVMe 2.3 přidává Computational Programs Command Set, Storage Level Management (SLM), a Zoned Namespaces (ZNS). NVMe-MI definuje management rozhraní.
 ### Dell PowerEdge R760 — NIC placement
 Server Dell R760 podporuje:
 - **OCP 3.0** adaptéry (až 2×) — 1/10/25/100 GbE
 - **PCIe Gen5** sloty — 8× slotů (6× FHHL + 2× LP)
 - **LOM** — 2× 1 GbE Broadcom 5720 na základní desce
 - Maximální rychlost NIC: 100 GbE (QSFP56)
 - Supported typy: RJ45, SFP+, SFP28, QSFP28, QSFP56
 Doporučené konfigurace:
 - Standard: OCP 3.0 2× 25 GbE + PCIe storage HBA
 - AI/ML: PCIe 100 GbE (riser config 1, slot 1-2) + GPU v ostatních slotech
 ### HPE Gen11 NIC options
 HPE ProLiant Gen11 (DL360/DL380) podporuje:
 - **OCP 3.0** sloty (až 2) — 10/25/100/200 GbE (Broadcom, Intel, NVIDIA Mellanox)
 - **PCIe Gen5** adaptéry — 8× slotů (DL380) / 3× sloty (DL360)
 - **iLO 6** dedikovaný management port (1 GbE)
 - Podporované NIC: Broadcom BCM57412 (10GbE), BCM57504 (25GbE), NVIDIA ConnectX-6 Dx (100GbE)
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | AI Data Center Network Design and Technologies (1st ed., 2026) | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | První vendor-agnostický průvodce návrhem sítí pro AI trénování a inferenci. Pokrývá high-radix fabric, lossless Ethernet/IP, UEC technologie, chlazení a power pro AI klastry. Autoři z HPE Juniper Networking. |
 *Poslední revize: 2026-06-03*
--- a/DATABASES.md
+++ b/DATABASES.md
@@ -4,23 +4,29 @@
 ### Relační (SQL)
-| DB | Licence | Use case |
+| DB | Licence | Use case | Detail |
-|----|---------|----------|
+|----|---------|----------|--------|
-| PostgreSQL | Open source | Univerzální, geospatial, analytika |
+| **PostgreSQL** | Open source | Univerzální, geospatial, analytika, AI | [POSTGRESQL.md](POSTGRESQL.md) |
-| MySQL | Open source | Web, LAMP stack |
+| **MySQL / MariaDB** | Open source | Web, LAMP stack, e-commerce | [MYSQL.md](MYSQL.md) |
-| MariaDB | Open source | MySQL kompatibilní |
+| **Microsoft SQL Server** | Proprietary | Enterprise .NET, Windows ekosystém | — |
-| Microsoft SQL Server | Proprietary | Enterprise .NET |
+| **Oracle DB** | Proprietary | Enterprise, finance, mainframe, RAC cluster | [ORACLE.md](ORACLE.md) |
-| Oracle DB | Proprietary | Enterprise |
+| **Amazon Aurora** | Managed | MySQL/PostgreSQL kompatibilní, cloud-native | — |
 | Amazon Aurora | Managed | MySQL/PostgreSQL kompatibilní |
 ### NoSQL
-| Typ | DB | Use case |
+| Typ | DB | Use case | Detail |
-|-----|----|----------|
+|-----|----|----------|--------|
-| Document | MongoDB, Couchbase | JSON data, flexibilní schema |
+| **Document** | MongoDB, Couchbase | JSON data, flexibilní schema | [MONGODB.md](MONGODB.md) |
-| Key-Value | Redis, DynamoDB | Cache, session store, real-time |
+| **Key-Value / Cache** | Redis, Memcached, DynamoDB | Cache, session store, real-time | [REDIS.md](REDIS.md) |
-| Wide-column | Cassandra, ScyllaDB | Time-series, IoT, velká data |
+| **Wide-column** | Cassandra, ScyllaDB | Time-series, IoT, velká data | [CASSANDRA.md](CASSANDRA.md) |
-| Graph | Neo4j, Dgraph | Vztahy, doporučení, social grafy |
+| **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,60 +43,41 @@
 - **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
+### PostgreSQL vs MySQL rozdíly
 - **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 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
+## CAP teorém
 - 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
+V distribuovaném systému lze mít pouze 2 ze 3: **C**onsistency, **A**vailability, **P**artition tolerance.
-| Parametr | Popis | Výchozí |
+V praxi: P je vždy vyžadováno, volíme mezi CP (konzistence) a AP (dostupnost).
 |----------|-------|---------|
 | `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**:
+### PACELC rozšíření
 - 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
+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
-```conf
+| DB | Partition volba | Else volba |
-# postgresql.conf
+|----|----------------|------------|
-wal_level = replica                 # nebo logical
+| Cassandra | AP (dostupnost) | LC (nízká latence, eventual consistency) |
-archive_mode = on
+| DynamoDB (default) | AP | LC |
-archive_command = 'aws s3 cp %p s3://backups/pg-wal/%f'
+| MongoDB | CP (primární) | LC |
-```
+| PostgreSQL (single) | CP | CC |
 | CockroachDB | CP | CC |
- **WAL** (Write-Ahead Log) — append-only log všech změn
+### Quorum detail
 - **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
+- **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
- **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
@@ -106,56 +93,7 @@ archive_command = 'aws s3 cp %p s3://backups/pg-wal/%f'
 - **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
@@ -173,151 +111,38 @@ Distribuce dat napříč uzly podle shard klíče.
          └────────┘ └────────┘ └────────┘
 ```
-### Hash-based sharding
+### Metody
-```
+| Metoda | Popis | Výhoda | Nevýhoda |
-shard_id = hash(shard_key) % number_of_shards
+|--------|-------|--------|----------|
-```
+| **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ší |
-### Range-based sharding
+### Routing
- Data rozdělena podle rozsahu hodnot (např. uživatelé A-M, N-Z)
+- **Proxy-based** — aplikace jde na proxy, ta routuje (Vitess, ProxySQL, mongos)
 - 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:
+## Data consistency patterns
- **C**onsistency — všichni vidí stejná data
+| Pattern | Popis | Příklad |
- **A**vailability — každý request dostane odpověď
+|---------|-------|---------|
- **P**artition tolerance — systém funguje i přes výpadek komunikace
+| **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 |
-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
 | 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 (nastolit konzistenci po obnově)
 - **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 |
 ### Cache strategie
 | 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ší |
 ### Redis detail
 **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 |
 **Eviction policies**:
 | 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í |
 **Redis Cluster vs Sentinel**:
 | 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í |
 ### Connection pooling
 | 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 |
 **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)
 ## 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 |
+## SQL Antipatterns
 |---------|-------|---------|
 | **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 |
-## 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 |
+| Antipattern | Problém | Řešení |
-|-----------|--------|----------|
+|-------------|---------|--------|
-| Zápis | In-place update (náhodný I/O) | Append-only (sekvenční I/O) |
+| **Fear of JOINs** | Manuální párování v aplikaci místo JOIN | Používat JOIN správně |
-| Čtení | Rychlé (přímo v page) | Pomalejší (merge z více SSTable) |
+| **Relational Division** | Hledání množin v WHERE | Relační dělení (subquery s GROUP BY/HAVING) |
-| Kompaktnost | Horší (page fragmentation) | Lepší (kompaktní SSTable) |
+| **Pagination via OFFSET** | OFFSET je O(n) — čím větší offset, tím pomalejší | Keyset pagination (WHERE id > last_seen) |
-| Write amplification | Nižší | Vyšší (kompakce) |
+| **Non-Sargable queries** | Funkce na sloupci v WHERE (`WHERE YEAR(date) = 2026`) | Přepsat na range podmínku |
 | Read amplification | Nižší | Vyšší (bloom filtry pomáhají) |
 | Typické DB | PostgreSQL, MySQL (InnoDB) | Cassandra, RocksDB, LevelDB |
-### Write-Ahead Log (WAL)
+### Optimization antipatterns
- Append-only log pro crash recovery
+| Antipattern | Problém | Řešení |
- 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
+| **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
+| Antipattern | Problém | Řešení |
- Staré verze řádků zůstávají v tabulce (vacuum/GC)
+|-------------|---------|--------|
- Izolační úrovně: Read Committed, Repeatable Read, Serializable
+| **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*
--- a/DATABAZOVE-ENGINY.md
+++ b/DATABAZOVE-ENGINY.md
@@ -0,0 +1,101 @@
 # ⚙️ Storage enginy a transakční modely
 ## B-Tree vs LSM-Tree
 Dva dominantní storage engine přístupy v moderních databázích.
 | Vlastnost | B-Tree | LSM-Tree |
 |-----------|--------|----------|
 | **Zápis** | In-place update (náhodný I/O na page) | Append-only (sekvenční I/O) |
 | **Čtení** | Rychlé (přímo v page, O(log N)) | Pomalejší (merge z více SSTable, bloom filtry) |
 | **Write amplification** | Nižší (přepis stránky) | Vyšší (kompakce, merge SSTables) |
 | **Read amplification** | Nižší (1 page read) | Vyšší (více SSTable k prohledání) |
 | **Komprese** | Horší (fragmentace page) | Lepší (kompaktní SSTable, bloková komprese) |
 | **Range scan** | Rychlý (linked list na listové úrovni) | Rychlý (SSTable jsou seřazené) |
 | **Space amplification** | Nízká | Vyšší (čeká na kompakci) |
 | **Typické DB** | PostgreSQL, MySQL (InnoDB), SQLite, Oracle | Cassandra, RocksDB, LevelDB, ScyllaDB, MongoDB (WiredTiger) |
 ### Kdy zvolit který engine
 **B-Tree** — když:
 - Potřebujete rychlé point lookupy (PK lookup, jedinečné ID)
 - Workload je read-heavy (většina dotazů = SELECT podle klíče)
 - Potřebujete range dotazy na primárním klíči
 - Transakční workload (OLTP) s krátkými dotazy
 **LSM-Tree** — když:
 - Potřebujete vysokou propustnost zápisů (write-heavy)
 - Append-only workload (logy, time-series, IoT)
 - Komprese dat je důležitá (ušetří místo)
 - Write amplification nevadí (dostatek I/O kapacity)
 ## Write-Ahead Log (WAL)
 Append-only log garantující, že žádná operace není ztracena při crash:
 ```text
 1. Transaction BEGIN → záznam do WAL
 2. Data modification → záznam do WAL (před modifikací page)
 3. Transaction COMMIT → flush WAL na disk (COMMIT potvrzen až po flush)
 4. Checkpoint → flush dirty pages → WAL do bodu checkpointu může být smazán
 ```
 - **Write-ahead** — WAL zapsán dříve než data page
 - **Checkpoint** — bod, odkud je WAL při recovery potřeba
 - **Redo log** (InnoDB) — podobný koncept, slouží k přehrání chybějících změn
 - **Group commit** — více transakcí flushne WAL najednou (vyšší propustnost)
 ## MVCC (Multi-Version Concurrency Control)
 Každá transakce vidí snapshot dat v okamžiku startu. Staré verze řádků zůstávají v tabulce.
 ### Implementace
 | DB | Mechanismus | Vacuum/GC | Izolační úrovně |
 |----|------------|-----------|-----------------|
 | **PostgreSQL** | Heap tuple (xmin/xmax) — staré verze v hlavní tabulce | VACUUM (autovacuum) | RU, RC, RR, Serializable (SSI) |
 | **MySQL InnoDB** | Undo log — staré verze v undo segmentech | Purge (automatický) | RU, RC, RR, Serializable |
 | **MSSQL** | Tempdb version store | Automatické (row versioning) | RC (snapshot), Serializable |
 | **Oracle** | Undo tablespace | Automatické (undo retention) | RC, Serializable, Read-only |
 | **MongoDB WiredTiger** | MVCC na úrovni dokumentu | Automatické (eviction) | Snapshot isolation |
 | **Cassandra** | MVCC není (přepis valore) | Compaction (merge SSTable) | — |
 ### Anomálie
 | Úroveň | Dirty Read | Non-repeatable Read | Phantom Read | Serialization Anomaly |
 |--------|-----------|---------------------|-------------|----------------------|
 | **Read Uncommitted** | Ano | Ano | Ano | Ano |
 | **Read Committed** | Ne | Ano | Ano | Ano |
 | **Repeatable Read** | Ne | Ne | Ne (PG: ne, MySQL: next-key locking) | Ano |
 | **Serializable** | Ne | Ne | Ne | Ne |
 - **Dirty Read** — čtení dat z necommitnuté transakce
 - **Non-repeatable Read** — stejný dotaz vrátí jiná data
 - **Phantom Read** — stejný dotaz vrátí nové řádky
 - **Serialization Anomaly** — výsledek transakcí není ekvivalentní žádnému sériovému pořadí
 ## Index types
 | Typ | Algoritmus | Use case | DB podpora |
 |-----|-----------|----------|------------|
 | **B-tree** | Balanced tree | `=`, `<`, `>`, `BETWEEN`, `IN`, `LIKE (prefix)` | Všechny (výchozí) |
 | **Hash** | Hash table | Pouze `=` (equality) | PostgreSQL (hash index), MySQL (MEMORY) |
 | **GiST** | Generalized Search Tree | Geometrie, full-text, intervaly, IP rozsahy | PostgreSQL |
 | **GIN** | Generalized Inverted Index | JSONB, pole, full-text (contains, overlaps) | PostgreSQL |
 | **BRIN** | Block Range Index | Time-series, logy (data v pořadí) — extrémně malý | PostgreSQL |
 | **SP-GiST** | Space-partitioned | Kvadranty, KD-tree, radix tree | PostgreSQL |
 | **R-tree** | Prostorový strom | Geoprostorová data | MySQL (MyISAM/InnoDB), SQLite |
 | **Clustered index** | B-tree + data v listech | PK lookup (InnoDB) — data uložena s indexem | MySQL InnoDB, MSSQL |
 | **Full-text** | Inverted index | Text search (stemming, relevance) | MySQL, PostgreSQL, MSSQL |
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | Database Internals | Alex Petrov | 978-1492040346 | Hloubkový výklad storage engine (B-Tree, LSM-Tree, WAL, MVCC), distribuované systémy (partitioning, replication, consensus) |
 *Poslední revize: 2026-06-03*
--- a/DATACENTERS.md
+++ b/DATACENTERS.md
@@ -55,11 +55,71 @@ ASHRAE Technical Committee 9.9 definuje teplotní a vlhkostní obálky pro IT za
 ### Power chain
 ```
-Grid ──> UPS ──> PDU ──> Rack PDU ──> Server PSU
+Grid ──> Transformer ──> UPS ──> PDU ──> Rack PDU ──> Server PSU
                           │
-          └──> Generator (ATS přepíná při výpadku)
+                           ├──> Generator (ATS přepíná při výpadku)
                           └──> STS/ATS (Static Transfer Switch)
 ```
 A/B feed topology:
 ```
 Grid A ──> UPS A ──> PDU A1 ──> Rack PDU A ──> PSU A (server)
                                    │
 Grid B ──> UPS B ──> PDU B1 ──> Rack PDU B ──> PSU B (server)
 ```
 Každý server má 2 PSU — každá napájena z jiné větve (A/B). Při výpadku jedné větve server pokračuje bez přerušení.
 ### UPS typy
 | Klasifikace | IEC 62040-3 | Popis | Přepínání | Use case |
 |-----------|-------------|-------|-----------|----------|
 | **VFD** (Voltage & Frequency Dependent) | Passive standby | UPS v bypassu, při výpadku přepne na invertor | 4-10 ms | SOHO, edge |
 | **VI** (Voltage Independent) | Line-interactive | Regulace napětí přes autotransformátor | 2-4 ms | Menší racky, office |
 | **VFI** (Voltage & Frequency Independent) | Double-conversion | AC → DC → AC, plná izolace, žádný přepínací čas | 0 ms | Enterprise DC, Tier III/IV |
 Pro DC je standard **VFI (double-conversion)** — online UPS, nulový přepínací čas, plná izolace od sítě.
 ### Battery technologies
 | Typ | Hustota (Wh/L) | Životnost (cykly) | Životnost (roky) | Teplota | Cena/kWh | Poznámka |
 |-----|---------------|-------------------|------------------|---------|----------|----------|
 | **VRLA** (AGM/Gel) | 50-80 | 200-500 | 3-5 | 20-25 °C | ~$150-200 | Levné, velké, těžké, citlivé na teplotu |
 | **Li-ion (LFP)** | 200-350 | 3000-5000 | 10-15 | 0-40 °C | ~$300-500 | Malé, lehké, dlouhá životnost, BMS nutný |
 | **Li-ion (NMC)** | 250-400 | 1000-2000 | 8-12 | 0-40 °C | ~$250-400 | Vyšší hustota, riziko thermal runaway |
 | **NiCd** | 80-150 | 1000-2000 | 10-15 | −20-50 °C | ~$400-600 | Extrémní teploty, paměťový efekt |
 | **Flow battery** (V/Zn/Br) | 20-40 | 10,000+ | 20+ | 10-35 °C | ~$500-800 | Neomezené cykly, velké, dlouhodobé zálohování |
 Li-ion (LFP) se stává standardem pro nové DC díky delší životnosti, menšímu půdorysu a lepšímu chování při vysokých teplotách.
 ### Generator sizing
 | Varianta | Velikost | Fuel | Start time | Run time | Use case |
 |----------|---------|------|-----------|----------|----------|
 | **Diesel** | 500-2500 kVA | Diesel (Nafta) | 10-30 s | 24-72 h (dle nádrže) | Standard pro enterprise DC |
 | **Nat. gas** | 200-1500 kVA | Zemní plyn | 10-30 s | Neomezeno (plynovod) | Méně časté, nižší emise |
 | **CHP** (cogeneration) | 500-2000 kVA | Zemní plyn | 5-15 min | Neomezeno | Kombinace power + cooling (absorption chiller) |
 Sizing: Generator by měl pokrýt 100 % IT loadu + 100 % cooling loadu (vč. chillerů) — typicky 1.3-1.8× IT load. Dieselová nádrž min. na 24 h provozu, běžně 48-72 h. Denní spotřeba ~0.3-0.4 L/kWh.
 ### ATS vs STS
 | Vlastnost | ATS (Automatic Transfer Switch) | STS (Static Transfer Switch) |
 |-----------|-------------------------------|-----------------------------|
 | **Přepínání** | 4-10 ms (mechanické relé) | < 4 ms (tyristorové) |
 | **Životnost** | ~10,000 přepnutí | Neomezená (solid-state) |
 | **Cena** | Nízká | Vysoká (~3-5× ATS) |
 | **Use case** | Generátor → UPS feed | Mezi dvěma UPS výstupy |
 ### PDU typy
 | Typ | Popis | Use case |
 |-----|-------|----------|
 | **Basic** | Pasivní rozbočení (no monitoring) | Edge, office |
 | **Metered** | Měření proudu na úrovni PDU | Standard DC |
 | **Monitored** | Měření per outlet, SNMP, web GUI | Enterprise DC |
 | **Switched** | On/off per outlet, remote reboot | Enterprise DC, colo |
 | **High-density** | 3-phase, 60-100 A, C19 outlets | GPU/HPC/AI racky |
 ### Power calculation
 ```
@@ -88,6 +148,17 @@ PUE = Total Facility Energy / IT Equipment Energy
 | 1.6-2.0 | Podprůměr | Starší DC |
 | >2.0 | Špatný | Legacy |
 PUE se měří na úrovni celého DC, nikoliv per rack. Zahrnuje: UPS ztráty, chlazení, osvětlení, ztráty v rozvodu. Nezahrnuje: výrobu paliva (well-to-tank), embodied carbon. Cíl pro moderní DC: PUE < 1.2.
 ### WUE a CUE
 | Metrika | Popis | Vzorec | Cíl |
 |---------|-------|--------|-----|
 | **WUE** (Water Usage Effectiveness) | Spotřeba vody na IT energii | WUE = Annual Water Usage / IT Energy (L/kWh) | < 0.5 L/kWh |
 | **CUE** (Carbon Usage Effectiveness) | CO₂ emise na IT energii | CUE = Total CO₂ / IT Energy (kg CO₂/kWh) | < 0.2 kg CO₂/kWh |
 WUE je kritický v suchých oblastech (jihozápad USA, Austrálie, Střední východ). Adiabatické chlazení spotřebuje výrazně více vody než chlazení s uzavřeným okruhem.
 ### 3-phase vs Single-phase
 | Vlastnost | Single-phase (230 V) | 3-phase (400 V) |
@@ -97,43 +168,495 @@ PUE = Total Facility Energy / IT Equipment Energy
 | **Efektivita** | Nižší (více ztrát) | Vyšší (nižší proud) |
 | **Use case** | Menší racky, office | Standard v DC, high-density |
 | **PDU** | Single-phase (C13/C19) | 3-phase (C13/C19, 3-f monitoring) |
 | **Balancování** | Automatické | Nutné balancovat fáze (L1/L2/L3) |
 ### Rack power density
-| Kat. | Typ | kW/rack | Cooling |
+| Kat. | Typ | kW/rack | Napájení | Cooling |
-|------|-----|---------|---------|
+|------|-----|---------|----------|---------|
-| Nízká | Office, storage | 1-3 kW | Air (free cooling) |
+| Nízká | Office, storage | 1-3 kW | 1-f, 16 A | Air (free cooling) |
-| Střední | Standard compute | 5-10 kW | Air (CRAC/CRAH) |
+| Střední | Standard compute | 5-10 kW | 3-f, 32 A | Air (CRAC/CRAH) |
-| Vysoká | GPU, HPC | 15-30 kW | Air + liquid assist |
+| Vysoká | GPU, HPC | 15-30 kW | 3-f, 60 A | Air + liquid assist |
-| Ultra | AI/ML clusters | 40-100+ kW | Direct-to-chip / immersion |
+| Ultra | AI/ML clusters | 40-100+ kW | 3-f, 100+ A | Direct-to-chip / immersion |
 ### Rack PDU konektory
 | Konektor | Max proud | Typ zařízení |
 |----------|-----------|-------------|
 | **C13** | 10 A (250 V) | Servery, switche, 1U |
 | **C19** | 16 A (250 V) | Servery s vyšším výkonem, UPS |
 | **IEC 60309** (3-f) | 16-125 A | Rack PDU vstupy |
 | **NEMA L6-30** | 30 A (250 V) | US spec |
 ## Cooling
 ### Chlazení — přehled technologií
 | Technologie | Typ | Výkon (kW/rack) | PUE typický | CAPEX | Use case |
 |-----------|------|----------------|-------------|-------|----------|
 | **Free air cooling** | Air | < 5 | 1.05-1.15 | Nízký | Klimaticky vhodné lokality |
 | **CRAC (DX)** | Air | 5-10 | 1.4-1.8 | Střední | Menší DC, retrofit |
 | **CRAH (CW)** | Air | 5-15 | 1.2-1.5 | Vysoký | Enterprise DC |
 | **In-row cooling** | Air | 10-25 | 1.2-1.4 | Vysoký | High-density racky |
 | **Rear-door HX** | Hybrid | 15-30 | 1.1-1.3 | Střední | Retrofity, GPU |
 | **Direct-to-chip** | Liquid | 40-100+ | 1.05-1.15 | Vysoký | AI/ML, HPC |
 | **Immersion (single-phase)** | Liquid | 50-100+ | 1.03-1.10 | Vysoký | Bitcoin, hyperscale |
 | **Immersion (two-phase)** | Liquid | 100-200+ | 1.03-1.08 | Velmi vysoký | Extreme density |
 ### Chilled water vs Direct Expansion (DX)
 | Vlastnost | Chilled water (CW) | Direct Expansion (DX) |
 |-----------|-------------------|----------------------|
-| **Medium** | Voda + glycol | Freon (R134a, R410A) |
+| **Medium** | Voda + glycol | Freon (R134a, R410A, R454B) |
 | **CRAC/CRAH** | CRAH (Coolant-based) | CRAC (refrigerant compressor) |
 | **Efektivita** | Vyšší (COP 5-7) | Nižší (COP 2-4) |
-| **Komplexita** | Vyšší (chillers, pumps, pipes) | Jednodušší |
+| **Teplota vody** | 7-12 °C (standard), 18-22 °C (high-temp) | −5-10 °C (evaporator) |
-| **Use case** | Velké DC, enterprise | Menší DC, edge, retrofit |
+| **Komplexita** | Vyšší (chillers, pumps, pipes, cooling tower) | Jednodušší |
 | **Údržba** | Vyšší (vodní úprava, prevence legionely) | Nižší |
 | **Use case** | Velké DC > 500 kW, enterprise | Menší DC, edge, retrofit |
 ### Containment typy
 | Typ | Popis | Efektivita | Implementace |
 |-----|-------|-----------|-------------|
 | **Cold aisle containment (CAC)** | Uzavřená studená ulička, teplý vzduch se vrací do místnosti | Vysoká | Dveře na koncích uličky, stropní panely |
 | **Hot aisle containment (HAC)** | Uzavřená teplá ulička, teplý vzduch jde přímo do zpátečky | Vyšší | Dveře + stropní panely, zpátečka do CRAH |
 | **Chimney / rear duct** | Každý rack má vlastní výfukový komín do stropu | Nejvyšší | Samostatné ducty per rack, nákladné |
 | **Open aisle** | Bez containmentu, studený a teplý vzduch se mísí | Nízká | Legacy, levné |
 Doporučení: CAC/HAC při hustotě > 5 kW/rack. HAC je o 5-10 % efektivnější než CAC (teplý vzduch je přímo odváděn, nemísí se s místností).
 ### CFD modeling
 Computational Fluid Dynamics (CFD) simuluje proudění vzduchu v DC před fyzickou implementací:
 - Identifikace hot spots (recirkulace teplého vzduchu do studené uličky)
 - Optimalizace pozice perforovaných dlaždic
 - Návrh bypass airflow (kabelové otvory, nezakryté pozice)
 - Simulace výpadku CRAH jednotky (what-if scénáře)
 - Nástroje: Future Facilities (6Sigma DC), Ansys Fluent, OpenFOAM
 ### Free cooling
 - **Air-side** — nasávání venkovního vzduchu při vhodné teplotě (filtrace, humidifikace)
- **Water-side** — využití chladné vody z venkovních chillerů (strainer cycle)
+- **Water-side** — využití chladné vody z venkovních chillerů (strainer cycle) bez kompresoru
 - **Klimatické pásmo** — free cooling využitelný ~2000-8000 hodin/rok podle lokality
- **Hybrid** — kombinace free cooling + mechanical cooling
+  - Skandinávie: 7000-8000 h/rok
  - Střední Evropa: 4000-6000 h/rok
  - Jižní Evropa: 2000-4000 h/rok
 - **Hybrid** — kombinace free cooling + mechanical cooling (nejběžnější)
 - **Economizer types**: Class A1 (dry cooler), Class A2 (evaporative), Class B (air-side)
-### Liquid cooling
+### Liquid cooling detail
-| Typ | Popis | Use case |
+| Typ | Teplota vstupu | Kapacita (kW/rack) | Medium | Instalace |
-|-----|-------|----------|
+|-----|---------------|-------------------|--------|-----------|
-| **Direct-to-chip (cold plate)** | Kapalina na chladiči CPU/GPU, voda nebo dielektrikum | AI/ML, HPC, GPU clustery |
+| **Cold plate (D2C)** | 20-45 °C | 40-100+ | Voda, propylenglykol | CDU per rack nebo per row |
-| **Immersion cooling** | Server ponořen v dielektrické kapalině (single-phase/two-phase) | High-density, bitcoin mining |
+| **Rear-door HX** | 18-27 °C | 15-30 | Voda | Pasivní, bez úpravy serveru |
-| **Rear-door heat exchanger** | Chladič na zadních dveřích racku (voda) | Retrofity, medium-density |
+| **Immersion (1-f)** | 35-50 °C | 50-100+ | Dielektrický olej | Nádrž, CDU, heat exchanger |
-| **Coolant Distribution Unit (CDU)** | Distribuce chladiva mezi racky, monitoring teploty | Standard pro liquid cooling |
+| **Immersion (2-f)** | 25-35 °C | 100-200+ | Dielektrikum (var) | Nádrž + kondenzátor |
 **CDU (Coolant Distribution Unit)**:
 - Zajišťuje teplotu a tlak chladiva do racků
 - Primární okruh (facility water) + sekundární okruh (rack coolant)
 - Dimenzování: 1 CDU na 4-8 racků (40-100 kW per CDU)
 - Redundance: N+1 CDU, dual coolant loops
 **Water quality requirements**:
 - Vodivost: < 1 µS/cm (demineralizovaná voda)
 - pH: 6.5-8.0
 - Částice: < 50 µm (filtrace)
 - Prevence koroze: inhibitory, glykol (10-30 %)
 - Prevence biologického růstu: UV, biocidy
 ### Adiabatic cooling
 Využití odpařování vody pro ochlazení vzduchu:
 - **Direct adiabatic** — vzduch prochází vodou (media pad), ochlazuje se a zvlhčuje
 - **Indirect adiabatic** — vzduch se ochlazuje přes heat exchanger bez přímého kontaktu s vodou
 - **Spotřeba vody**: 3-5 L/kWh (direct), 1-2 L/kWh (indirect)
 - Účinnost závisí na vlhkosti vzduchu — v suchém klimatu efektivnější
 ## Kabeláž a structured cabling
 ### TIA-942 cabling hierarchy
 ```
 Entrance Room (ER)
    │
    ├── Backbone cabling (fiber single-mode / multi-mode)
    │       │
    │       ├── Main Distribution Area (MDA)
    │       │       │
    │       │       ├── Horizontal Distribution Area (HDA)
    │       │       │       │
    │       │       │       └── Equipment Distribution Area (EDA) → rack
    │       │       │
    │       │       └── Intermediate Distribution Area (IDA) — volitelný
    │       │
    │       └── Telecommunication Room (TR) — pro office
    │
    └── Backbone cabling (fiber / copper)
 ```
 ### Copper cabling categories
 | Kategorie | Frekvence | Rychlost | Délka | Konektor | Use case |
 |-----------|----------|----------|-------|----------|----------|
 | **Cat5e** | 100 MHz | 1 GbE | 100 m | RJ45 | Legacy, voice |
 | **Cat6** | 250 MHz | 1 GbE (10 GbE do 55 m) | 100 m (10 GbE: 55 m) | RJ45 | Běžné DC, enterprise |
 | **Cat6A** | 500 MHz | 10 GbE | 100 m | RJ45 | Standard pro nové DC |
 | **Cat7** (GG45) | 600 MHz | 10 GbE | 100 m | GG45/TERA | Niche, nahrazen Cat6A/8 |
 | **Cat8.1** | 2000 MHz | 25/40 GbE | 30 m | RJ45 | Top-of-rack, storage |
 | **Cat8.2** | 2000 MHz | 25/40 GbE | 30 m | GG45/TERA | Top-of-rack, storage |
 V DC se standardně používá **Cat6A** (10 GbE do 100 m) pro horizontální rozvody. Cat8 pouze pro propojky v rámci racku (do 30 m).
 ### Fiber optic typy
 | Typ | Core | Modal BW | Rychlost | Max délka | Use case |
 |-----|------|----------|----------|-----------|----------|
 | **OS1** (SM) | 9 µm | — | 100 GbE - 800 GbE | 10-80 km | Backbone, campus, WAN |
 | **OS2** (SM) | 9 µm | — | 100 GbE - 800 GbE | 2-80 km (CWDM/DWDM) | Backbone, DWDM |
 | **OM1** (MM) | 62.5 µm | 200 MHz·km | 1 GbE | 275 m | Legacy |
 | **OM2** (MM) | 50 µm | 500 MHz·km | 10 GbE | 82 m | Legacy |
 | **OM3** (MM) | 50 µm | 2000 MHz·km | 10 GbE do 300 m, 100 GbE do 100 m | 300 m (10G) | Standard DC, VCSEL |
 | **OM4** (MM) | 50 µm | 4700 MHz·km | 100 GbE do 150 m, 400 GbE do 100 m | 550 m (10G) | Výkonný standard DC |
 | **OM5** (MM) | 50 µm | 4700+ MHz·km | 200/400 GbE SWDM | 150 m (100G) | Emerging, SWDM |
 Pro nové DC: **OM4** jako standard pro multi-mode, **OS2** pro single-mode backbone (LR, DWDM). OM5 není široce nasazen — OM4 + paralelní optika (SR4) je běžnější.
 ### Connector types
 | Konektor | Typ | Insertion loss | Počet vláken | Use case |
 |----------|-----|---------------|-------------|----------|
 | **LC** | Duplex | < 0.15 dB | 2 | Standard pro SFP/SFP+/QSFP |
 | **SC** | Duplex | < 0.2 dB | 2 | Starší instalace, patch panely |
 | **MPO/MTP** (12-f) | Multi-fiber | < 0.35 dB | 12/24 | 40/100/400 GbE paralelní |
 | **MPO/MTP** (24-f) | Multi-fiber | < 0.5 dB | 24 | 400 GbE (SR4.2, DR4) |
 | **SN** | Duplex (mini) | < 0.15 dB | 2 | High-density (QSFP-DD, OSFP) |
 | **CS** | Duplex (mini) | < 0.15 dB | 2 | High-density (QSFP-DD, OSFP) |
 ### MPO/MTP polarity
 | Metoda | Popis | Use case |
 |--------|-------|----------|
 | **Type A** (Straight) | Vlákno 1→1, 2→2, ... | Duplex aplikace s cross-over na obou koncích |
 | **Type B** (Crossed) | Vlákno 1→12, 2→11, ... | Paralelní optika (SR4, SR8) — standard |
 | **Type C** (Pairs crossed) | Páry 1-2→2-1, 3-4→4-3 | 40 GbE SR4 (4×10G) |
 ### Breakout kazety
 ```
 MPO (12-f) ──> Breakout kazeta ──> 6× LC duplex (12 vláken = 6× duplex)
 MPO (24-f) ──> Breakout kazeta ──> 12× LC duplex (24 vláken = 12× duplex)
 ```
 Use case: Propojení MPO portu (switch) s LC porty (servery, storage). Kazety jsou v patch panelu, ne v aktivní cestě.
 ### Copper vs fiber decision
 | Kritérium | Copper (Cat6A/8) | Fiber (OM4/OS2) |
 |-----------|-----------------|-----------------|
 | **Dosah** | 30-100 m | 100 m - 80 km |
 | **Rychlost** | 1-40 GbE | 1-800 GbE |
 | **Cena transceiveru** | Nižší (RJ45) | Vyšší (SFP+/QSFP) |
 | **Cena kabelu** | Nižší | Vyšší (patch cord) |
 | **Spotřeba portu** | 2-5 W (25 GbE) | 1-3 W (25 GbE SR) |
 | **Elektromagnetické rušení** | Citlivý | Imunní |
 | **Váha (100 m)** | ~3-4 kg | ~0.5-1 kg |
 | **Doporučení** | Do 30 m, server→ToR switch | Backbone, storage, >30 m |
 ### Cabling best practices
 - **Horizontal cabling**: max 90 m permanent link + 10 m patch cords (TIA-942)
 - **Fiber management**: slack spools, cable managers, minimální poloměr ohybu 10× průměr kabelu
 - **Color coding**: OS1/OS2 (yellow), OM3 (aqua), OM4 (magenta/purple), OM5 (lime green)
 - **Labeling**: oba konce, patch panely, faceplates — standard ANSI/TIA-606-B
 - **Overhead vs underfloor**: overhead (ladder rack) je preferován v DC (lepší airflow, jednodušší změny)
 - **MPO cassettes**: plánovat 15-20 % rezervu vláken pro budoucí potřeby
 ## Fyzická bezpečnost
 ### Multi-layer security model (defense in depth)
 ```
 Layer 1: Perimeter (plot, brána, stráže)
 Layer 2: Building (zdi, zámky, CCTV, čtečky karet)
 Layer 3: DC hall (biometrie, mantrap, CCTV, detekce pohybu)
 Layer 4: Rack / Cage (elektronické zámky, senzory)
 Layer 5: Data (šifrování, HSM, access control)
 ```
 ### Access control
 | Metoda | Faktor | Úroveň | Poznámka |
 |--------|--------|--------|----------|
 | **RFID / proximity card** | Něco, co máte | Standard | Základní přístup, levné |
 | **Smart card (PKI)** | Něco, co máte + PIN | Střední | Certifikát na kartě, anti-passback |
 | **Biometric (fingerprint)** | Něco, co jste | Vysoká | Rychlý, hygienický (čtečky bez dotyku) |
 | **Biometric (palm/finger vein)** | Něco, co jste | Velmi vysoká | Těžko falšovatelný, bezkontaktní |
 | **Biometric (iris/retina)** | Něco, co jste | Nejvyšší | Velmi přesný, pomalý, drahý |
 | **Multi-factor** | 2+ faktory | Nejvyšší | Karta + biometrie + PIN — Tier IV DC |
 ### Mantrap design
 ```
 Vnější dveře ──> Mantrap (prostor) ──> Vnitřní dveře
                     │
                     ├── Weight sensor (anti-tailgating)
                     ├── CCTV (obě dveře)
                     ├── Intercom (nouzový východ)
                     └── Motion detector (v mantrapu)
 ```
 - Otevírá se vždy jen jedny dveře
 - Anti-tailgating: váhový senzor detekuje více osob
 - Výstup (exit) přes breakout button + detekce pohybu
 - Nouzový východ: panic bar + alarm
 ### CCTV
 | Prvek | Doporučení |
 |-------|-----------|
 | **Rozlišení** | Min. 1080p, ideálně 4K (6 MP+) |
 | **FPS** | 15-30 FPS (záznam), 30+ FPS (realtime monitoring) |
 | **Retence** | Min. 30 dní (90 dní pro audit) |
 | **Storage** | NVR (on-prem), cloud (AWS KVS, Azure Video Indexer) |
 | **AI analytics** | Detekce obličeje, ANPR (poznávací značky), object detection |
 | **Zorné pole** | Každé dveře, každá ulička — bez slepých míst |
 ### Asset tracking
 | Technologie | Přesnost | Cena | Use case |
 |-----------|----------|------|----------|
 | **Barcode** | Rack-level | Velmi nízká | Manuální inventura |
 | **RFID (passive)** | Rack-level (door sweep) | Nízká | Automatická detekce otevření racku |
 | **RFID (active, UWB)** | 10-30 cm | Střední | Real-time tracking v reálném čase |
 | **Bluetooth BLE** | 1-3 m | Nízká | Orientační pozice |
 | **GPS** | 1-10 m | Střední | Venkovní tracking |
 ## DC layout a design
 ### Raised floor vs Slab
 | Vlastnost | Raised floor | Slab (pevná podlaha) |
 |-----------|-------------|----------------------|
 | **Airflow** | Underfloor air distribution (zvednutá podlaha jako plénum) | Overhead air, in-row cooling |
 | **Flexibilita** | Snadné přidání perforovaných dlaždic | Omezené (nutné overhead cooling) |
 | **Hmotnost** | Limit 500-1000 kg/m² (závisí na výšce) | Neomezené |
 | **Cena** | Vyšší (~$200-400/m²) | Nižší (~$100-200/m²) |
 | **Výška** | 600-900 mm (standard), 900-1200 mm (high-density) | — |
 | **Trend** | Klesající (přechod na in-row/overhead cooling) | Rostoucí (nové DC, high-density) |
 Moderní high-density DC (AI/ML, GPU) se odklánějí od raised floor k slab + overhead/in-row cooling — vyšší hmotnost racků (1000-2000 kg), nemožnost dostatečného airflow podlahou.
 ### Rack layout a rozměry
 | Parametr | Standard | High-density | Poznámka |
 |----------|----------|-------------|----------|
 | **Rack šířka** | 600 mm (19") | 600-750 mm | 750 mm pro GPU (kabeláž, chlazení) |
 | **Rack hloubka** | 1000-1200 mm | 1200-1500 mm | GPU servery, delší kabely |
 | **Rack výška** | 42U | 48U / 52U | Vyšší rack = lepší power density |
 | **Ulička šířka (studená)** | 1200-1500 mm | 1500-1800 mm | Servisní přístup, airflow |
 | **Ulička šířka (teplá)** | 900-1200 mm | 1200-1500 mm | Užší než studená |
 | **Max zatížení racku** | 500-800 kg | 1000-2000 kg | Nutné podlahové nosníky |
 ### Space planning
 ```
 Pro Tier III DC (příklad):
  IT prostor: 1000 m²
    └── 20 řad × 10 racků = 200 racků při 42U
    └── 200 racků × 5 kW avg = 1 MW IT load
    └── PUE 1.4 → 1.4 MW facility
  Podpůrné prostory:
    └── UPS + baterie: 200 m²
    └── Generátory: 100 m² (venkovní)
    └── Chlazení (chillery, cooling tower): 300 m²
    └── Kanceláře, sklady, loading dock: 400 m²
  Celkem: ~2000 m² (50% IT, 50% support)
 ```
 ### Zone approach (TIA-942)
 | Zóna | Popis | Přístup | Security |
 |------|-------|---------|----------|
 | **Z1** (Veřejná) | Recepce, kanceláře | Volný | Minimální |
 | **Z2** (Kancelářská) | Administrativa, NOC | Zaměstnanci + hosté | RFID |
 | **Z3** (DC support) | UPS, generátory, chlazení | DC operátoři | RFID + biometrie |
 | **Z4** (DC hall) | Servery, storage, networking | DC operátoři + schválení | RFID + biometrie + mantrap |
 | **Z5** (Rack/cage) | Konkrétní rack nebo cage | Pouze oprávněný personál | Elektronický zámek |
 ## Fire suppression
 ### Detekce
 | Systém | Typ | Doba detekce | Falešné poplachy | Use case |
 |--------|-----|-------------|------------------|----------|
 | **VESDA** (Very Early Smoke Detection) | Aspirační, laserové čidlo | < 30 s (4 stupně alarmu) | Velmi nízké | Standard pro DC |
 | **Spot detection** | Ionizační / optický kouřový detektor | 2-5 min | Střední | Legacy, menší DC |
 | **Heat detection** | Tepelný detektor (teplota / rychlost nárůstu) | 5-10 min | Velmi nízké | Záloha za VESDA |
 | **Line-type (LHD)** | Lineární tepelný kabel | 2-5 min | Nízké | Cable trays, nad stropem |
 VESDA je standard — aktivní aspirace nasává vzduch z DC, laserové čidlo detekuje částice kouře ve 4 úrovních (Alert → Action → Fire 1 → Fire 2). Umožňuje zásah ještě před viditelným kouřem.
 ### Suppression systémy
 | Systém | Medium | Výhody | Nevýhody | Typ DC |
 |--------|--------|--------|----------|--------|
 | **Novec 1230** (FK-5-1-12) | Plyn | Bezpečný pro lidi, nulový ODP, krátký atmospheric lifetime (5 dní) | Vyšší cena | Enterprise DC |
 | **FM-200** (HFC-227ea) | Plyn | Rychlý (10 s), účinný | Vysoký GWP (3220), ODP nemá | Legacy DC |
 | **Inergen** (IG-541) | Inertní plyn (52% N₂, 40% Ar, 8% CO₂) | Zcela bezpečný, přírodní plyn | Velké množství (objem), vysoký tlak | Enterprise DC |
 | **Argonite** (IG-55) | 50% Ar, 50% N₂ | Bezpečný, přírodní | Velké množství, vyšší tlak | Enterprise DC |
 | **Water mist** | Voda (jemná mlha) | Chlazení, potlačení kouře, nízká cena | Voda v DC (riziko), jen local application | Retrofity |
 | **Pre-action sprinkler** | Voda | Dvojí spuštění (detekce + sprinkler) | Riziko vody, nutné odvodnění | Tier I-II |
 **Koncentrace**: Novec (4-6 % objemu), FM-200 (7-9 %), Inergen (35-50 %). Novec a Inergen jsou bezpečné pro dýchání (min. 5-7 min evakuace).
 ### Detekční zóny
 ```
 DC hall ──> zóny po ~200 m² (max)
               │
               ├── VESDA (každá zóna vlastní aspirátor)
               ├── Kouřové detektory (podhled + podlaha)
               └── Heat detection (záložní)
 ```
 ## DCIM (Data Center Infrastructure Management)
 ### Co DCIM pokrývá
 | Oblast | Metriky | Výstup |
 |--------|---------|--------|
 | **Power** | Per PDU, per outlet, per rack, celkem | Capacity planning, PUE, kW/rack |
 | **Cooling** | Teplota, vlhkost, airflow (senzory per rack) | Hot spot mapy, airflow optimalizace |
 | **Asset** | Co je v kterém racku, U pozice, serial, warranty | Asset inventory, lease management |
 | **Network** | Port utilization, patch panel propojení | Patch management, port tracking |
 | **Space** | Volné U v racku, volné racky | Capacity planning, "what-if" simulace |
 ### Nástroje
 | Nástroj | Typ | Platforma | Cena | Poznámka |
 |---------|-----|-----------|------|----------|
 | **Nlyte (Carrier)** | Enterprise DCIM | On-prem / Cloud | $$$ | Tržní leader, complex |
 | **Sunbird DCIM** | Enterprise DCIM | Cloud | $$$ | Power monitoring, asset tracking |
 | **Device42** | DCIM + IPAM | On-prem / Cloud | $$ | Integrovaný IPAM, CMDB |
 | **NetBox** | Open source DCIM | On-prem | Zdarma | IPAM, DCIM, asset tracking |
 | **OpenDCIM** | Open source | On-prem | Zdarma | Základní DCIM, asset management |
 | **RackTables** | Open source | On-prem | Zdarma | Jednoduchý, asset + networking |
 | **Vendor-specific** | Dell OME, HPE OneView | On-prem | Součást hw | Pouze daný vendor |
 ## Site selection
 ### Kritéria pro výběr lokality DC
 | Kategorie | Kritérium | Váha |
 |-----------|-----------|------|
 | **Power** | Dostupnost elektřiny (grid capacity), cena/kWh, možnost dvou nezávislých přívodů | Vysoká |
 | **Connectivity** | Dostupnost fiber backbone, počet poskytovatelů konektivity, latency k major POP | Vysoká |
 | **Přírodní rizika** | Zemětřesení, povodně, hurikány, tornáda, lesní požáry — historická data + predikce | Vysoká |
 | **Klima** | Průměrná teplota, vlhkost (free cooling potenciál) | Střední |
 | **Pracovní síla** | Dostupnost techniků, DC operátorů, network/admin inženýrů | Střední |
 | **Daně a regulace** | Daňové pobídky, environmental regulations, stavební povolení | Střední |
 | **Bezpečnost** | Kriminalita, politická stabilita, teroristické riziko | Vysoká |
 | **Dopravní dostupnost** | Blízkost letiště, dálnice (pro dodávky HW, personál) | Nízká |
 ### Přírodní rizika — mapování
 | Riziko | Oblasti | Mitigace |
 |--------|---------|----------|
 | **Zemětřesení** | Pacific Ring of Fire (CA, Japonsko, Chile) | Base isolation, seismic bracing, flexibilní propojení |
 | **Hurikány** | Karibik, jihovýchod USA, jihovýchodní Asie | Zesílená konstrukce, generátory nad úrovní záplav |
 | **Povodně** | Říční údolí, pobřežní oblasti | Umístění mimo záplavovou zónu, bariéry |
 | **Lesní požáry** | Kalifornie, Austrálie, Středomoří | Defenzivní zóny, filtrace vzduchu, monitoring |
 ### Power availability po regionech
 | Region | Grid reliability | Cena/kWh (industriální) | Poznámka |
 |--------|-----------------|------------------------|----------|
 | **Severní Evropa** (SE, NO, FI) | Vysoká (99.99 %) | $0.04-0.08 | Levná zelená energie, chladné klima |
 | **Střední Evropa** (DE, NL, CZ) | Vysoká (99.99 %) | $0.10-0.20 | Stabilní, renewables rostou |
 | **Východní USA** (VA, NC) | Vysoká | $0.05-0.08 | Největší DC hub (Ashburn, VA) |
 | **Západní USA** (CA, OR) | Střední (PG&E issues) | $0.10-0.15 | CALISO grid, blackout risk |
 | **Singapur** | Vysoká | $0.15-0.20 | Moratorium na nová DC (2023), voda |
 | **Dubai / UAE** | Vysoká | $0.06-0.10 | Levná energie, vysoká teplota (cooling) |
 ## Compliance a certifikace
 | Standard / Certifikace | Oblast | Popis |
 |----------------------|--------|-------|
 | **TIA-942** (Rated 1-4) | DC design | Klasifikace redundance, kabeláže, bezpečnosti (analogický k Uptime Tier) |
 | **Uptime Institute** (Tier I-IV) | DC design | Provozní certifikace, konstrukční dokumentace |
 | **ISO 27001** | ISMS | Informační bezpečnost, řízení rizik |
 | **ISO 27701** | Privacy | Rozšíření ISO 27001 pro GDPR compliance |
 | **SOC 2** (Type I/II) | Service org | Controls: Security, Availability, Confidentiality, Integrity, Privacy |
 | **PCI DSS** | Platební karty | Fyzická bezpečnost, přístup k cardholder data |
 | **HIPAA** | Zdravotnictví | USA, ochrana zdravotních dat |
 | **FedRAMP** | US government | Cloud service authorization, DC security |
 | **GDPR** | EU | Ochrana osobních údajů, data residency |
 | **NIST SP 800-53** | DC security | Security control catalog pro US federal |
 | **ISO 14001** | EMS | Environmental management, sustainability |
 ## Sustainability
 ### Uhlíková stopa DC
 ```
 Celkové emise = Scope 1 (přímé) + Scope 2 (energie) + Scope 3 (dodavatelský řetězec)
  Scope 1: Generátory (diesel), úniky chladiva
  Scope 2: Nakoupená elektřina (grid mix)
  Scope 3: Výroba HW, transport, EOL recyklace (~60-80 % celkových emisí)
 ```
 ### Redukce emisí
 | Opatření | Dopad na PUE | Snížení emisí | Návratnost |
 |----------|-------------|---------------|------------|
 | **Zvýšení teploty** (22→27 °C) | −0.1-0.2 | 10-20 % chlazení | Ihned |
 | **Free cooling** | −0.1-0.3 | 20-40 % chlazení | 1-2 roky |
 | **Liquid cooling** | −0.2-0.4 | 30-50 % chlazení | 2-4 roky |
 | **LED osvětlení + senzory** | −0.01-0.02 | < 1 % | 1 rok |
 | **PPA (Power Purchase Agreement)** | — | 100 % Scope 2 | Variabilní |
 | **Obnovitelné zdroje** (solární na střeše) | — | 5-15 % spotřeby | 5-10 let |
 | **Zelený generátor** (HVO biodiesel) | — | 90 % CO₂ redukce | +30 % fuel cost |
 ### Certifikace udržitelnosti
 | Certifikace | Popis |
 |-----------|-------|
 | **LEED** (BD+C: DC) | U.S. Green Building Council — design a konstrukce |
 | **BREEAM** | UK, European sustainability assessment |
 | **Climate Neutral Data Centre Pact** (EU) | Self-regulatory, PUE < 1.4 do 2030 |
 | **ISO 50001** | Energy management system |
 | **Energy Star** | EPA, energetická účinnost (jen US) |
 ## Decision diagram — návrh DC topologie
 ```mermaid
 flowchart TD
    Start(["DC design"]) --> TIER{"Požadovaný Tier?"}
    TIER -->|"Tier I / II"| T1["N / N+1 redundance<br/>Jednoduché napájení, single path<br/>CRAC/CRAH, free cooling<br/>PUE 1.4-1.6, cena 1×"]
    TIER -->|"Tier III"| T3["N+1, současně udržovatelné<br/>Dual path (A/B feed)<br/>Hot aisle containment<br/>PUE 1.2-1.4, cena 2×"]
    TIER -->|"Tier IV"| T4["2N+1, fault tolerant<br/>Dual redundant + STS<br/>Hot + cold containment<br/>PUE 1.1-1.3, cena 3×"]
    TIER --> POWER{"Power chain"}
    POWER -->|"UPS"| UPS{"UPS typ"}
    UPS -->|"Enterprise DC"| UPS1["VFI double-conversion<br/>Li-ion (LFP), 10-15 let<br/>N+1 nebo 2N modulární"]
    UPS -->|"Edge / office"| UPS2["VI line-interactive<br/>VRLA, 3-5 let"]
    POWER -->|"Generátor"| GEN["Diesel 500-2500 kVA<br/>Nádrž na 24-72 h<br/>ATS 4-10 ms přepnutí"]
    POWER -->|"PDU"| PDU["3-phase 400 V<br/>Monitored/Switched<br/>A/B feed do racků"]
    Start --> DENS{"Hustota výkonu"}
    DENS -->|"< 10 kW/rack"| COOL1["Air cooling<br/>CRAC/CRAH, raised floor<br/>Hot aisle containment<br/>ASHRAE A1-A2"]
    DENS -->|"10-25 kW/rack"| COOL2["Hybrid<br/>In-row cooling<br/>Rear door HX<br/>ASHRAE A1-H1"]
    DENS -->|"> 25 kW/rack"| COOL3["Liquid cooling<br/>CDU, direct-to-chip<br/>Immersion single/two-phase<br/>ASHRAE W-třídy"]
    Start --> CLIM{"Klimatická zóna"}
    CLIM -->|"Mírná (ČR, DE)"| FC1["Free cooling 4000-6000 h/rok<br/>Chiller + economizer<br/>PUE saving 0.2-0.3"]
    CLIM -->|"Teplá (ES, US South)"| FC2["Chiller celoročně<br/>Adiabatic cooling<br/>PUE 1.3-1.6"]
    CLIM -->|"Chladná (SE, NO)"| FC3["Free cooling 7000+ h/rok<br/>Air-side economizer<br/>PUE < 1.2"]
 ```
 ## Monitoring disků — S.M.A.R.T.
@@ -153,3 +676,12 @@ Nástroje: `smartmontools` (smartctl, smartd), Prometheus exporter (`node_export
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | The Data Center as a Computer (4th ed., 2025) | Barroso, Hölzle, Ranganathan | 978-3-031-99488-3 | Komplexní vývoj designu warehouse-scale computer (WSC) od Google architektů. Pokrývá hardware, software, power, cooling, networking a 25 let zkušeností s WSC. Klíčová publikace pro architekturu datových center. |
 | Electronics Cooling: From the Chip to the Datacenter (Vol. 62) | Abraham et al. | 978-0-443-47084-4 | Praktický průvodce tepelným managementem od úrovně tranzistoru po datové centrum. Zahrnuje conduction, convection, liquid immersion a phase change cooling. Nezbytný zdroj pro návrh chlazení DC. |
 *Poslední revize: 2026-06-03*
--- a/GPU.md
+++ b/GPU.md
@@ -124,3 +124,5 @@ NVLink topologie (GPU direct)   PCIe topologie (CPU mediated)
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 *Poslední revize: 2026-06-03*
--- a/HARDWARE.md
+++ b/HARDWARE.md
@@ -8,3 +8,5 @@ Tento soubor byl rozdělen do samostatných oblastí:
 | 🎮 GPU — architektura, modely, virtualizace | [GPU.md](GPU.md) |
 | ⚙️ Server configuration — best practices podle workloadu | [SERVER-CONFIG.md](SERVER-CONFIG.md) |
 | 📦 Provisioning — boot, instalace, správa serverů | [PROVISIONING.md](PROVISIONING.md) |
 *Poslední revize: 2026-06-03*
--- a/HYPERVISORS.md
+++ b/HYPERVISORS.md
@@ -11,7 +11,7 @@
 | Platforma | Hypervisor | Licence | Poznámka |
 |-----------|-----------|---------|----------|
-| **VMware vSphere** | ESXi | Proprietary (Subscription od 2024) | Tržní lídr, široká adopce |
+| **VMware vSphere** | ESXi | Proprietary (Subscription od 2024) | Tržní lídr, široká adopce. Po akvizici Broadcomem (2023) přešlo na per-core subscription, ukončen perpetual license |
 | **Microsoft Hyper-V** | Hyper-V | Windows Server / standalone | Integrace s Azure, SCVMM |
 | **Proxmox VE** | KVM + LXC | Open source | Debian-based, web UI, levný |
 | **Red Hat OpenStack / oVirt** | KVM | Open source | Otevřená alternativa, komplexní |
@@ -24,7 +24,7 @@
 - **VM — Virtual Machine** — plná virtualizace, vlastní kernel
 - **Container** — sdílený kernel hostitele, lehčí (Docker, LXC)
 - **Paravirtualizace** — guest OS ví, že běží ve VM (lepší výkon I/O)
- **NUMA** — Non-Uniform Memory Access, optimalizace přidělování CPU/memory (viz [HARDWARE.md](HARDWARE.md#memory-a-numa))
+- **NUMA** — Non-Uniform Memory Access, optimalizace přidělování CPU/memory (viz [SERVER-HW.md](SERVER-HW.md#numa))
 - **Overcommit** — přidělení více vCPU/RAM než je fyzicky (řízení poměru)
 - **Live Migration** — přesun běžící VM mezi hosty (vSphere vMotion, Hyper-V Live Migration)
 - **HA (High Availability)** — restart VM na jiném hostu při selhání
@@ -32,9 +32,37 @@
 ## VMware vSphere
 ### VMware licensing (post-Broadcom 2024+)
 Od roku 2024 VMware prodává pouze subscription license, perpetual + SnS (Support & Subscription) byly ukončeny.
 | Produkt | Metrika | Cena (orientační) | Co obsahuje |
 |---------|---------|-------------------|-------------|
 | **vSphere Standard** | Per core (min 16 cores/CPU) | ~$140/core/rok | ESXi, vCenter, vMotion, HA, DRS basic |
 | **vSphere Enterprise Plus** | Per core | ~$220/core/rok | Vše výše + DRS advanced, SIOC, NIOC, Big Data Extensions |
 | **vSphere Foundation** | Per core (balíček) | ~$350/core/rok | VSphere Enterprise Plus + Aria Operations, Aria Operations for Logs, Aria Automation |
 | **VMware Cloud Foundation (VCF)** | Per core (balíček) | ~$700/core/rok | VSphere + vSAN + NSX + Aria celá sada. Vyžadováno pro vSAN a NSX od 2025 |
 | **vSAN** | Per core (pouze jako součást VCF od 2025) | Již není standalone | Storage virtualization, dedup, compression, encryption |
 | **NSX** | Per core (pouze jako součást VCF od 2025) | Již není standalone | SDN, micro-segmentace, firewall, load balancing |
 **Klíčové změny po Broadcom akvizici**:
 - Ukončen prodej perpetual licencí (květen 2024)
 - Ukončeny samostatné produkty: vSAN a NSX již nelze koupit standalone (pouze v rámci VCF)
 - Zrušeny desktopové a ROBO varianty (migrováno na VCF)
 - Průměrný nárůst nákladů: 2-5× oproti předchozímu modelu (závisí na velikosti a produktovém mixu)
 - **Dopad**: Mnoho zákazníků migruje na Proxmox VE, Nutanix AHV nebo Hyper-V
 **Per-core kalkulace**:
 ```text
 Server: 2× EPYC 9654 (96C each) = 192 cores
  vSphere Standard: 192 × $140 = $26 880/rok
  VCF: 192 × $700 = $134 400/rok (vč. vSAN a NSX)
 Pro srovnání: dříve perpetual + SnS ≈ $15 000 jednorázově + $3 000/rok
 ```
 ### Cluster design
- **Max velikost clusteru**: 64 hostů (vSphere 8), 96 hostů (vSphere 8 + enhanced)
+- **Max velikost clusteru**: 64 hostů (vSphere 8/9), 96 hostů (vSphere 8 + enhanced)
 - **Datastore limits**: max 256 datastorů na host, max 65 TB na VMFS-6 datastore
 - **vSAN ready capacity**: doporučeno max 60-64 hostů na vSAN cluster
 - **Fault domains** — rozdělení clusteru do skupin hostů (rack awareness), min 3 fault domains pro stetch cluster
@@ -42,10 +70,24 @@
  - **Host failures cluster tolerates** — nejčastější (1-4 hosty)
  - **Percentage of cluster resources** — rezervace % CPU/memory
  - **Dedicated failover hosts** — vyhrazený host(y) pro HA
- **Cluster limits (vSphere 8)**:
+- **Cluster limits (vSphere 8/9)**:
-  - 512 VMs per host (max)
+  - 960 VMs per host (vSphere 9 max)
  - 15 000 VMs per cluster (vCenter max)
-  - 300 hosts per cluster (vSphere 8, hardware vMotion)
+  - 300 hosts per cluster (vSphere 8/9, hardware vMotion)
 ### Microsoft Hyper-V licensing
 | Varianta | Metrika | Cena | Co obsahuje |
 |----------|---------|------|-------------|
 | **Windows Server Standard** | Per core (min 16 licencí/server) + CAL | ~$1 000/core (jednorázově) + $200/CAL | 2 VM licence (každá s plnou Windows Server licencí) |
 | **Windows Server Datacenter** | Per core (min 16 licencí/server) + CAL | ~$6 200/core (jednorázově) + $200/CAL | Neomezené VM, Storage Spaces Direct, Shielded VMs |
 | **Azure Stack HCI** | Per core (měsíčně) | ~$10-20/core/měsíc (Azure hybrid benefit) | Hyper-V + S2D + Azure management, součást Azure subscription |
 | **Hyper-V Server** | Zdarma | $0 | Samostatný hypervisor (bez managementu, bez GUI, omezená podpora) — od 2025 již není distribuován |
 **Důležité**:
 - Windows Server Standard = 2 VM na každou licenci. Pokud potřebujete 3 VM na 2-socket serveru, potřebujete 2× Standard license (4 VM) nebo Datacenter
 - **Azure Hybrid Benefit** — pokud máte Windows Server s SA (Software Assurance), můžete použít license v Azure bez dodatečných nákladů
 - **CAL (Client Access License)** — každý uživatel nebo zařízení přistupující k Windows Serveru musí mít CAL (kromě Azure Hybrid Benefit)
 ## Microsoft Hyper-V
@@ -149,6 +191,141 @@ Viz také: [STORAGE.md](STORAGE.md) — detailní přehled storage protokolů a
 - **Use case**: Telco, velké private cloudy, MNO (MANO, NFVI)
 - **Náročnost**: Vysoká — komplexní nasazení a údržba
 ---
 ## Variantní konfigurace hypervizorů podle velikosti a typu storage
 ### Volba platformy podle use case
 | Use case | Primární volba | Alternativa | Zdůvodnění |
 |----------|---------------|-------------|------------|
 | **VMware shop, enterprise** | vSphere 8/9 | Hyper-V | Nejobsáhlejší ekosystém, vSAN, SRM, nejširší ISV podpora |
 | **Microsoft shop, Azure hybrid** | Hyper-V / Azure Stack HCI | vSphere | Windows Server CAL už je, S2D, Azure Arc, native Hyper-V Replica |
 | **SME / nízký budget** | Proxmox VE | XCP-ng / Hyper-V (free) | Open source, vestavěný Ceph, ZFS, PBS, žádné licenční náklady |
 | **HCI greenfield** | Nutanix AHV | VMware vSAN | All-in-one, jednoduchá správa, vestavěný DR a backup |
 | **Hyperscale / telco** | OpenStack (RHOSP) | — | Multi-tenancy, NFVI, MANO, Neutron SDN, Ceph integrace |
 ### Varianta A: Malé nasazení (2-3 hosty, lokální storage)
 Pro malé firmy, pobočky, edge, dev/test. Žádné sdílené storage — HA zajištěna aplikačně nebo replikací VM.
 | Parametr | Proxmox VE | VMware vSphere | Hyper-V |
 |----------|-----------|---------------|---------|
 | **CPU** | 1× EPYC 9124-9224 / Xeon 4410Y (8-16C) | 1× EPYC 9124-9224 / Xeon 4410Y | 1× Xeon 4410Y / EPYC 9124 |
 | **RAM** | 64-128 GB (DDR5-4800, 1DPC) | 64-128 GB | 64-128 GB |
 | **OS disk** | 2× SATA SSD RAID1 (240-480 GB) | 2× SATA SSD RAID1 | 2× SATA SSD RAID1 |
 | **VM storage** | ZFS RAID10 (4-6× NVMe/SATA SSD) | VMFS local (4-6× SSD RAID5/10) | ReFS CSV (4-6× SSD RAID10) |
 | **Network** | 2× 10/25 GbE LACP | 2× 10/25 GbE LACP + management | 2× 10/25 GbE LACP |
 | **Management** | Proxmox web UI (1× node) | vCSA / vCenter (1× appliance) | Windows Admin Center / SCVMM |
 | **HA** | Proxmox HA (watchdog, fencing) | vSphere HA (1 host failure) | Hyper-V HA (WS Failover Cluster) |
 | **Backup** | Proxmox Backup Server | Veeam B&R (Community) | Windows Server Backup / Veeam |
 | **Licence** | Zdarma (support ~€500/host/rok) | vSphere Essentials (~$600/3 hosts) | Windows Server Standard (2 VMs) |
 **Use case**: Startup, pobočka, dev/test, < 200 VM, bez SAN, minimální budget.
 **Výhody**: Nízká cena, jednoduchá správa. **Nevýhody**: Omezená škálovatelnost, výpadek hostu = nedostupnost VM.
 ### Varianta B: Střední HCI (3-6 hostů, vSAN / Ceph)
 Hyperkonvergovaná infrastruktura — storage běží na stejných hostech jako VM.
 | Parametr | VMware vSAN | Proxmox + Ceph | Nutanix AHV |
 |----------|------------|----------------|-------------|
 | **CPU** | 1-2× EPYC 9334-9654 (16-32C) | 1-2× EPYC 9224-9334 (12-24C) | 1-2× EPYC 9334-9654 |
 | **RAM** | 256-512 GB | 128-256 GB | 256-512 GB |
 | **Cache tier** | 1-2× NVMe cache (write buffer) | — (Ceph používá RAM/OSD) | 1-2× NVMe (oplog) |
 | **Capacity tier** | 4-8× SSD (SAS/SATA) | 4-8× HBA NVMe/SSD (OSD) | 4-6× SSD (extent store) |
 | **Network** | 4× 25 GbE (vSAN + VM + mgmt) | 4× 25 GbE (Ceph public + cluster) | 4× 25 GbE (storage + VM) |
 | **Fault domain** | Rack awareness (3 racks min) | CRUSH rack level | Rack awareness |
 | **Replication** | RAID-1 mirroring (FTT=1) | 3× replikace / EC 8+3 | 2× kopie + EC |
 | **Dedupe/Compress** | Dedup + compression (capacity) | ZFS / Ceph compression (inline) | Inline compression |
 | **HA limit** | 1-3 host failures | 1-2 host failures (replication) | 1-2 host failures |
 | **Min. hostů** | 2 + witness | 3 (MON + OSD) | 3 |
 **Use case**: Střední firma, VDI, general virtualizace, 50-500 VM.
 **Doporučení**: Pro vSAN → min. 4 hosty pro FTT=1 s erasure coding. Pro Ceph → min. 3 hosty, ideálně 5+, každý OSD host = 1 OSD na NVMe pro maximální IOPS.
 ### Varianta C: Enterprise FC SAN (6+ hostů)
 Klasická 3-tier architektura — compute (hosty) + storage (SAN) + network oddělené.
 | Parametr | VMware vSphere | Hyper-V |
 |----------|---------------|---------|
 | **CPU** | 2× EPYC 9654-9965 (32-64C) | 2× EPYC 9654-9965 / Xeon 8592+ |
 | **RAM** | 512-2048 GB (DDR5) | 512-2048 GB |
 | **OS disk** | 2× SATA SSD RAID1 (480 GB) | 2× SATA SSD RAID1 |
 | **Storage** | FC SAN LUN (2× FC HBA 32/64G) | FC SAN LUN nebo CSV over SMB |
 | **App network** | 2-4× 25/100 GbE LACP | 2-4× 25/100 GbE LACP |
 | **Storage network** | 2× FC 32/64G (multipath) | 2× FC 32/64G nebo SMB Multichannel |
 | **vMotion / Live Migration** | 2× 25 GbE dedikované (vMotion) | 2× 25 GbE dedikované (SMB/RDMA) |
 | **Management** | vCenter (VCSA), NSX, Aria | SCVMM, Azure Arc |
 | **Cluster max** | 64-96 hostů (vSphere 8/9) | 64 hostů (WS 2025) |
 | **Admission control** | 1-4 host failures | Nodes reserve |
 | **Drs / Balancování** | DRS (fully automated) | SCVMM / AKS load balancing |
 **Use case**: Enterprise, databáze, kritické aplikace, 500-5000 VM.
 **Varianty storage**: FC SAN (nejnižší latence), iSCSI (nižší CAPEX), NFS (jednodušší management).
 **FC SAN topologie**:
 ```
                 ┌─────────────────────────────────────┐
                 │              FC Fabric              │
                 │   ┌─────────┐       ┌─────────┐    │
                 │   │ Switch 1│       │ Switch 2│    │
                 │   └────┬────┘       └────┬────┘    │
                 └────────┼─────────────────┼──────────┘
                    ┌─────┴─────┐     ┌─────┴─────┐
               ┌───┤ FC HBA 1  ├─┐ ┌─┤ FC HBA 2  ├───┐
               │   └───────────┘ │ │ └───────────┘   │
            ┌──┴──┐          ┌──┴──┴──┐          ┌──┴──┐
            │Host1│          │Host2   │          │Host3│ ...
            └─────┘          └────────┘          └─────┘
 ```
 ### Varianta D: Hyperscale OpenStack (20+ hostů)
 Pro telco, velké private cloudy, MANO/NFVI prostředí.
 | Parametr | Red Hat OpenStack | Canonical Charmed OpenStack |
 |----------|-------------------|-----------------------------|
 | **Compute** | Nova + KVM | Nova + KVM |
 | **Storage** | Ceph (Cinder/RBD) + Swift | Ceph + Swift |
 | **Network** | Neutron + OVN/OVS + DPDK | Neutron + OVN/OVS |
 | **CPU per host** | 2× EPYC 9654-9965 (64-128C) | 2× EPYC 9654-9965 |
 | **RAM per host** | 512-1024 GB | 512-1024 GB |
 | **Storage per host** | Ceph OSD (4-12× NVMe/SSD) | Ceph OSD |
 | **Network per host** | 4-8× 100 GbE (DPDK/VPP) | 4× 100 GbE |
 | **Control plane** | 3-9× kontrolní nod (HA) | 3-7× kontrolní node |
 | **Orchestrace** | TripleO / OpenStack Kolla | Juju + charms |
 | **SDN** | OVN, OpenDaylight | OVN |
 | **NFVI ready** | Yes (SR-IOV, NUMA, huge pages) | Yes |
 | **Min. velikost** | 9 nodeů (3 ctl + 3 compute + 3 ceph) | 7 nodeů |
 **Use case**: Telco (5G UPF, MNO), hyperscale private cloud, > 5000 VM.
 ### Connectivity summary podle platformy
 | Platforma | App / VM síť | Storage síť | Replikace / HA | Management |
 |-----------|-------------|-------------|----------------|------------|
 | **Proxmox malý** | 2× 10/25 GbE LACP | — (lokální ZFS) | — | 1× 1 GbE |
 | **vSAN (3-6)** | 2× 25 GbE LACP | 2× 25 GbE (vSAN) | vSAN traffic | 1× 1 GbE |
 | **Proxmox Ceph (3-6)** | 2× 25 GbE | 2× 25 GbE (Ceph public) | 2× 25 GbE (Ceph cluster) | 1× 1 GbE |
 | **Nutanix (3-6)** | 2× 25 GbE | Dedikované storage VLAN | Replication traffic | 1× 1 GbE |
 | **vSphere FC SAN (6+)** | 2-4× 25/100 GbE LACP | 2× FC 32/64G multipath | 2× 25 GbE (vMotion) | 1× 1 GbE + SAN mgmt |
 | **Hyper-V FC SAN (6+)** | 2-4× 25/100 GbE LACP | 2× FC 32/64G nebo SMB | 2× 25 GbE (Live Migration) | 1× 1 GbE |
 | **OpenStack (20+)** | 2-4× 100 GbE | 2× 100 GbE (Ceph) | 2× 100 GbE (OVN) | 1× 1 GbE |
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | Virtualization Essentials (3rd ed., 2023) | Matthew Portnoy | 978-1119481513 | Praktický průvodce virtualizací: od základů hypervisorů (Type 1/Type 2), konfigurace VM (CPU, memory, storage, networking) až po cloud computing a DevOps. "Learning-by-doing" přístup s tutorialy. Autor je Senior System Engineer u VMware/Splunk. |
 | VMware vSphere Design (2nd ed.) | Guthrie, Lowe, Coleman | 978-1119130312 | Komplexní průvodce návrhem vSphere infrastruktury: hardware selection, network layout, security, storage a hypervisory. Popisuje framework pro design, analýzu rozhodnutí a best practices od zkušených VMware architectů. |
 *Poslední revize: 2026-06-03*
--- a/INFRASTRUCTURE.md
+++ b/INFRASTRUCTURE.md
@@ -8,3 +8,5 @@ Tento soubor byl rozdělen do samostatných oblastí:
 | 🏭 Datová centra | [DATACENTERS.md](DATACENTERS.md) |
 | 💾 Storage | [STORAGE.md](STORAGE.md) |
 | 🔧 Hardware a servery | [HARDWARE.md](HARDWARE.md) |
 *Poslední revize: 2026-06-03*
--- a/MONGODB.md
+++ b/MONGODB.md
@@ -0,0 +1,116 @@
 # 🥬 MongoDB
 ## Přehled
 MongoDB je nejrozšířenější document-oriented NoSQL databáze. Ukládá data jako BSON (binární JSON) dokumenty s flexibilním schematem. Vhodná pro aplikace s rychlým vývojem, kde schema často migruje nebo je různorodé.
 ## Data model
 - **Database** → Collection → Document (JSON/BSON)
 - **Document** — pole s klíč-hodnota, vnořené objekty, pole
 - **Flexibilní schema** — každý dokument může mít jiná pole (ale nedoporučuje se)
 - **ObjectID** — výchozí primární klíč (12-bajtový: timestamp + machine + PID + counter)
 ## Architektura
 ```
 mongod (jednotlivý node)
  ├── WiredTiger storage engine (výchozí od 3.2)
  │   ├── B-Tree indexy (B-Tree, ne LSM)
  │   ├── MVCC (snapshot isolation)
  │   ├── Compression (zlib, snappy, zstd)
  │   └── Cache (WiredTiger internal cache)
  ├── Replication (replica set)
  │   ├── Primary (všechny zápisy)
  │   └── Secondary (replikace, volitelné čtení)
  └── Sharding (cluster)
      ├── mongos (router)
      ├── Config servers (metadata)
      └── Shards (replica sets)
 ```
 ### Replica set
 - Primární node = všechny zápisy, sekundární = replikace (oplog)
 - Automatický failover (election mezi sekundáry)
 - Až 50 nodeů v replica setu, max 7 voting nodes
 - Read preference: primary (default), primaryPreferred, secondary, secondaryPreferred, nearest
 ### Sharding
 - Shard klíč = rozhodující pro distribuci
 - **Range sharding** — blízká data na stejném shardu (good for range queries, risk of hot spots)
 - **Hashed sharding** — rovnoměrná distribuce (good for write throughput, bad for range queries)
 - **Zoned sharding** — data umístěna podle zón (geo-distribuce, compliance)
 ## Index types
 | Typ | Popis |
 |-----|-------|
 | **Single field** | Standard B-Tree index |
 | **Compound** | Více polí v indexu (order matters) |
 | **Multikey** | Index na pole (array) — každá hodnota samostatně |
 | **Text** | Full-text search |
 | **Geospatial (2d, 2dsphere)** | Geo dotazy (near, within, intersect) |
 | **Hashed** | Pro hashed sharding |
 | **TTL** | Automatické mazání dokumentů po expiraci |
 | **Wildcard** | Index na neznámá/nepravidelná pole |
 ## Aggregation pipeline
 MongoDB pipeline framework pro transformace dat:
 ```javascript
 db.orders.aggregate([
  { $match: { status: "shipped" } },
  { $group: { _id: "$customer_id", total: { $sum: "$amount" } } },
  { $sort: { total: -1 } },
  { $limit: 10 }
 ])
 ```
 ## Doporučení — v čem je MongoDB lepší
 | Oblast | MongoDB | Konkurence | Proč MongoDB |
 |--------|---------|------------|--------------|
 | **Flexibilní schema** | Schema-less, změny bez migrace | PostgreSQL (ALTER TABLE + migration) | Rychlý vývoj, MVP, časté změny modelu |
 | **JSON / dokumenty** | Nativní BSON, vnořené objekty | PostgreSQL (jsonb, ale chybí $ operators) | Jednodušší mapování objektů z kódu |
 | **Horizontal scaling** | Nativní sharding (mongos + config) | MySQL (Vitess externí) | Vestavěný, jednoduchý na setup |
 | **Geo-distribuce** | Zoned sharding, replica set per region | Cassandra (AP model, jiná filozofie) | CP z CAP, konzistence + distribuce |
 | **Agregace** | Aggregation pipeline, $lookup (LEFT JOIN) | PostgreSQL (SQL JOINy, výkonnější) | Užitečné pro denormalizovaná data |
 | **Rychlost developmentu** | ORM-like (Mongoose), JSON přirozený | SQL (schema first, migrace) | Nejrychlejší time-to-market |
 ### Kdy použít MongoDB
 - **Rychlý vývoj / MVP** — schema evolves frequently, žádné migrace
 - **Katalogová data** — produkty s různými atributy (e-commerce, marketplace)
 - **Content management** — různorodý obsah (blog, CMS, headless CMS)
 - **Real-time analytics** — agregace, dashboardy, event data
 - **IoT / senzorová data** — různorodé struktury zpráv
 - **Mobilní aplikace** — JSON dokumenty přirozeně mapují API response
 ### Kdy použít něco jiného
 - **Finanční transakce** → PostgreSQL (ACID, referenční integrita)
 - **Komplexní reporty / JOINy** → PostgreSQL nebo ClickHouse
 - **Vztahová data (friends, follows)** → Neo4j (grafová DB)
 - **High-throughput zápisů** → Cassandra (AP model, bez master bottlenecku)
 - **Malá data, jeden server** → SQLite (jednodušší, žádný daemon)
 ## MongoDB licensing
 MongoDB změnila licenci v roce 2018 z GNU AGPL v3 na **SSPL** (Server Side Public License):
 | Varianta | Licence | Cena | Podmínky |
 |----------|---------|------|----------|
 | **MongoDB Community** | SSPL | Zdarma | SSPL: pokud nabízíte MongoDB jako managed službu, musíte uvolnit celý stack (vč. orchestrace, monitoringu) jako open source. Interní použití bez omezení |
 | **MongoDB Enterprise Advanced** | Komerční | ~$10 000/server/rok (Atlas: pay-per-use) | Enterprise funkce (LDAP, Kerberos, auditing, encryption), support 24/7 |
 | **MongoDB Atlas** | Managed | Pay-per-use (~$0.10-5.00/hod dle instance) | Plně managed, multi-cloud, auto-scaling, backup, monitoring |
 **Dopad**: SSPL je podobný model jako u Redis — pro self-hosted interní použití bez omezení, cloud poskytovatelé (AWS, Azure) nesmí nabízet MongoDB jako managed službu bez komerční dohody. Alternativa: **FerretDB** (open source proxy kompatibilní s MongoDB wire protokolem).
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 *Poslední revize: 2026-06-03*
--- a/MONITORING.md
+++ b/MONITORING.md
@@ -236,7 +236,7 @@ receivers:
 ## Strukturované logování
-```
+```json
 {
  "timestamp": "2026-06-03T10:30:00Z",
  "level": "ERROR",
@@ -381,6 +381,91 @@ Level 3: Engineering manager / incident commander
 - **Retention politika** — raw data krátce, agregace dlouhodobě
 - **Jednotný formát logů** — JSON, strukturovaná data
 ## Doporučená literatura
 ### Klasické knihy
 | Kniha | Autoři | ISBN | Klíčová témata |
 |-------|--------|------|----------------|
 | **Site Reliability Engineering** | Beyer, Jones, Petoff, Murphy | 978-1491929124 | Jak Google provozuje produkční systémy — SRE principy, error budgety, toil, SLI/SLO |
 | **The Site Reliability Workbook** | Beyer, Murphy, Rensin, Kawahara, Thorne | 978-1492029502 | Praktický doprovod k SRE — case studies z Evernote, Home Depot, NY Times; implementace SLO, monitoring, on-call |
 | **Observability Engineering** | Majors, Fong-Jones, Miranda | 978-1492076445 | První ucelená kniha o observability — structured events, iterativní verifikace hypotéz, core analysis loop; 2. vydání v roce 2026 (32 nových kapitol o AI, cost governance) |
 ### Cloud a monitoring
 | Kniha | Autor | ISBN/Rok | Témata |
 |-------|-------|----------|--------|
 | **Cloud Observability in Action** | Michael Hausenblas | Manning, 2023 | Praktický průvodce observability v cloud-native prostředí — signal types (logs, metrics, traces, profiles), OTel Collector, SLOs, signal correlation, developer observability; open-source nástroje |
 | **Mastering Prometheus** | William Hegedus | 978-1-80512-566-2 | Pokročilé techniky pro Prometheus — interní architektura TSDB, custom service discovery, kardinalita, remote storage (VictoriaMetrics, Mimir), SLO-based alerting; autor je SRE manager v Akamai a contributor Prometheus/Thanos |
 | **Observability with Grafana** | Chapman, Holmes | 978-1-80324-964-3 | Kompletní průvodce LGTM stackem (Loki, Grafana, Tempo, Mimir) — instrumentace přes OTel, LogQL/PromQL/TraceQL, AI/ML alerting, real user monitoring s Faro, Pyroscope profiling, k6 zátěžové testování |
 | **Hands-On Monitoring and Alerting with Prometheus** | Muhammad Badawy | 978-9349887565 | Praktický průvodce Prometheus — instalace, konfigurace, service discovery, labeling, PromQL, Alertmanager, monitoring Linux, Windows, Docker, databází |
 ### AI a observability
 | Kniha | Autoři | ISBN/Rok | Témata |
 |-------|--------|----------|--------|
 | **Observability in the AI-Native Era** | Lipsig, Grabner, Rati | 978-1-80638-959-9 | Propojení observability s AIOps — ML-based anomaly detection, root-cause analysis, self-healing systémy, OTel + Prometheus + Grafana + Dynatrace/Datadog, compliance |
 | **Open Source Observability** | Corless, Pawar | O'Reilly, 2025 | Report o disaggregated, modulárních observability stackách — flexibilita, cost efficiency, data autonomy, blueprint pro vlastní řešení z open-source komponent |
 ## Detailní přehled nástrojů
 Rozšířené informace k nástrojům z tabulky výše:
 ### Grafana Sigil
 AI observability produkt od Grafana Labs. OpenTelemetry-native SDK pro instrumentaci LLM agentů:
 - **Repozitář**: `github.com/grafana/sigil-sdk` (Go SDK) + `sigil-app` (Grafana plugin)
 - **Funkce**: sledování konverzací, generování, tool usage, cost tracking, quality evaluation
 - **Rostoucí problém**: 500M+ konverzací, 5M+ agentů v produkci (GrafanaCON 2026)
 - **Integrace**: automatické propojení s Prometheus (metrics), Tempo (traces), AI Observability API
 ### InfraLens
 Zero-instrumentation Kubernetes observability postavená na eBPF:
 - **Repozitář**: `github.com/Herenn/Infralens` (Apache 2.0, Go)
 - **Funkce**: automatická detekce service-to-service komunikace, vizualizace topologie, AI-powered dokumentace
 - **Architektura**: eBPF agent + Go backend + React frontend
 - **Status**: early-stage (1 star, 10 commitů), ale koncept eBPF-based observability je potvrzený (Grafana Beyla, Cilium Hubble, Pixie)
 ### Ingero
 GPU causal observability agent — první svého druhu:
 - **Repozitář**: `github.com/ingero-io/ingero` (Apache 2.0)
 - **Funkce**: eBPF tracing od Linux kernel eventů přes CUDA API až po Python zdrojový kód
 - **Overhead**: < 2 %, zero code changes, jeden binární soubor
 - **MCP server**: nativní podpora Model Context Protocol — AI asistenti mohou přímo queryovat GPU data
 - **Use case**: diagnostika GPU stallů, scheduler preemptions, CUDA memory spikes — kauzální řetězce místo prostých metrik
 - **Verze**: v0.19.0 (2026), aktivní vývoj
 ### GreptimeDB
 Unified observability databáze — jeden backend pro metrics, logs a tracy:
 - **Repozitář**: `github.com/GreptimeTeam/greptimedb` (Apache 2.0, Rust)
 - **Architektura**: compute-storage disaggregation, object storage first (S3, GCS, Azure Blob), columnar storage
 - **Dotazování**: SQL + PromQL v jedné query, možnost JOIN mezi metrikami a logy
 - **Drop-in náhrada**: Prometheus (PromQL, remote write), Loki (Push API), Elasticsearch (bulk API), Jaeger (Query API)
 - **Cost reduction**: až 50× nižší náklady oproti tradičním řešením
 - **Roadmap 2026**: v1.0 GA (Q1 2026), v1.1–v1.3 (Vector Index, AI Functions, Auto Rollup, adaptive resource management)
 - **GreptimeDB Enterprise**: enhanced security, HA, enterprise support
 ### Netdata
 Open-source, real-time monitoring platform pro celou infrastrukturu:
 - **Repozitář**: `github.com/netdata/netdata` (GPLv3+, C; 79k★)
 - **Funkce**: per-sekundové metriky, ML-based anomaly detection, AI-powered troubleshooting, 800+ integrací
 - **Zero configuration**: auto-discovery, pre-configured alerts, hotové dashboardy
 - **Architektura**: distributed agent → Netdata Cloud (volitelně), data zůstávají lokální
 - **Energetická efektivita**: dle studie University of Amsterdam nejefektivnější nástroj pro monitoring Docker systémů
 - **Netdata Cloud**: free tier (5 node), paid od $12/node/měsíc
 - **Licencování**: agent GPLv3+, dashboard NCUL1, cloud closed-source
 ## Zdroje
 Odkazy, knihy a standardy: [sources/monitoring/sources.md](sources/monitoring/sources.md)
 *Poslední revize: 2026-06-03*
--- a/MYSQL.md
+++ b/MYSQL.md
@@ -0,0 +1,142 @@
 # 🐬 MySQL & MariaDB
 ## Přehled
 MySQL je nejrozšířenější open-source relační databáze, zejména ve webovém prostředí (LAMP stack). MariaDB je fork po akvizici Oracle, plně kompatibilní s rozšířeními. Výchozí volba pro WordPress, Drupal, Magento a většinu PHP aplikací.
 ## Architektura (server + storage engine)
 Na základě *High Performance MySQL* (Schwartz, Zaitsev, Tkachenko):
 ```text
 MySQL Server Layer
  ├── Connection handling (thread-per-connection)
  ├── Query parser & optimizer
  ├── Built-in functions
  └── Storage Engine API
        ├── InnoDB (výchozí, MVCC, ACID)
        ├── MyISAM (legacy, table-level locks)
        ├── MEMORY (in-memory, HEAP)
        └── ... (ostatní)
 ```
 ### InnoDB (výchozí engine od MySQL 5.5+)
 - **MVCC** — Multi-Version Concurrency Control (snapshot isolation)
 - **REPEATABLE READ** (výchozí) — next-key locking zabraňuje phantom reads
 - **Clustered index** — primární klíč = fyzické uspořádání dat
 - **Buffer pool** — cache dat a indexů v RAM (hlavní parametr výkonu)
 - **Doublewrite buffer** — prevence částečného zápisu stránky
 ### Schema design tipy
 - Preferovat menší datové typy (MEDIUMINT místo INT, TIMESTAMP místo DATETIME)
 - NULL používat opatrně (každý NULL sloupec zvyšuje složitost indexu)
 - ENUM používat jen pro opravdu malé, stabilní seznamy hodnot
 - JSON sloupce v MySQL 8+ — užitečné pro flexibilní schema, ale ne pro joinování
 ### Deferred join pattern
 ```sql
 -- 1. covering index najde PK
 -- 2. teprve pak join na plný řádek
 SELECT * FROM users
  INNER JOIN (
    SELECT id FROM users
    WHERE status = 'active'
    ORDER BY created_at DESC
    LIMIT 100 OFFSET 1000
  ) AS tmp USING (id);
 ```
 **Join decomposition**: Někdy výhodnější rozdělit JOIN na několik jednoduchých dotazů (lepší využití cache, méně locků, škálování napříč servery).
 **IN() optimalizace**: MySQL řadí hodnoty v IN() seznamu a používá binární vyhledávání (O(log n)), na rozdíl od OR klauzulí (O(n)).
 ## MariaDB rozdíly oproti MySQL
 | Vlastnost | MySQL 8.x | MariaDB 11.x |
 |-----------|-----------|--------------|
 | **Storage engine** | InnoDB (pouze) | InnoDB + XtraDB (fork) + Aria + MyRocks |
 | **JSON** | Native JSON typ | JSON alias na LONGTEXT + JSON funkce |
 | **CTE** | WITH (non-recursive + recursive) | WITH (non-recursive + recursive) |
 | **Window functions** | Ano (8.0+) | Ano (10.2+) |
 | **Sequence** | Ne (auto_increment only) | Ano (CREATE SEQUENCE) |
 | **Thread pooling** | Enterprise only | Vestavěný |
 | **Galera cluster** | Ne (nativně) | Ano (nativní synchronní clustering) |
 ## ProxySQL
 ProxySQL je advanced proxy pro MySQL s pokročilým routingem:
 | Vlastnost | Popis |
 |-----------|-------|
 | **Query routing** | Pravidla pro směrování dotazů (read/write split, sharding) |
 | **Connection pooling** | Multiplexování tisíců spojení do malého poolu |
 | **Query cache** | Cache výsledků v paměti (TTL, size limit) |
 | **Query rewriting** | Rewrite SQL dotazů na cestě |
 | **Aktivní monitoring** | Detekce výpadků backendů, automatic failover |
 ## Doporučení — v čem je MySQL lepší
 | Oblast | MySQL | Konkurence | Proč MySQL |
 |--------|-------|------------|------------|
 | **Webové aplikace** | De facto standard pro WP, Drupal, Magento | PostgreSQL (méně CMS pluginů) | Nejširší podpora ve web hosting providers |
 | **Čtení (SELECT heavy)** | InnoDB buffer pool, covering index, adaptive hash | PostgreSQL (MVCC overhead u čtení) | Cache-efficient, rychlé point lookupy |
 | **Replikace** | Async replication, Group Replication, InnoDB Cluster | PostgreSQL (streaming replication) | Jednodušší setup, široká dokumentace |
 | **Ekosystém** | ProxySQL, Orchestrator, Vitess, PlanetScale | PostgreSQL (méně nástrojů) | Nejvíce toolingu pro správu clusteru |
 | **JSON v MySQL 8+** | JSON datový typ, Multi-Value Indexes | PostgreSQL (jsonb, GIN) | Srovnatelné, Multi-Value Index unikátní |
 ### Kdy použít MySQL / MariaDB
 - **CMS / e-commerce** — WordPress, Drupal, Magento, Joomla (všechny vyžadují MySQL)
 - **Read-heavy aplikace** — InnoDB buffer pool efektivně cachuje často čtená data
 - **Jednoduchá replicace** — Group Replication / InnoDB Cluster pro HA
 - **MariaDB pro Galera cluster** — synchronní multi-master clustering
 - **PHP aplikace** — nativní PHP MySQL extensions (mysqli, PDO_MySQL)
 ## MySQL / MariaDB licensing
 ### MySQL licensing
 | Varianta | Licence | Cena | Omezení |
 |----------|---------|------|---------|
 | **MySQL Community (GPL)** | GPL v2 | $0 | Pokud distribuujete aplikaci, která obsahuje MySQL (např. embedded), musíte uvolnit celou aplikaci pod GPL. Webová aplikace (přes network) ≠ distribuce — GPL se netýká |
 | **MySQL Standard (Commercial)** | Commercial (Oracle) | ~$2 000/server/rok | Bez GPL omezení, production support, MySQL Enterprise Monitor |
 | **MySQL Enterprise** | Commercial (Oracle) | ~$5 000/server/rok | Vše výše + MySQL Enterprise Backup, Audit, Firewall, Thread Pool, Encryption |
 | **MySQL Cluster CGE** | Commercial (Oracle) | ~$10 000/server/rok | Distributed multi-master cluster (NDB), telco-grade |
 **Kdy GPL vadí**: Pokud embeddedujete MySQL do komerčního produktu (např. desktopová aplikace s MySQL knihovnou). Webová aplikace komunikující přes TCP/IP **není** distribuce — GPL se neuplatní.
 ### MariaDB licensing
 | Varianta | Licence | Cena | Omezení |
 |----------|---------|------|---------|
 | **MariaDB Community** | GPL v2 | $0 | Stejné jako MySQL Community — GPL, ale bez Oracle licenčních rizik |
 | **MariaDB Enterprise** | Business Source License (BSL) | Subscription (~$2-5k/server/rok) | Po 3 letech se automaticky mění na GPL v2. Zahrnuje enterprise funkce (ColumnStore, Spider, Xpand) |
 | **MariaDB SkySQL** | Managed (BSL) | Pay-per-use (~$0.10-1.00/hod) | Fully managed DBaaS |
 **Klíčový rozdíl oproti Oracle MySQL**:
 - MariaDB je nezávislý fork, není pod kontrolou Oracle
 - BSL model je liberálnější — po 3 letech se stává open source
 - MariaDB nevyžaduje commercial licenci pro enterprise funkce (v MySQL jsou enterprise-only)
 ### Kdy použít něco jiného
 - **Komplexní dotazy / CTE / window functions** → PostgreSQL (pokročilejší optimalizátor)
 - **GIS / geoprostorová data** → PostgreSQL + PostGIS
 - **Konzistence > rychlost** → PostgreSQL (SSI serializable)
 - **High-throughput zápisů** → Cassandra (MySQL master bottleneck)
 - **Distribuovaný SQL cluster** → CockroachDB, Vitess (MySQL kompatibilní sharding)
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | High Performance MySQL (4th ed.) | Schwartz, Zaitsev, Tkachenko | 978-1492075292 | Komplexní průvodce architekturou, optimalizací a monitoringem MySQL |
 *Poslední revize: 2026-06-03*
--- a/NETWORKING.md
+++ b/NETWORKING.md
@@ -183,7 +183,7 @@ Root DS → .com DNSKEY → .com DS → example.com DNSKEY → example.com RRSIG
 ### BGP path selection algoritmus
-BGP router vybírá jedinou nejlepší cestu podle následujících kriterií (v pořadí priority):
+BGP router vybírá jedinou nejlepší cestu podle následujících kritérií (v pořadí priority):
 1. **WEIGHT** (Cisco-specific) — nejvyšší weight (local to router)
 2. **LOCAL_PREF** — nejvyšší local preference (v rámci AS)
@@ -329,6 +329,165 @@ Viz také: [CLOUD.md](CLOUD.md) — cloud architektura, multi-AZ, hybrid cloud k
 - **Segment Routing (SR-MPLS / SRv6)** — zjednodušení MPLS, programovatelné cesty
 - **Zero Trust Networking** — mikrosegmentace, identity-based access, never trust / always verify
 ## Rozšířená témata podle knih
 ### TCP/IP Illustrated (Stevens, ISBN 978-0321336316)
 Klíčové architektonické principy dle knihy:
 - **End-to-End Argument** — korektnost a kompletnost komunikace může být zajištěna pouze na úrovni aplikace, nikoliv nižších vrstev. Síť má být "hloupá", koncové stanice "chytré".
 - **Fate Sharing** — veškerý stav nutný k udržení aktivní komunikace musí být uložen na koncových bodech (endpoints), nikoliv v síti.
 - **Layering** — hierarchické vrstvení protokolů dle OSI modelu; každá vrstva zapouzdřuje PDU z vyšší vrstvy a přidává vlastní hlavičku.
 - **Multiplexing/Demultiplexing** — protokoly na stejné vrstvě koexistují díky identifikátorům (IP proto, TCP/UDP port).
 - **Sliding window** — efektivní využití linky při vysoké latenci (window size = bandwidth × RTT).
 Kniha pokrývá celý TCP/IP stack od linkové vrstvy (Ethernet, ARP, PPP) přes IP, ICMP, DHCP, NAT, DNS, UDP, TCP (connection management, timeout, retransmission, congestion control, keepalive) až po aplikace (SNMP, Telnet, FTP, SMTP, NFS, HTTP).
 ### AI Data Center Network Design (Subramaniam, ISBN 978-0-13-543628-8)
 Komplexní, vendor-agnostický průvodce návrhem síťové infrastruktury pro AI clustery.
 **Klíčové koncepty:**
 - **Rail-Optimized Design (ROD)** — propojení GPU napříč racky po "kolejích" (rail), každá kolej tvoří nezávislou síť pro all-reduce komunikaci. Minimalizuje latenci pro synchronní training.
 - **Rail-Unified Design (RUD)** — sdílená network fabric pro všechny GPU, flexibilnější, ale vyšší nároky na load balancing.
 - **RoCEv2 (RDMA over Converged Ethernet)** — primární transport pro AI clustery: vyžaduje lossless fabric (ECN, PFC, DCQCN, SFC, CSIG).
 - **Load balancing pro AI** — ECMP nestačí, nutné dynamic/global load balancing (DLB/GLB), flowlet-based rebalancing, per-packet spraying.
 - **Topologie** — Clos (3-stage/5-stage), Dragonfly, Torus pro škálování na desítky tisíc GPU.
 - **Ultra Ethernet Consortium (UEC)** — nový standard pro Ethernet v AI clastrech (2025+), řeší omezení RoCEv2.
 - **Storage pro AI** — NVMe-oF, GPUDirect Storage, parallel file systems pro checkpointing a dataset loading.
 - **KPIs** — Job Completion Time (JCT), tail latency, fabric utilization, PFC storm detection.
 ### Cloud Networking and Resilience (Critelli, ISBN 979-8868824357)
 Praktický průvodce budováním resilientních cloudových sítí (Apress, 2026). Autor je EMEA Lead pro Networking & Resilience v AWS.
 **Vrstvový přístup k resilienci (podle OSI modelu):**
 | Vrstva | Opatření |
 |--------|----------|
 | L1 (Fyzická) | Redundantní přípojky, diverse fibre paths, DWDM |
 | L2 (Linková) | MLAG, LACP, spanning-tree rychlá konvergence |
 | L3 (Síťová) | BGP multi-homing, AS path prepend, Anycast |
 | L4 (Transportní) | Connection draining, slow start, health checky |
 | L7 (Aplikační) | DNS failover, global load balancing, cell-based architektury |
 **Regulatorní rámce:** DORA (Digital Operational Resilience Act), NIS2 — vyžadují pravidelné testování resiliency, chaos engineering, business continuity plány.
 **AIOps v resilienci:** ML-based predikce traffic patternů, automatické škálování, proaktivní fault detection (přechod od reaktivního monitoringu k prediktivní prevenci).
 ### Zero Trust in Resilient Cloud and Network Architectures (Halley et al., ISBN 978-0-13-820460-0)
 Cisco Press — praktická příručka pro nasazení Zero Trust architektur v hybridních a cloudových prostředích.
 **Implementační rámec:**
 - **User and Device Trust** — ověření identity uživatele i zařízení před udělením přístupu (SSE — Security Service Edge).
 - **Application Access Policies** — granulární pravidla na úrovni aplikace, nikoliv IP adresy.
 - **Greenfield vs Brownfield** — nové sítě stavěné jako Zero Trust od základu vs. migrace existující infrastruktury.
 - **Automation** — Terraform, Ansible pro provisioning; Meraki, EVPN, Pub/Sub telemetrie.
 - **Industrial Zero Trust** — rozšíření konceptu do OT/ICS prostředí.
 - **Quantum security** — příprava na post-quantum kryptografii v síťových architekturách.
 ### The Segmentation Blueprint (Kulkarni, ISBN 978-0-13-546236-2)
 Cisco Press (2026) — pragmatický průvodce segmentací sítě od VLAN po nanosegmentaci.
 **Evoluce segmentace:**
 | Generace | Technologie | Rozsah |
 |----------|-------------|--------|
 | Tradiční | VLAN, ACL, firewall | Podsíť / subnet |
 | Mikrosegmentace | Security Groups, Network Policies | Workload / instance |
 | Nanosegmentace | Service mesh (Istio, Linkerd), mTLS | Aplikace / API / proces |
 **Maturity model segmentace:**
 1. **Initial** — flat network, žádná segmentace
 2. **Basic** — VLANy, firewall mezi environmenty
 3. **Defined** — Security Groups, service access policies
 4. **Managed** — Mikrosegmentace, Network Policies, EVPN
 5. **Optimized** — Nanosegmentace, service mesh, Zero Trust, AI-driven policy management
 **Klíčová metrika:** Blast radius — kolik workloadů je ohroženo při kompromitaci jednoho uzlu. Cílem je redukce na minimum.
 ### Segment Routing for SP and Enterprise Networks (Deragisch, ISBN 978-0-13-823101-9)
 Cisco Press (2024) — ucelený průvodce Segment Routingem pro MPLS i IPv6 data plane.
 **SR-MPLS vs SRv6:**
 | Vlastnost | SR-MPLS | SRv6 |
 |-----------|---------|------|
 | SID délka | 20 bit (MPLS label) | 128 bit (IPv6 address) |
 | Data plane | MPLS | IPv6 + SRH (Segment Routing Header) |
 | Signalizace | IGP (IS-IS/OSPF) extensions | IGP + BGP extensions |
 | Zrání | Mature, široce nasazeno | Emerging, standardizace dokončena |
 | Use case | SP sítě, MPLS migration | Cloud, DC, 5G, end-to-end programovatelnost |
 **Výhody SR oproti klasickému MPLS:**
 - Eliminace LDP/RSVP-TE (signaling je součástí IGP)
 - Traffic engineering state přesunutý z uzlů do packet headerů (source routing)
 - Fast reroute (FRR) bez dodatečných protokolů
 - Egress Peer Engineering (EPE) — výběr exit pointu AS
 - Mikro-loop avoidance při konvergenci
 **Migrační strategie:** Greenfield (nová síť), Brownfield (postupná migrace z MPLS), "SR in a box" — kombinace SR a LDP.
 ### Understanding and Designing Azure Networking (Stuart, Moreno, 2025)
 Praktický průvodce návrhem Azure sítí od dvou Microsoft Solution Engineers (bývalí CCIE).
 **Klíčová témata:**
 | Oblast | Klíčové služby a koncepty |
 |--------|--------------------------|
 | **Topologie** | Hub-and-spoke, Virtual WAN, multi-hub designs, Azure Route Server |
 | **Hybridní konektivita** | ExpressRoute, VPN Gateway, SD-WAN integrace |
 | **Multi-cloud** | Azure ↔ AWS/GCP, cross-cloud fabrics |
 | **Bezpečnost** | NSG, Azure Firewall, DDoS Protection, WAF, AVNM, ZTNA |
 | **DNS & PaaS** | Private Link, Private DNS Zones, Private Resolver, hybrid DNS forwarding |
 | **Application delivery** | Azure Load Balancer, App Gateway, Front Door, Traffic Manager |
 | **Monitoring** | Network Watcher, Traffic Analytics, Azure Monitor, Policy-as-code |
 **Design decision framework:** Sbírej požadavky → analyzuj constraints → vyber topologii → implementuj → monitoruj.
 ### Mastering Next-Gen Juniper Data Centers (Chatterjee, ISBN 978-0-13-533636-6)
 Addison-Wesley (2026) — hands-on průvodce EVPN VXLAN fabrikami na Juniper zařízeních.
 **Klíčové architektury:**
 - **EVPN VXLAN fabric** — multi-tenant overlay sítě s BGP EVPN control plane a VXLAN data plane.
 - **Multivendor interoperability** — detailní postupy pro EVPN napříč Juniper, Cisco NX-OS, Arista EOS.
 - **Multicast v EVPN VXLAN** — intra-subnet i inter-subnet multicast design (IGMP/MLD proxying, PIM, EVPN Type-6/7 routes).
 - **Day-2 operations** — Juniper Apstra pro automatizaci (Terraform provider), telemetrie (gNMI, OpenConfig).
 - **Service chaining** — propojení NGFW, load balancerů v rámci fabric.
 - **DCI s EVPN** — Over-the-Top (OTT) i Integrated Interconnect (VXLAN stitching, MPLS transit).
 **Evoluce od předchozí knihy (Deploying Juniper Data Centers with EVPN VXLAN, 2024):** Rozšíření o pokročilá témata — multicast, interoperability, Apstra Day-2, observability stack.
 ### Intelligent Cloud Networking: AI-Driven Resource Management (Yadav, ISBN 9364220110)
 Průnik AI/ML a cloudového network managementu (Addition Publishing, 2026).
 **Aplikace AI v síťovém managementu:**
 | Oblast | Technika | Přínos |
 |--------|----------|--------|
 | **Flow prediction** | LSTM, Transformer | Predikce traffic patternů, proaktivní škálování |
 | **Flow classification** | CNN, RL | Identifikace typů provozu pro QoS |
 | **Load balancing** | DRL (Deep RL) | Dynamická distribuce zátěže, redukce congestion |
 | **Resource management** | Q-learning, DQN | Optimalizace alokace CPU/memory/network |
 | **Routing optimization** | DRL, GNN | Adaptivní routing podle aktuálních podmínek |
 | **Congestion control** | ML-based CC | Prediktivní řízení congeste (místo reakce na loss) |
 | **Anomaly detection** | Autoencoders, Isolation Forest | Detekce útoků a anomálií v reálném čase |
 | **Blockchain security** | Smart contracts | Decentralizované řízení přístupu, audit trail |
 **Technologické směry:**
 - **Ultra Ethernet Consortium (UEC)** — nová generace Ethernetu pro AI, lossless fabric, telemetrie, adaptive routing.
 - **Path Aware Networking** — aplikace si vybírá cestu podle aktuálních podmínek (latence, loss, cena).
 - **Self-optimizing networks** — uzavřená smyčka: telemetrie → AI analýza → automatická akce → zpětná vazba.
 ## Best practices
 - **Segmentace sítě** — oddělení environmentů (dev/staging/prod), vrstev (web/app/db)
@@ -394,3 +553,5 @@ PFS (Perfect Forward Secrecy) — při kompromitaci privátního klíče nelze d
 ```
 Typický řetěz: `Leaf Cert → Intermediate CA → Root CA` (self-signed, v trust store).
 *Poslední revize: 2026-06-03*
--- a/ORACLE.md
+++ b/ORACLE.md
@@ -0,0 +1,207 @@
 # 🏛️ Oracle Database
 ## Přehled
 Oracle Database je proprietární relační databáze s nejširší škálou enterprise funkcí — RAC clustering, Active Data Guard, partitioning, advanced compression, in-memory options a Oracle Exadata integrace. Dominantní v korporátním světě, financích, telekomunikacích a mainframe ekosystému.
 ## Architektura
 ### Oracle instance + database
 ```
 Oracle Instance (memory + processes)
  ├── System Global Area (SGA)
  │   ├── Database Buffer Cache
  │   ├── Shared Pool (library cache, dictionary cache)
  │   ├── Redo Log Buffer
  │   ├── Java Pool
  │   ├── Large Pool (backup, parallel)
  │   └── In-Memory Column Store (option)
  ├── Program Global Area (PGA) — per session
  └── Background processes
      ├── PMON (process monitor)
      ├── SMON (system monitor)
      ├── DBWn (database writer)
      ├── LGWR (log writer)
      ├── CKPT (checkpoint)
      ├── ARCn (archiver)
      └── MMON (manageability monitor)
 ```
 ### Multitenant architektura (12c+)
 ```
 Container Database (CDB)
  ├── Root (CDB$ROOT) — metadata, system objects
  ├── Seed (PDB$SEED) — template pro nové PDB
  ├── Pluggable Database 1 (PDB1) — aplikace A
  ├── Pluggable Database 2 (PDB2) — aplikace B
  └── Pluggable Database 3 (PDB3) — aplikace C
 ```
 Každé PDB vypadá jako samostatná databáze, ale sdílí SGA a background procesy. Výhoda: vyšší densita, jednodušší patchování (CDB úroveň), resource management per PDB.
 ### Oracle RAC (Real Application Clusters)
 Multi-instance architektura — více serverů přistupuje ke stejné storage:
 ```text
 Node 1 ─── Oracle ASM ─── Shared Storage (SAN/NFS)
 Node 2 ─── Oracle ASM ─── Shared Storage (SAN/NFS)
 Node 3 ─── Oracle ASM ─── Shared Storage (SAN/NFS)
              │
        Cache Fusion (private interconnect)
 ```
 - Až 64 nodů v clusteru
 - **Cache Fusion** — transfer dirty blocks mezi instancemi přes private interconnect (RAC-specific)
 - **ASM** (Automatic Storage Management) — clustered filesystem + volume manager
 - **Service** — workload routing (primární, report, batch)
 ### Oracle Data Guard
 | Režim | Ochrana | Latence | Use case |
 |-------|---------|---------|----------|
 | **Maximum Protection** | Zero data loss (sync) | Nejvyšší | Kritické systémy |
 | **Maximum Availability** | Zero data loss (sync, fallback na async) | Vysoká | Enterprise standard |
 | **Maximum Performance** | Async | Nejnižší | DR na dálku |
 - **Active Data Guard** — standby pro čtení (reporting, backup) — vyžaduje licenci
 - **Far Sync** — synchronní zápis na vzdálený standby přes async (kompromis)
 ### Oracle Exadata
 Hardware+software platforma pro Oracle DB:
 | Komponenta | Popis |
 |-----------|-------|
 | **Database Servers** | x86 (Xeon), 2-8× per rack, NVMe, 1.5-6 TB RAM |
 | **Storage Servers** | Celková kapacita až 2.7 PB raw per rack |
 | **Smart Scan** | Predikátová filtrace na storage vrstvě (místo v DB serveru) |
 | **Smart Flash Cache** | Násobné vrstvy caching (RAM, Flash, disk) |
 | **RDMA over Converged Ethernet** | Nízká latence mezi DB a storage servery |
 Vhodné pro: největší OLTP, data warehousing, consolidation.
 ## Klíčové enterprise funkce
 | Funkce | Popis | Konkurence |
 |--------|-------|------------|
 | **RAC** | Shared-everything cluster až 64 uzlů | MSSQL AlwaysOn FCI (2 uzly) |
 | **Active Data Guard** | Standby pro čtení, far sync, automatic failover | MSSQL AlwaysOn AG, PostgreSQL streaming |
 | **Partitioning** | Range, List, Hash, Composite, interval, reference | PostgreSQL (declarative partitioning 10+) |
 | **Advanced Compression** | Columnar, HCC (Exadata), OLTP compression | InnoDB page compression, PG TOAST |
 | **In-Memory** | Column store v SGA pro real-time analytics | PG (no native), MSSQL (columnstore index) |
 | **Advanced Security** | TDE, data redaction, VPD, audit vault, database firewall | PG (pgcrypto, pgaudit), MSSQL (TDE, Always Encrypted) |
 | **Flashback** | Dotazování na historická data (Flashback Query, Table, Database) | PG (temporal tables via extension), MSSQL (system-versioned) |
 | **Sharding** | System-managed, composite, user-defined | MongoDB (native), Vitess (MySQL), Citus (PG) |
 | **ASM** | Clustered filesystem + volume manager | VMware VMFS, Windows CSV |
 ## Oracle licensing detail
 ### Edice
 | Edice | Metrika | Cena (orientační) | Limitace |
 |-------|---------|-------------------|----------|
 | **Oracle Database Standard Edition 2 (SE2)** | Per core (core factor 0.5) | ~$17 500/core | Max 16 CPU threads (na server), max 2 sockets, žádný RAC (pouze Oracle RAC One), žádné partitioning, in-memory, compression |
 | **Oracle Database Enterprise Edition (EE)** | Per core (core factor 0.5) | ~$47 500/core | Bez omezení, všechny funkce (RAC, partitioning, in-memory, compression, Advanced Security) — ale vše jako **volitelné licence** |
 | **Oracle Database Enterprise Edition (RAC)** | Per core (EE + RAC option) | ~$47 500 + $23 000/core | EE + RAC clustering |
 ### Volitelné licence (options) — EE only
 | Option | Cena (orientační / core) | Use case |
 |--------|--------------------------|----------|
 | **Real Application Clusters (RAC)** | ~$23 000 | Multi-instance cluster |
 | **Active Data Guard** | ~$10 000 | Standby pro čtení, far sync, automatic failover |
 | **Partitioning** | ~$11 500 | Range, list, hash, interval, reference, system |
 | **Advanced Compression** | ~$11 500 | OLTP compression, HCC (Exadata), JSON compression |
 | **Advanced Security** | ~$15 000 | TDE, data redaction, database firewall |
 | **In-Memory Database** | ~$23 000 | Column store v SGA pro real-time analytics |
 | **Database Vault** | ~$5 750 | Separation of duties, multi-tenancy security |
 | **Multitenant (EE)** | Zdarma (od 21c) | CDB/PDB — max 3 PDB na CDB v EE bez license. Neomezeno s Multitenant option (~$17 500) |
 | **Spatial / Graph** | ~$5 750 | Geoprostorová data, property graph |
 | **Label Security** | ~$5 750 | Row-level security s klasifikacemi |
 ### Oracle Cloud (OCI) licensing
 | Služba | Model | Cena | Poznámka |
 |--------|-------|------|----------|
 | **OCI Base Database (RDS-like)** | BYOL nebo License Included | ~$1-5/hod (BYOL levnější) | Single instance nebo RAC, automatické backup, patching |
 | **OCI Exadata Database Service** | BYOL nebo License Included | ~$5-30/hod (dle shape) | Exadata X9M/X10M v OCI, elastic, full Exadata features |
 | **OCI Autonomous Database** | Per CPU (ECPU) | ~$0.50-3.00/ECPU/hod | Auto-tuning, auto-scaling, auto-patching |
 | **BYOL (Bring Your Own License)** | Vlastní Oracle license v OCI | Jen infrastruktura | Lze použít stávající perpetual license, včetně supportu |
 ### RAC sizing — licence cost
 ```text
 4-node RAC, každý node 2× EPYC 9654 (96C) = 192 cores per node
  Core factor 0.5 → 96 Oracle licenses per node
  4 × 96 = 384 Oracle EE licenses
 EE: 384 × $47 500 = $18 240 000
 RAC option: 384 × $23 000 = $8 832 000
 Support 22 % ročně: ($18 240 000 + $8 832 000) × 0.22 = $5 955 840/rok
 Tip: Pro RAC zvažte menší CPU (např. 64C místo 96C) — license cost často převyšuje hardware cost.
 ```
 ### Oracle vs PostgreSQL — srovnání
 | Oblast | Oracle | PostgreSQL |
 |--------|--------|------------|
 | **Licence** | Proprietary (per core, ~$17.5k-47.5k/core + 22 % support ročně) | Open source (PostgreSQL license, MIT-like) |
 | **RAC clustering** | Nativní, shared-everything | Žádné (Citus = shared-nothing) |
 | **Multitenant** | CDB/PDB architektura | Žádné (schemas per tenant) |
 | **Parallel execution** | Vyspělý (auto DOP, parallel index scan) | Dobrý (parallel seq/index scan, join) |
 | **Storage management** | ASM (integrovaný) | OS volume / LVM |
 | **Materialized views** | S refresh on commit, query rewrite | Není query rewrite |
 | **Partitioning** | 40+ možností (interval, referential, system) | Declarative (range, list, hash od 10+) |
 | **In-memory** | Columnar in SGA | Není nativní |
 | **Standby použitek** | Active Data Guard (read-only, licence) | Hot standby (read-only, zdarma) |
 | **Cloud** | OCI (Oracle Cloud), AWS RDS, Azure | Všechny cloudy (native) |
 ## Doporučení — v čem je Oracle lepší
 | Oblast | Oracle | Konkurence | Proč Oracle |
 |--------|--------|------------|-------------|
 | **Licence cost (4-node RAC, 384 cores)** | ~$50M (1. rok vč. supportu) | PostgreSQL: $0 | Oracle: 22 % support ročně z license fee |
 | **Vendor lock-in** | Vysoký (GoldenGate migrace náročná, PL/SQL specific) | PostgreSQL: žádný | MySQL i PG mají nástroje pro migraci z Oracle (ora2pg, AWS DMS) |
 | **Enterprise OLTP** | RAC + ASM, zero-downtime patching | MSSQL (FCI limit 2 nodes) | Shared-everything cluster, transparent failover |
 | **Finance / Banking** | Audit Vault, Database Vault, TDE, VPD | PG (pgaudit, row-level security) | Compliance certifikace (SOX, PCI, GDPR) |
 | **Consolidace** | Multitenant (CDB/PDB) — stovky DB na 1 instanci | PG (citizen schemas) | Nižší overhead, jednodušší management |
 | **Data Warehouse** | Exadata Smart Scan, parallel execution, in-memory | ClickHouse (specializovaná) | Hybrid workload (OLTP + DW v jedné DB) |
 | **High-end hardware** | Exadata engineered system | PG (běží na čemkoliv) | Full-stack optimalizace HW+SW |
 | **Partitioning** | Rozsah možností (reference, interval, system) | PG (basic) | 10+ let náskok v implementaci |
 | **Flashback / recovery** | Flashback Database, Table, Query — libovolný čas | PG (PITR, point-in-time) | Rychlejší, granularnější recovery |
 | **Ekosystém** | OEM, Data Pump, SQL Developer, Toad, GoldenGate | PG (pgAdmin, pg_dump, Patroni) | Desítky let enterprise toolingu |
 ### Kdy použít Oracle
 - **Kritické OLTP systémy** — banking, payment processing, trading
 - **Enterprise konsolidace** — stovky DB na jednom RAC clusteru (multitenant)
 - **Regulované prostředí** — finance, healthcare, government (audit, security, compliance)
 - **Oracle ekosystém** — E-Business Suite, PeopleSoft, Siebel, JD Edwards
 - **Exadata zákazníci** — maximální výkon pro hybrid workload (OLTP + DW)
 - **GoldenGate replikace** — heterogenní replikace (Oracle → Kafka, Oracle → PostgreSQL)
 - **Cloud migration** — OCI, AWS RDS for Oracle, Azure Oracle Database Service
 ### Kdy použít něco jiného
 - **Startup / SME** → PostgreSQL (zdarma, dostatečný výkon, žádný vendor lock-in)
 - **Web / LAMP stack** → MySQL (jednodušší, levnější, široká podpora)
 - **Cloud-native** → Aurora, CockroachDB (architektura pro cloud, ne port on-prem do cloudu)
 - **Potřebujete jen SQL** → PostgreSQL (Oracle overhead se nevyplatí)
 - **Horizontální škálování zápisů** → Cassandra (RAC škáluje čtení, zápisy jdou přes jeden nod)
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | Oracle Database 23ai New Features | Oracle Corporation | — | Oficiální průvodce novinkami — AI Vector Search, JSON Relational Duality, property graphs, schema privileges |
 | Expert Oracle Architecture (3rd ed.) | Thomas Kyte, Darl Kuhn | 978-1484249602 | Komplexní výklad Oracle architektury — od storage po RAC a Data Guard |
 *Poslední revize: 2026-06-03*
--- a/POSTGRESQL.md
+++ b/POSTGRESQL.md
@@ -0,0 +1,178 @@
 # 🐘 PostgreSQL
 ## Přehled
 PostgreSQL je nejpokročilejší open-source relační databáze s důrazem na rozšiřitelnost, standardy SQL a spolehlivost. Vývoj od 1996, silná komunita, aktivní release cyklus (major verze každý rok).
 ## Architektura
 ### Procesový model
 ```text
 Postmaster (supervisor)
    ├── Backend process (1 per connection)
    ├── WAL writer
    ├── Checkpointer
    ├── Autovacuum launcher
    ├── Stats collector
    ├── Logical replication launcher
    └── Archiver (WAL archiving)
 ```
 Každé spojení = vlastní OS proces (ne vlákno). Výhoda: izolace, stabilita. Nevýhoda: vyšší memory footprint u tisíců spojení → nutný connection pooler (PgBouncer).
 ### MVCC (Multi-Version Concurrency Control)
 Každá transakce vidí snapshot dat z okamžiku startu. Staré verze řádků (tuple) zůstávají v tabulce:
 - 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), zhoršení výkonu index scanů, XID wraparound hazard.
 ### WAL (Write-Ahead Log)
 Append-only log všech změn pro crash recovery a replikaci:
 ```conf
 wal_level = replica                 # nebo logical
 archive_mode = on
 archive_command = 'aws s3 cp %p s3://backups/pg-wal/%f'
 ```
 **PITR (Point-In-Time Recovery)**:
 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** — zaručuje, že WAL není smazán masterem, dokud ho replica nespotřebuje
 - **Logical** — pro logickou replikaci (selektivní tabulky, transformace dat)
 - **Riziko**: pokud replica spadne, WAL naroste na disku (disk full)
 - Monitoring: `pg_replication_slots`, `pg_stat_replication`
 ### Konfigurace
 Hlavní soubory (dle Obe & Hsu):
 - `postgresql.conf` — paměť, síť, logování, storage
 - `pg_hba.conf` — přístupová práva
 - `pg_ident.conf` — mapování OS uživatelů na PostgreSQL role
 ### AI-Ready PostgreSQL 18
 (Kumar, Linster, 2026) — PostgreSQL 18 jako unified platform pro transakce, analytiku a AI:
 | Oblast | Technika |
 |--------|----------|
 | Vektory | pgvector — embeddingy přímo v řádcích tabulky |
 | Hybridní pattern | Semantic recall → SQL filtrování |
 | LLM integrace | PostgreSQL + MCP (Model Context Protocol) |
 | Embedding pipeline | Batch i stream generování embeddingů |
 **Hybridní dotaz**:
 ```sql
 SELECT p.*, pm.name
 FROM products p
 JOIN product_embeddings pe ON p.id = pe.product_id
 WHERE pe.embedding <-> '[0.1, 0.3, ...]' < 0.8
  AND p.in_stock = true
  AND p.price < 100.00
 ORDER BY pe.embedding <-> '[0.1, 0.3, ...]'
 LIMIT 10;
 ```
 ### Rozšíření (extensions)
 | Extension | Účel |
 |-----------|-------|
 | pgvector | Vektorové vyhledávání pro AI/embeddings |
 | PostGIS | Geografická data, prostorové dotazy |
 | pg_stat_statements | Monitoring výkonu dotazů |
 | pg_duckdb | Analytické dotazy (DuckDB engine uvnitř PG) |
 | pg_search | Full-text a hybridní vyhledávání |
 | pg_cron | Scheduling úloh v DB |
 | citus | Horizontální škálování (sharding) |
 | timescaledb | Time-series optimalizace |
 | pgaudit | Auditní logování |
 ## Connection pooling
 | Pooler | Typ | Protokol |
 |--------|-----|----------|
 | PgBouncer | Proxy (transaction/session) | PostgreSQL wire |
 | Odyssey | Proxy (multithreaded) | PostgreSQL wire |
 | pgpool-II | Proxy (replication, load balancing) | PostgreSQL wire |
 | RDS Proxy | Managed proxy (AWS) | PostgreSQL wire |
 **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)
 ## Doporučení — v čem je PostgreSQL lepší
 | Oblast | PostgreSQL | Konkurence | Proč PG |
 |--------|-----------|------------|---------|
 | **Rozšiřitelnost** | Extensions, custom types, operators, index methods | MySQL omezené | Lze přidat cokoliv od vektorů po full-text v DB |
 | **SQL standard** | Nejbližší ANSI SQL | MySQL odbočky (GROUP BY, ALTER TABLE) | Přenositelnost, méně překvapení |
 | **Geoprostorová data** | PostGIS (zlatý standard GIS) | MySQL GIS (omezený) | Jediná reálná open-source volba pro GIS |
 | **Konzistence** | SSI serializable, foreign keys, CHECK, exclusions | MySQL MyISAM bez FK, InnoDB jen RC | Vhodné pro finanční a kritické systémy |
 | **Concurrent读写** | MVCC bez reader/writer blokování | MySQL InnoDB reader blokuje writer (a naopak) u starších verzí | Lepší škálovatelnost čtení |
 | **AI/vektory** | pgvector nativně v DB | Samostatná vektorová DB (zvýšení latence) | Hybridní dotazy v jediném SQL |
 | **Licence** | PostgreSQL license (MIT-like) | MySQL dvojí licence (Oracle) | Žádná vendor lock-in |
 ### Kdy použít PostgreSQL
 - **Enterprise aplikace** — vyžadují ACID, referenční integritu, komplexní transakce
 - **Geografické systémy** — GIS, mapové aplikace, lokalitní služby
 - **Finanční systémy** — účetnictví, banking, compliance (audit logging, SSI)
 - **AI / RAG aplikace** — hybridní vektorové + relační dotazy v jedné DB
 - **Analytika na relačních datech** — pg_duckdb, materializované views, window functions
 - **Multi-tenant aplikace** — row-level security, schemas per tenant
 ## PostgreSQL licensing
 | Varianta | Licence | Cena | Omezení |
 |----------|---------|------|---------|
 | **PostgreSQL** | PostgreSQL license (MIT-like) | $0 | Žádná — lze používat, modifikovat, distribuovat v komerčních produktech. Není potřeba žádný "commercial license" |
 | **Amazon Aurora PostgreSQL** | Proprietary (AWS) | ~$0.10-1.00/hod | AWS managed, PostgreSQL compatible. AWS smí používat PG kód díky PostgreSQL license |
 | **YugabyteDB** | Apache 2.0 | $0 (core) | PostgreSQL kompatibilní distributed SQL, postaveno na PG query layer |
 | **TimescaleDB** | Apache 2.0 (community) / Timescale License (enterprise) | $0 (community) | Časově řadová rozšíření PostgreSQL. Enterprise: tiered storage, compression, multi-node |
 **Klíčové**: PostgreSQL license je jedna z nejliberálnějších — umožňuje cloud providerům (AWS, GCP, Azure) nabízet PostgreSQL jako managed službu bez omezení. To je rozdíl oproti MongoDB (SSPL) a Redis (RSALv2). Díky tomu má PostgreSQL nejširší cloud podporu ze všech databází.
 **Dopad na výběr**: Žádný license risk, žádný vendor lock-in, žádné skryté náklady. PostgreSQL je bezpečná volba pro jakýkoliv projekt.
 ### Kdy použít něco jiného
 - **Jednoduchý web / blog** → SQLite (v embedded scénáři lehčí)
 - **High-throughput key-value** → Redis (o řád nižší latence)
 - **Time-series v masivním měřítku** → TimescaleDB, InfluxDB
 - **Globálně distribuovaná data** → CockroachDB, Spanner
 - **Full-text search primárně** → Elasticsearch
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | PostgreSQL: Up and Running (3rd ed.) | Regina Obe, Leo Hsu | 978-1491962935 | Praktický průvodce administrací, konfigurací a extensions |
 | AI-Ready PostgreSQL 18 | Kumar, Linster | — | PostgreSQL jako unified platform pro AI workloads |
 *Poslední revize: 2026-06-03*
--- a/PROVISIONING.md
+++ b/PROVISIONING.md
@@ -32,7 +32,7 @@ subnet 10.0.0.0 netmask 255.255.255.0 {
 - Scriptable: `chain http://boot.example.com/script.ipxe`
 - Embedded: iPXE ROM flashnutá přímo do NIC
-### Vergleich PXE vs iPXE
+### Porovnání PXE vs iPXE
 | Vlastnost | PXE | iPXE |
 |-----------|-----|------|
@@ -147,7 +147,7 @@ GET /redfish/v1/Chassis/1/Thermal
 ## Terraform pro provisioning
-```
+```hcl
 # Terraform provider pro VMware vSphere
 provider "vsphere" {
  user           = var.vsphere_user
@@ -193,3 +193,5 @@ Více v [CICD.md](CICD.md).
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 *Poslední revize: 2026-06-03*
--- a/REDIS.md
+++ b/REDIS.md
@@ -0,0 +1,119 @@
 # 🔴 Redis
 ## Přehled
 Redis je in-memory key-value store s pokročilými datovými strukturami, používaný primárně jako cache, session store, message broker a real-time databáze. Běží v RAM s možností persistence na disk (RDB/AOF).
 ## 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 |
 | **Geospatial** | Geo-indexing (GEOADD, GEOSEARCH) | Lokalitní dotazy, proximity search |
 | **JSON** | JSON dokument (RedisJSON modul) | Dokumentové struktury |
 ## Eviction policies
 | 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í |
 ## Redis Cluster vs Sentinel
 | 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í |
 ## Persistence
 | Metoda | Popis | RTO | RPO | Use case |
 |--------|-------|-----|-----|----------|
 | **RDB** (Redis Database) | Periodický snapshot do dump.rdb | Minuty | Poslední snapshot | Cache, ztráta tolerována |
 | **AOF** (Append-Only File) | Append-only log všech write operací | Sekundy | 1 s (fsync every sec) | Data nesmí být ztracena |
 | **RDB + AOF** | Kombinace | Sekundy | 1 s | Doporučeno pro produkci |
 ## Moduly (RediSearch, RedisJSON, RedisGraph)
 Redis rozšiřitelný modulem:
 - **RediSearch** — full-text search, facety, prefix/suffix vyhledávání
 - **RedisJSON** — JSON path dotazy, manipulace dokumentů
 - **RedisGraph** — grafová DB (na bázi Cypher, deprecated od 2025)
 - **RedisTimeSeries** — time-series s downsamplingem, retention politikami
 - **RedisBloom** — Bloom filtry, Cuckoo filtry, Top-K, Count-Min Sketch
 ## Memcached vs Redis
 | Vlastnost | Redis | Memcached |
 |-----------|-------|-----------|
 | **Data structures** | String, Hash, List, Set, Sorted Set, Stream, JSON | Pouze String |
 | **Persistence** | RDB + AOF | Žádná (čistě in-memory) |
 | **Replication** | Master-replica, Cluster | Žádná (multi-threaded) |
 | **Eviction** | 6 politik | LRU pouze |
 | **Lua scripting** | Ano (EVAL) | Ne |
 | **Transakce** | Ano (MULTI/EXEC) | Ne |
 | **Pub/Sub** | Ano | Ne |
 | **Streaming** | Ano (Stream) | Ne |
 ## Doporučení — v čem je Redis lepší
 | Oblast | Redis | Konkurence | Proč Redis |
 |--------|-------|------------|------------|
 | **Cache (in-memory)** | < 1 ms latence, 6 eviction politik | Memcached (pouze LRU string) | Bohatší datové typy, persistence, cluster |
 | **Session store** | Hash + TTL, Cluster pro HA | DynamoDB (vyšší latence) | Jednodušší, rychlejší, nativní expirace |
 | **Rate limiting** | Sorted Set (sliding window counter) | Aplikace v DB (složité) | Atomic operace, vestavěná logika |
 | **Leaderboard / scoring** | Sorted Set (ZADD, ZRANK, ZREVRANGE) | SQL (ORDER BY + COUNT = expensive) | O(1) rank, O(log N) insert |
 | **Message queue** | List/Stream (RPUSH+BLPOP) | Kafka (těžká, JVM) | Lehká, embedded, žádný broker |
 | **Real-time analytics** | HyperLogLog + Bitmap + Stream | ClickHouse (těžká analytika) | Agregace v reálném čase, malá RAM |
 | **Geolokace** | GEOADD, GEOSEARCH, GEODIST | PostGIS (těžší, disk-based) | In-memory, ideální pro real-time |
 ### Kdy použít Redis
 - **Cache pro API** — response cache, DB query cache, session cache
 - **Session management** — distribuované session napříč servery
 - **Rate limiting** — API gateway, per-user/per-IP limity
 - **Leaderboardy / žebříčky** — real-time skórování
 - **Message broker** — fronta úloh (RQ, Celery s Redis), pub/sub notifikace
 - **Real-time analytics** — počítání unikátů, metrik, dashboardů
 - **Geoproxmity** — "najdi nejbližší pobočku" v < 1 ms
 ### Kdy použít něco jiného
 - **Trvalá data s SQL dotazy** → PostgreSQL nebo MySQL
 - **Velké objemy > RAM** → Memcached (multi-threaded), Dragonfly (více RAM utilization)
 - **Dlouhodobá fronta zpráv** → Kafka, RabbitMQ (disk-based persistence)
 - **Dokumentová DB** → MongoDB (persistentní, komplexní dotazy)
 ## Redis licensing
 Redis prošel zásadní změnou licence v roce 2024:
 | Období | Licence | Podmínky |
 |--------|---------|----------|
 | **Do března 2024** | BSD 3-clause (open source) | Zcela volné použití, včetně managed služeb |
 | **Od března 2024** | RSALv2 + SSPL (dual license) | SSPL: pokud nabízíte Redis jako managed službu, musíte uvolnit celý stack jako open source. RSALv2: omezení na cloud provozovatele |
 | **Valkey (fork, Linux Foundation)** | BSD 3-clause | Plně open source fork Redis 7.2, podpora od Linux Foundation, AWS, Google, Oracle |
 **Dopad**: Managed Redis služby (AWS ElastiCache, Google Memorystore, Azure Cache for Redis) nemohou používat Redis 7.4+ bez komerční licence → přechází na **Valkey**. Pro self-hosted Redis beze změny — RSALv2/SSPL neomezuje interní použití.
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 *Poslední revize: 2026-06-03*
--- a/SERVER-CONFIG.md
+++ b/SERVER-CONFIG.md
@@ -11,7 +11,7 @@
 | **SR-IOV** | Enabled | GPU, NIC passthrough |
 | **NUMA** | Enabled | NUMA-aware scheduling |
 | **ACPI** | Enabled | Power management, OS-level |
-| **Security Boot** | Enabled | Secure boot chain |
+| **Secure Boot** | Enabled | Secure boot chain |
 | **TPM** | Enabled | Measured boot, key storage |
 ---
@@ -27,118 +27,546 @@
 | **In-memory** (Redis, Memcached) | High clock, low cache latency | Single-threaded (Redis), RAM bandwidth |
 | **Document** (MongoDB) | Balance (clock × cores) | Mixed workload |
 | **Distributed** (Cassandra, Scylla) | Many cores, high cache | Shard-per-core (Scylla), compaction |
 | **Oracle OLTP** | High clock, moderate cores, core-factor aware | CPU license cost (core factor 0.5 pro AMD EPYC i Intel Xeon) |
 | **Oracle OLAP / DW** | Many cores, large SGA, in-memory option | Parallel query, Exadata Smart Scan, compression |
-### Storage layout
+### Oracle CPU licensing — core factor
 Oracle licencuje na jádro s korekčním faktorem dle procesoru. Faktor 0.5 znamená, že 2 jádra = 1 Oracle license.
 | Procesor | Core factor | 64 fyzických jader → Oracle licencí |
 |----------|-------------|--------------------------------------|
 | AMD EPYC (všechny řady) | 0.5 | 32 |
 | Intel Xeon (Scalable) | 0.5 | 32 |
 | IBM POWER | 1.0 | 64 |
 | ARM (Ampere Altra) | 0.5 | 32 |
 **Dopad na výběr CPU**: Při stejném Oracle license cost je EPYC s více jádry výhodnější — dostanete více compute power za stejnou license cenu.
 ### Konfigurace podle velikosti firmy a typu storage
 #### Varianta A: Malá firma — lokální NVMe RAID
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 1× EPYC 9124/9224 nebo Intel Xeon 4410Y (8-16C) | 1 socket, high clock |
 | **RAM** | 64-256 GB (8-16 GB/core) | DDR5-4800, 1DPC |
 | **OS disk** | 2× SATA/SAS SSD, RAID 1 (240-480 GB) | Pro OS + binární soubory |
 | **Data disk** | 4-6× NVMe (U.2/E3.S), RAID 10 | Lokální data, žádné sdílení |
 | **WAL disk** | 2× NVMe RAID 1 (400-800 GB) | Pouze PostgreSQL |
 | **Network** | 2× 25 GbE (LACP) | Aplikační traffic + management |
 | **Form factor** | 1U nebo 2U | Single node, žádný cluster |
 | **Storage backend** | Lokální RAID controller (PERC/Broadcom) | HW RAID 10 nebo SW RAID (mdadm) |
 | **HA** | Aplikace řídí failover (patroni, repmgr, orchestrator) | Standby node při selhání |
 **Use case**: Startup, pobočka, dev/test, < 500 uživatelů, jeden databázový server, nízké nároky na dostupnost.
 #### Varianta B: Střední firma — lokální NVMe + asynchronní replikace
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 1-2× EPYC 9334/9374F nebo Intel Xeon 5418Y (16-24C) | 1-2 socket, balanced |
 | **RAM** | 128-512 GB (8-16 GB/core) | DDR5-4800/5600, 1DPC |
 | **OS disk** | 2× NVMe RAID 1 (2× 480 GB) | OS + binárky |
 | **Data disk** | 6-8× NVMe, RAID 10 | Lokální NVMe, 3-6 TB usable |
 | **WAL disk** | 2× NVMe RAID 1 (2× 800 GB) | Oddělený od data |
 | **Network** | 2× 25 GbE (app) + 2× 25 GbE (replication) | Aplikační a replikační síť odděleny |
 | **Form factor** | 2U | Primární + replica node |
 | **Storage backend** | SW RAID (mdadm) nebo HW RAID (PERC H965) | Write-back cache s BBU |
 | **HA** | Patroni / repmgr / MySQL InnoDB Cluster | Asynchronní replikace na 1-2 standby |
 **Use case**: E-commerce, SaaS střední velikosti, 500-5000 uživatelů, RPO < 1 min, RTO < 5 min.
 #### Varianta C: Velká firma — FC SAN (enterprise)
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 2× EPYC 9654/9965 nebo Xeon 8592+/6980P (48-128C) | 2 socket, max cores, large cache |
 | **RAM** | 512 GB - 2 TB (8-16 GB/core) | DDR5, 2DPC (penalizace speed), 12 channelů (EPYC) |
 | **OS disk** | 2× SATA SSD RAID 1 (2× 480 GB) | Pouze OS, data na SAN |
 | **Data + WAL** | LUNy z FC SAN | Hitachi VSP / Dell PowerMax / Pure //X |
 | **HBA** | 2× dual-port FC HBA (32/64 Gb) | Multipath (active-active), FC-NVMe |
 | **Network** | 2× 25/100 GbE (app) + 2× 32/64 Gb FC (storage) | App i storage síť odděleny |
 | **Form factor** | 2U | 2-8 node cluster (RAC, AlwaysOn AG) |
 | **Storage backend** | FC SAN — LUN per databáze | Thin provisioning, RAID na SAN, snapshots |
 | **HA** | Oracle RAC / SQL Server AOAG / PostgreSQL Patroni | Synchronní replikace, FC multipath |
 **Výhody SAN**: Centrální management, snapshots, cloning, disaster recovery (SRDF/Metro), oddělená storage síť, vyšší dostupnost.
 **Nevýhody**: Vyšší latence oproti lokálnímu NVMe (~50-200 µs přes SAN vs ~10 µs local NVMe), vyšší CAPEX, vendor lock-in.
 #### Varianta D: Velká firma — Ceph / SDS backend
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 2× EPYC 9334/9654 (16-32C) | Méně cores než SAN varianta — část CPU jde na Ceph client |
 | **RAM** | 256-512 GB | Méně RAM — Ceph client cache není tak efektivní jako lokální buffer |
 | **OS disk** | 2× SATA SSD RAID 1 (2× 480 GB) | OS |
 | **Network** | 2× 25/100 GbE (app) + 2× 25/100 GbE (Ceph public) | App i Ceph traffic po Ethernetu |
 | **HBA** | Storage HBA v IT/HBA mode (žádný RAID) | Pro Ceph OSD node, ne DB node |
 | **Form factor** | 2U | DB nod + separátní Ceph OSD nod |
 | **Storage backend** | RBD (RADOS Block Device) přes Ceph | 3× replikace nebo erasure coding |
 | **HA** | Aplikace + Ceph inherentní HA | Ceph self-healing, auto-rebalance |
 **Výhody Ceph**: Žádný vendor lock-in, horizontální škálování, jednotná platforma pro block/file/object, nižší CAPEX.
 **Nevýhody**: Vyšší latence a CPU režie (Ceph client → network → OSD), variabilní výkon, složitější troubleshooting.
 #### Varianta E: Cloud — RDS / CloudSQL / Azure SQL
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **Compute** | AWS RDS (db.r7g/r8g), Azure SQL (GP/BC/Hyperscale) | Managed service, bez přístupu k OS |
 | **Storage** | EBS gp3 / io2, Azure Premium SSD v2, Cloud SQL SSD | Automatické škálování, PITR, multi-AZ |
 | **Network** | Security Group, Private Link, VPC peering | Žádný HBA, žádná SAN — vše přes Ethernet |
 | **HA** | Multi-AZ (synchronní), read replicas | Managed failover, RTO < 60 s |
 | **Backup** | Automated, PITR (7-35 dní) | Bez nutnosti managementu |
 **Use case**: Žádný on-prem hardware, elastické škálování, pay-per-use, menší provozní režie.
 **Nevýhody**: Vyšší dlouhodobé náklady, data residency, network latency, limited customization.
 ### Srovnání variant
 | Aspekt | Lokální NVMe (malá) | Lokální NVMe (střední) | FC SAN | Ceph | Cloud |
 |--------|---------------------|----------------------|--------|------|-------|
 | **Latence** | ~10 µs | ~10 µs | ~50-200 µs | ~100-500 µs | ~100-1000 µs |
 | **Škálování** | Vertikální | Vertikální | Horizontální | Horizontální | Elastické |
 | **CAPEX** | Nízký | Střední | Vysoký | Střední | Žádný (OPEX) |
 | **Provozní režie** | Nízká | Nízká | Vysoká (SAN admin) | Střední | Žádná |
 | **HA** | Aplikace | Patroni/Cluster | RAC/AOAG | Ceph HA | Managed |
 | **RPO** | 1-5 min | < 1 min | < 10 s | < 30 s | < 60 s |
 | **RTO** | 5-15 min | < 5 min | < 2 min | < 5 min | < 60 s |
 | **Počet serverů** | 1-2 | 2-4 | 4-16 | 6-20+ | 0 (managed) |
 | **Firma** | Startup/SME | SME/Enterprise | Enterprise | Enterprise | Libovolná |
 ### PostgreSQL parameter matrix podle storage typu
 | Parametr | Local NVMe | FC SAN | Ceph RBD |
 |----------|-----------|--------|----------|
 | `random_page_cost` | 1.1 | 1.5-2.0 | 2.0-3.0 |
 | `effective_io_concurrency` | 300 | 100-200 | 50-100 |
 | `synchronous_commit` | off (NVMe cache) | on (SAN cache) | off (Ceph cache) |
 | `full_page_writes` | on | on | on (i přes Ceph) |
 ### Storage layout podle typu backendu
 **Lokální NVMe (malá/střední):**
 ```
-Mount point    FS       RAID     Disk type    Účel
+Mount point    FS       RAID       Disk            Účel
-─────────────  ─────    ─────    ──────────   ──────────────────
+/               ext4    1 (mirror) 2× SATA SSD     OS
-/               ext4    1 (mirror)  2× SSD    OS, binární soubory
+/data           xfs     10          4-8× NVMe       Data
-/data           xfs     10 (stripe) 4-8× NVMe Databázová data
+/wal            xfs     1 (mirror) 2× NVMe          WAL (PG)
 /wal            xfs     1 (mirror) 2× NVMe   Write-ahead log (PostgreSQL)
 /tmp            tmpfs   —          RAM       Dočasné soubory
 ```
-### PostgreSQL specific
+**FC SAN (enterprise):**
 ```
 Mount point    FS       Device                   Účel
 /               ext4    local RAID 1 (2× SSD)     OS
 /dev/sdb        xfs     FC LUN 1 (500 GB)         WAL (PG)
 /dev/sdc        xfs     FC LUN 2 (2 TB)           Data
 /dev/sdd        xfs     FC LUN 3 (2 TB)           Indexy (oddělené)
 ```
-| Parametr | Doporučení | Poznámka |
+**Ceph RBD:**
 ```
 Mount point    FS       Ceph device               Účel
 /               ext4    local RAID 1 (2× SSD)     OS
 /dev/rbd0       xfs     rbd datastore-01          Data + WAL (Ceph RBD)
 ```
 ### Kernel tuning podle variants
 **Lokální NVMe:**
 ```
 vm.dirty_ratio = 30
 vm.dirty_background_ratio = 5
 ```
 **FC SAN:**
 ```
 # SAN storage — vyšší latency, méně agresivní flush
 vm.dirty_ratio = 20
 vm.dirty_background_ratio = 3
 vm.dirty_expire_centisecs = 3000   # Defer writes (SAN cache)
 ```
 **Ceph RBD:**
 ```
 # Ceph RBD — network storage, optimalizovat pro RBD cache
 vm.dirty_ratio = 15
 vm.dirty_background_ratio = 2
 # RBD cache settings
 # rbd cache = true (client-side)
 # rbd cache size = 256-512 MB
 ```
 ### Database-specific tuning
 | Parametr | PostgreSQL | MySQL | Oracle | MongoDB |
 |----------|-----------|-------|--------|---------|
 | **Cache** | `shared_buffers` 25 % RAM | `innodb_buffer_pool` 70-80 % RAM | `SGA_TARGET` 60-80 % RAM | `WiredTiger cache` 50-80 % RAM |
 | **OS cache** | `effective_cache_size` 75 % RAM | OS cache + InnoDB | OS cache (double buffering risk při large SGA) | OS cache |
 | **Write buffer** | `wal_buffers` 64-256 MB | `innodb_log_file_size` 1-4 GB | Redo log (2-4 groups, 200 MB-4 GB) | WiredTiger log |
 | **Connections** | `max_connections` 50-500 | `max_connections` 100-500 | `processes` 200-2000 | maxIncomingConnections |
 | **I/O** | `effective_io_concurrency` 200 | `innodb_io_capacity` 2000 | `db_file_multiblock_read_count` 128 | WiredTiger eviction |
 | **Huge pages** | `huge_pages = try` | `large-pages = ON` | `use_large_pages = only` (mandatory) | transparent_hugepages=never |
 | **Parallel query** | `max_parallel_workers` 4-8 | `innodb_parallel_read_threads` 4 | `parallel_degree_policy = auto` — až 64 | — |
 ### Connectivity per variant
 | Varianta | App síť | Storage síť | Replikace | Management |
 |----------|---------|-------------|-----------|------------|
 | **Lokální (malá)** | 2× 25 GbE LACP | — | 2× 25 GbE (same) | iDRAC/iLO |
 | **Lokální (střední)** | 2× 25 GbE LACP | — | 2× 25 GbE dedik. | iDRAC/iLO |
 | **FC SAN** | 2× 25/100 GbE | 2× 32/64 Gb FC (multipath) | FC replication | iDRAC/iLO + SAN mgmt |
 | **Ceph** | 2× 25/100 GbE | 2× 25/100 GbE (public net) | 2× 25/100 GbE (cluster net) | iDRAC/iLO + Ceph mgmt |
 | **Cloud** | Elastic IP / Private Link | — | — | AWS Console / API |
 | **Oracle Standalone** | 2× 25 GbE LACP | ASM (2× 25 GbE nebo FC 32G) | Data Guard 2× 25 GbE | iLO + ASM mgmt |
 | **Oracle RAC** | 2-4× 25/100 GbE | 2× 64 Gb FC (multipath) | Cache Fusion interconnect | iLO + SAN mgmt |
 | **Oracle Exadata** | 4-8× 100 GbE RoCE | NVMe over Fabric | RDMA interconnect | Exadata CLI + OEDA |
 ### Oracle-specific konfigurace
 #### Oracle ASM — diskgroup layout
 Oracle ASM (Automatic Storage Management) nahrazuje tradiční filesystem + volume manager:
 | Diskgroup | Redundancy | Disky | Účel |
 |-----------|-----------|-------|-------|
 | **DATA** | Normal (2× mirror) | 4-12× FC LUN/NVMe | Data files, temp files, control files |
 | **FRA** (Flash Recovery Area) | Normal (2× mirror) | 2-6× FC LUN/NVMe | Archive logs, backup, flashback logs |
 | **REDO** | High (3× mirror) | 2-4× FC LUN/NVMe | Online redo log groups (I/O kritické) |
 | **SPFILE** | Normal | 2× small LUN | Server parameter file |
 **ASM striping**: Coarse (1 MB) pro běžná data, Fine (128 KB) pro redo logy (nižší latence zápisu).
 #### Varianta O1: Standalone Oracle (malá/střední, single instance)
 | Parametr | Small (< 500 users) | Medium (500-2000 users) |
 |----------|---------------------|------------------------|
 | **CPU** | 1-2× EPYC 9124-9224 / Xeon 4410Y (8-16C) | 2× EPYC 9334-9374F / Xeon 5418Y (16-24C) |
 | **RAM (SGA + PGA)** | 64-128 GB (SGA 70 %, PGA 30 %) | 128-512 GB (SGA 60-80 %, PGA 20-40 %) |
 | **Huge pages** | Ano (vm.nr_hugepages) — mandatory pro SGA | Ano |
 | **OS disk** | 2× SATA SSD RAID 1 (240 GB) | 2× NVMe RAID 1 (480 GB) |
 | **DATA + FRA** | 4-6× NVMe, ASM normal redundancy | 6-8× NVMe nebo FC LUN, ASM normal |
 | **REDO** | 2-4× NVMe (oddělené od DATA), ASM high | 4× FC LUN (oddělené), ASM high |
 | **Archive log** | Lokální FRA | FC LUN (FRA diskgroup) |
 | **Network (app)** | 2× 25 GbE LACP | 2-4× 25/100 GbE LACP |
 | **Network (storage)** | — (lokální NVMe) | 2× FC 32G multipath |
 | **Network (Data Guard)** | — | 2× 25 GbE dedikované |
 | **DB version** | Oracle SE2 (max 16 threads) | Oracle EE (neomezené) |
 **Use case**: Dev/test, malé produkční DB, pobočky. SE2 license = max 16 CPU threads, limitovaná parallel execution.
 #### Varianta O2: Oracle Data Guard (střední/velká, HA + DR)
 Primární + standby v active-passive režimu, možnost Active Data Guard pro reporting.
 | Parametr | Doporučení |
 |----------|-----------|
 | **CPU** | 2× EPYC 9654-9965 / Xeon 8592+ (32-64C) |
 | **RAM** | 256-1024 GB (SGA 60-80 %, PGA 20-40 %) |
 | **Huge pages** | Ano (50-80 % RAM alokováno pro SGA) |
 | **OS disk** | 2× NVMe RAID 1 (480 GB) |
 | **Storage** | FC SAN LUN (DATA + FRA + REDO odděleně) nebo NVMe + ASM |
 | **HBA** | 2× dual-port FC 32/64 Gb (multipath active-active) |
 | **App network** | 2-4× 25/100 GbE LACP |
 | **Storage network** | 2× FC 32/64 Gb multipath |
 | **Data Guard network** | 2× 25/100 GbE dedikované (sync nebo async) |
 | **Data Guard režim** | Maximum Availability (sync, fallback na async) — RPO = 0 |
 | **Topologie** | 1 primary + 1-2 standby (physical), far sync pro geo-DR |
 | **Active Data Guard** | Standby otevřená pro čtení (reporting, backup) — vyžaduje ADG licenci |
 **Latence Data Guard**:
 ```text
 Synchronní (Maximum Availability):
  Primární COMMIT → LGWR flush REDO → sync přes síť → Standby LGWR → ACK → ~1-5 ms
  RPO = 0, dopad na latenci zápisu
 Asynchronní (Maximum Performance):
  Primární COMMIT → LGWR flush REDO → async do standby buffer → ~0.1-1 ms
  RPO = několik sekund, zanedbatelný dopad na zápis
 ```
 **Síťové požadavky pro Data Guard sync**:
 - RTT < 2 ms pro synchronní režim (doporučeno < 1 ms)
 - Min. 10 GbE, doporučeno 25 GbE (propustnost = REDO rate × 2)
 - REDO rate: OLTP ~50-500 MB/s, batch ~500-2000 MB/s
 - Při REDO rate 500 MB/s a 25 GbE → ~20 % link utilization
 #### Varianta O3: Oracle RAC (velká, enterprise)
 Multi-instance cluster se shared storage a Cache Fusion.
 | Parametr | Doporučení |
 |----------|-----------|
 | **Počet nodů** | 2-4 (typicky), max 64 (RAC cluster) |
 | **CPU per node** | 2× EPYC 9654-9965 / Xeon 8592+ (32-64C) |
 | **RAM per node** | 512-2048 GB (SGA 60-80 %, PGA 20-40 %) |
 | **Huge pages** | Ano (1 GB stránky pokud RAM > 512 GB) |
 | **Storage** | FC SAN — shared LUNs (ASM normal/high redundancy) |
 | **HBA** | 2× dual-port FC 64 Gb (multipath, active-active) |
 | **App network** | 2-4× 25/100 GbE LACP (VIP, SCAN listener) |
 | **Storage network** | 2-4× FC 64 Gb (multipath per node) |
 | **Cache Fusion interconnect** | 2× 100 GbE (RoCE v2 nebo InfiniBand) — dedikovaný |
 | **RAC interconnect latency** | < 5 µs (doporučeno), max < 10 µs |
 | **ASM** | Normal redundancy (2-way mirror) |
 | **Oracle Clusterware** | Voting disk (3× 1 GB LUN), OCR (3× 500 MB LUN) |
 | **Service** | OLTP_service, REPORT_service, BATCH_service |
 **Cache Fusion — kritický interconnect**:
 ```
 Node A (DB instance) ←──→ Node B (DB instance)
       │                        │
       └──────── ASM ───────────┘
              │
        FC SAN (shared storage)
 Cache Fusion traffic: dirty block transfer mezi instancemi
  → Latence < 5 µs, jinak RAC škálování degraduje
  → Kapacita: 2× 100 GbE, dedikovaný switch nebo InfiniBand HDR100
  → Doporučená MTU: 9000 (jumbo frames)
 ```
 **RAC sizing podle počtu transakcí**:
 | TPS | Nodů | CPU per node | RAM per node | Interconnect |
 |-----|------|-------------|-------------|-------------|
 | < 10 000 | 2 | 16-24C | 256 GB | 2× 25 GbE |
 | 10 000 - 50 000 | 2-4 | 32-48C | 512 GB | 2× 100 GbE RoCE |
 | 50 000 - 200 000 | 4-8 | 48-64C | 1024 GB | 2× 100 GbE RoCE / InfiniBand |
 | > 200 000 | 8+ | 64-128C | 2048 GB | InfiniBand HDR100/HDR200 |
 **RAC sizing — výpočet licence cost**:
 ```text
 Příklad: 4-node RAC, každý node 2× EPYC 9654 (96C) = 192 cores per node
  Core factor 0.5 → 96 Oracle licenses per node
  4 × 96 = 384 Oracle EE licenses
  Pri ~$47.5k/license → ~$18.2M (jen licence, bez supportu 22 % ročně)
 ```
 #### Varianta O4: Oracle Exadata (hyperscale)
 Engineered system — optimální pro hybrid workload (OLTP + DW).
 | Parametr | X9M / X10M | Use case |
 |----------|-----------|----------|
-| `shared_buffers` | 25 % RAM | Cache databázových bloků |
+| **Database servers** | 2-8× (Xeon, 1.5-6 TB RAM, NVMe) | Compute |
-| `effective_cache_size` | 75 % RAM | Odhad OS cache pro query planner |
+| **Storage servers** | 3-18× (NVMe + HDD, Smart Scan) | Offloading predikátů |
-| `work_mem` | 4-64 MB per operation | SORT, HASH JOIN (correlate s max_connections) |
+| **Smart Scan** | Filtrace na storage vrstvě | Méně dat po síti, vyšší propustnost |
-| `maintenance_work_mem` | 1-10 % RAM | VACUUM, CREATE INDEX, ANALYZE |
+| **RoCE interconnect** | 100 GbE (RDMA) | Nízká latence, high bandwidth |
-| `wal_buffers` | 64-256 MB | Write-ahead log buffer |
+| **In-Memory Column Store** | Volitelná licence | Real-time analytics bez ETL |
-| `max_connections` | 50-500 | Connection pooling (PgBouncer) |
+| **HCC (Hybrid Columnar Compression)** | Compression v storage serverech | Až 10-15× komprese pro DW |
-| `random_page_cost` | 1.1 (NVMe), 4 (HDD) | Index scan cost (NVMe = téměř seq scan) |
+| **Rack power** | ~15-30 kW (full rack) | Vyšší densita |
 | `effective_io_concurrency` | 200 (NVMe), 2 (HDD) | Parallel I/O |
-### MySQL / MariaDB specific
+**Kdy zvolit Exadata místo standalone RAC**:
-
+- OLTP > 50 000 TPS
-| Parametr | Doporučení | Poznámka |
+- Potřeba konsolidace (více DB na jeden cluster)
-|----------|-----------|----------|
+- Smart Scan výrazně zrychluje reporting na produkčních datech
-| `innodb_buffer_pool_size` | 70-80 % RAM | Hlavní cache InnoDB |
+- HCC pro úsporu storage u DW workloadů
 | `innodb_log_file_size` | 1-4 GB | Redo log, čím větší tím lepší write perf |
 | `innodb_flush_log_at_trx_commit` | 1 (ACID) / 2 (perf) | 1 = fsync každou transakci |
 | `innodb_io_capacity` | 2000 (NVMe) / 200 (HDD) | IOPS limit |
 | `innodb_write_io_threads` | 4-8 | Parallel write threads |
 | `max_connections` | 100-500 | Connection pooling doporučen |
 ### MongoDB specific
 | Parametr | Doporučení | Poznámka |
 |----------|-----------|----------|
 | **WiredTiger cache** | 50-80 % RAM | Storage engine cache |
 | **WiredTiger compression** | Snappy / Zstd | Komprese disku (zlib je pomalý) |
 | `filesystem` | XFS | Doporučený FS (ext4 OK, NTFS ne) |
 | **ReadConcern/WriteConcern** | majority/majority | Pro důležitá data |
 ### Kernel tuning pro DB
 ```
 # /etc/sysctl.d/99-database.conf
 vm.swappiness = 1              # Minimalizuj swap, preferuj cache
 vm.dirty_ratio = 30            # % RAM before background flush
 vm.dirty_background_ratio = 5  # Start flush at 5 %
 vm.nr_hugepages = 0            # Huge pages pokud DB podporuje (PostgreSQL, MongoDB)
 net.core.rmem_max = 134217728
 net.core.wmem_max = 134217728
 net.ipv4.tcp_rmem = 4096 87380 134217728
 net.ipv4.tcp_wmem = 4096 65536 134217728
 net.core.somaxconn = 4096
 # I/O scheduler (NVMe = none, SSD = mq-deadline, HDD = kyber/bfq)
 # echo none > /sys/block/nvme0n1/queue/scheduler
 ```
 ---
 ## 2. Hypervisor host (ESXi / KVM / Hyper-V)
-### CPU a NUMA
+### Konfigurace podle velikosti a storage typu
-| Nastavení | Doporučení | Poznámka |
+#### Varianta A: Malá firma — lokální storage (2-3 hosty)
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
-| **Overcommit ratio** | 1:1 až 4:1 (vCPU:pCPU) | Podle workloadu (1:1 DB, 4:1 web) |
+| **CPU** | 1× EPYC 9224/9254 nebo Xeon 4410Y/5418Y (12-24C) | 1 socket, dost cores pro VM density |
-| **NUMA-aware sizing** | VM ≤ 1 NUMA node | Cross-NUMA penalty ~1.5-2× latence |
+| **RAM** | 128-256 GB (4-8 GB/core) | DDR5, 1DPC |
-| **CPU pinning** | Dedikované VM: ano | Zamezí context switching |
+| **OS disk** | 2× SATA SSD RAID 1 (2× 240-480 GB) | ESXi / Proxmox / Hyper-V boot |
-| **C-States** | Disabled (in BIOS) | Nižší latence, vyšší spotřeba |
+| **VM storage** | 4-6× SATA/SAS SSD, RAID 5/6 nebo 10 | Lokální RAID, 4-12 TB usable |
-| **P-State** | OS control / Performance | HW power management |
+| **Network** | 2-4× 10/25 GbE (LACP) | Sdílený pro vše (management + VM + storage) |
-| **Hyper-Threading** | Enabled | Více vCPU, watch for noisy neighbor |
+| **Hypervisor** | VMware vSphere Standard / Proxmox VE / Hyper-V | Basic license, žádné enterprise funkce |
 | **Storage backend** | Lokální RAID controller (PERC H755, Broadcom 9560) | HW RAID s cache, write-back |
 | **HA** | VMware HA / Proxmox HA | Restart VM na jiném hostu při selhání |
 | **Backup** | Veeam B&R Free / PBS (Proxmox Backup Server) | Lokální nebo USB disk |
-### Storage pro hypervisor
+**Use case**: Malá kancelář, pobočka, dev/test, < 10 VM, nízký rozpočet, jednoduchá správa.
 **Limitace**: Žádné vMotion bez shared storage, outage při výpadku hosta (restart HA, ne seamless).
 #### Varianta B: Střední firma — vSAN / Ceph (3-6 hostů)
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 1-2× EPYC 9334/9654 nebo Xeon 5418Y/8592+ (16-32C) | 1-2 socket |
 | **RAM** | 256-512 GB (4-8 GB/core) | DDR5, 2DPC (minimální penalizace) |
 | **OS disk** | 2× SATA SSD RAID 1 nebo 2× M.2 NVMe (BOSS-S1) | Oddělený od VM storage |
 | **Cache tier** | 1-2× NVMe (vSAN caching / Ceph WAL+DB) | Pro write performance |
 | **Capacity tier** | 4-8× SATA/SAS SSD nebo HDD (vSAN capacity / Ceph OSD) | HDD pro kapacitu, SSD pro performance |
 | **Network** | 4× 25/100 GbE — 2× VM + mgmt, 2× storage (vSAN/Ceph) | Oddělená storage síť, RDMA (RoCE v2) |
 | **Hypervisor** | VMware vSAN / Proxmox Ceph / StarWind HCI | HCI license (vSAN ~$2.5k/Core) |
 | **Storage backend** | vSAN OSA/ESA nebo Ceph (RADOS) | Distributed storage, auto-rebalance |
 | **HA** | vSphere HA + vSAN / Proxmox HA + Ceph | vMotion, DRS, automated failover |
 | **Failover** | N+1 (jeden host jako rezerva) | U vSAN min. 4 hosty (pro ESA min. 3) |
 **Čistě Ceph varianta (Proxmox / OpenStack)**:
 ```
-VM storage:
+Proxmox node (3-6×):
-├── OS datastore          RAID 1 (2× SATA SSD) — ESXi boot, images
+├── CPU: 1× EPYC 9224-9334 (12-24C)
-├── VM datastore (gold)   RAID 10 (4× NVMe) — critical VMs, DB
+├── RAM: 128-256 GB
-├── VM datastore (silver) RAID 5 (6× SAS SSD) — general VMs
+├── OS: 2× SATA SSD RAID 1
-└── VM datastore (bronze) RAID 6 (8× SATA HDD) — backup, archive
+├── Ceph OSD: 4-8× NVMe/SATA SSD (RAW, HBA mode)
-
+├── Network: 2× 25 GbE (public) + 2× 25 GbE (cluster)
-Swap datastore:                   1× NVMe nebo SATA SSD (dedikovaný)
+└── Storage: Ceph 3× replication, CRUSH host failure domain
 ```
-### Network design
+**VMware vSAN varianta (4-6 hostů)**:
 ```
 vSAN node (4-6×):
 ├── CPU: 1-2× EPYC/Xeon (16-32C)
 ├── RAM: 256-512 GB
 ├── OS: 2× M.2 NVMe (BOSS-S1) nebo SD card (deprecated)
 ├── vSAN cache: 1-2× NVMe (write buffer)
 ├── vSAN capacity: 4-8× SATA SSD (vSAN ESA) nebo HDD (vSAN OSA)
 ├── Network: 2× 25/100 GbE (VM) + 2× 25 GbE (vSAN)
 └── Storage: vSAN ESA (all-NVMe) nebo OSA (hybrid)
 ```
-| Traffic | VLAN | Speed | NIC teaming |
+**Use case**: SME, enterprise divize, 10-100 VM, potřeba vMotion, DRS, HA, jednoduchý storage management.
 |---------|------|-------|-------------|
 | **Management** | Mgmt VLAN | 1 GbE | Active/Passive |
 | **VM traffic** | VM VLANs | 25/100 GbE | LACP (802.3ad) |
 | **Storage** | Storage VLAN | 25/100 GbE | LACP / RDMA | 
 | **vMotion** | vMotion VLAN | 25/100 GbE | Dedikovaný, multi-NIC |
 | **FT (Fault Tolerance)** | FT VLAN | 10 GbE | Dedikovaný, low latency |
-### BIOS pro hypervisor
+#### Varianta C: Velká firma — FC SAN (6+ hostů)
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 2× EPYC 9654/9965 nebo Xeon 8592+/6980P (32-64C) | 2 socket, max VM density |
 | **RAM** | 512 GB - 2 TB (4-8 GB/core) | DDR5, 2DPC |
 | **OS disk** | 2× SATA SSD RAID 1 nebo SD card (vSphere) | Boot, image storage |
 | **VM storage** | LUNy z FC SAN — VMFS / NFS datastory | Hitachi, Dell, Pure, HPE storage |
 | **HBA** | 2× dual-port FC HBA 32/64 Gb | Multipath, FC-NVMe |
 | **Network** | 4-8× 25/100 GbE — rozdělené do traffic typů | Management, VM, vMotion, FT odděleny |
 | **Hypervisor** | VMware vSphere Enterprise+ / Hyper-V DC | Enterprise license, DRS, HA, FT |
 | **Storage backend** | FC SAN — VMFS 8 datastory, VVols | Thin provisioning, storage DRS, array snapshots |
 | **HA** | vSphere HA + DRS + vCenter | vMotion, DRS, FT, SRM pro DR |
 | **Failover** | N+1 nebo admission control (rezerva CPU/RAM) | Vyhrazená kapacita pro HA failover |
 **Use case**: Enterprise, 100+ VM, mix DB a aplikací, centralizovaný storage management, enterprise SLA.
 #### Varianta D: Hyperscale — Ceph / SDS (20+ hostů)
 | Komponenta | Doporučení | Poznámka |
 |-----------|-----------|----------|
 | **CPU** | 2× EPYC 9654/9965 (64-128C) | 2 socket, compute optimální |
 | **RAM** | 512 GB - 1 TB (2-4 GB/core) | Nízký overcommit ratio pro konzistenci |
 | **OS disk** | 2× M.2 NVMe RAID 1 (BOSS) | Boot |
 | **Network** | 4-8× 100 GbE (compute + storage) | Separate OVN/OVS pro SDN, VXLAN tunneling |
 | **Hypervisor** | OpenStack (Nova) / OpenShift (KubeVirt) | Open source, API-driven, multi-tenant |
 | **Storage backend** | Ceph (RADOS, RBD, RGW, CephFS) | Unified storage, erasure coding (8+3) |
 | **Orchestrace** | OpenStack / Kubernetes | Infrastructure-as-Code, autoscaling |
 | **HA** | OpenStack HA / Kubernetes HA | Self-healing, auto-rebalance |
 **Use case**: Cloud provider, hyperscale, 500+ VM, multi-tenant, maximální automatizace.
 ### Srovnání hypervisor variant
 | Aspekt | Lokální (malá) | vSAN/Ceph (střední) | FC SAN (velká) | Ceph hyperscale |
 |--------|---------------|---------------------|----------------|-----------------|
 | **Storage** | Lokální RAID | vSAN / Ceph (HCI) | FC SAN (centralizovaný) | Ceph (distribuovaný) |
 | **Počet hostů** | 2-3 | 3-6 | 6-50+ | 20+ |
 | **Latence VM** | ~10 µs (local) | ~100-500 µs | ~200 µs (SAN) | ~500-2000 µs |
 | **CAPEX/host** | Nízký | Střední | Vysoký | Střední |
 | **CAPEX storage** | Nízký | Žádný (součást hostů) | Vysoký (SAN array) | Žádný (součást hostů) |
 | **Management** | Simple (per host) | vCenter / Proxmox | vCenter + SAN mgmt | OpenStack / K8s |
 | **vMotion** | Ne (bez sdílené storage) | Ano (vSAN / Ceph RBD) | Ano (FC LUN) | Ano (Ceph RBD) |
 | **DRS** | Ne | Ano (vSphere) | Ano (vSphere) | OpenStack scheduler |
 | **Škálování** | Vertikální | Horizontální (přidat host) | Horizontální (host + SAN) | Horizontální |
 ### Network design podle varianty
 #### Malá (lokální storage)
 | Traffic | VLAN | Rychlost | Teaming | Poznámka |
 |---------|------|----------|---------|----------|
 | Management | Mgmt | 1 GbE | Active/Passive | Dedikovaný port (iLO/iDRAC) |
 | VM + Storage | All | 2-4× 10/25 GbE | LACP | Sdílené, VLAN tagging |
 ```
 ┌──────────────────────────────────────────┐
 │  Host                                   │
 │  ┌──────┐ ┌─────────────────────────────┐│
 │  │ iLO  │ │   NIC1   NIC2               ││
 │  │ 1 GbE │ │  [LACP] 25 GbE             ││
 │  └──────┘ └──────────┬──────────────────┘│
 └──────────────────────┼───────────────────┘
                       │
                 ┌─────┴─────┐
                 │  Switch   │
                 └───────────┘
 ```
 #### Střední (vSAN / Ceph)
 | Traffic | VLAN | Rychlost | Teaming | Poznámka |
 |---------|------|----------|---------|----------|
 | Management | Mgmt | 1 GbE | Active/Passive | Dedikovaný iLO/iDRAC |
 | VM | VM | 2× 25/100 GbE | LACP | VM traffic, migrace |
 | Storage | vSAN/Ceph | 2× 25/100 GbE | LACP nebo RDMA | Oddělený, Jumbo frames (MTU 9000) |
 ```
 ┌──────────────────────────────────────────┐
 │  Host                                   │
 │  ┌──────┐ ┌──────────┐ ┌───────────────┐│
 │  │ iLO  │ │ NIC1 NIC2│ │ NIC3 NIC4     ││
 │  │ 1 GbE │ │ VM traffic│ │ Storage (vSAN)││
 │  └──────┘ └──────────┘ └───────────────┘│
 └──────────────────────────────────────────┘
 ```
 #### Velká (FC SAN)
 | Traffic | VLAN | Rychlost | Teaming | Poznámka |
 |---------|------|----------|---------|----------|
 | Management | Mgmt | 1 GbE | Active/Passive | Dedikovaný |
 | VM | VM | 2-4× 25/100 GbE | LACP | VM traffic |
 | vMotion | vMotion | 2× 25 GbE | Dedikovaný | Multi-NIC vMotion |
 | FT | FT | 2× 10/25 GbE | Dedikovaný | Low latency |
 | Storage | — | 2× 32/64 Gb FC | Multipath | FC SAN |
 ```
 ┌──────────────────────────────────────────────┐
 │  Host                                       │
 │  ┌──────┐ ┌────────────┐ ┌────┐ ┌─────────┐│
 │  │ iLO  │ │ NIC1-4      │ │HBA1│ │ HBA2    ││
 │  │ 1 GbE │ │ VM+vMotion+FT│ │32Gb│ │ 32Gb    ││
 │  └──────┘ └────────────┘ └─┬──┘ └──┬──────┘│
 └────────────────────────────┼───────┼───────┘
                             │       │
                     ┌───────┴───┐ ┌─┴────────┐
                     │ Ethernet  │ │ FC Switch │
                     │ Switch    │ │ (Brocade/ │
                     │           │ │  Cisco)   │
                     └───────────┘ └──────────┘
 ```
 ### BIOS pro hypervisor — všechny varianty
 | Nastavení | Hodnota | Zdůvodnění |
 |-----------|---------|------------|
 | Hyper-Threading | Enabled | Vyšší VM density |
 | Virtualization Technology | Enabled | VT-x/AMD-V |
 | VT-d / IOMMU | Enabled | Passthrough, SR-IOV |
-| Power Management | Performance / OS | Minimalizace latence VM |
+| Power Management | Performance / OS | Minimalizace latence VM exit |
-| C-States | Disabled | Nižší latence VM exit |
+| C-States | Disabled | Nižší latence VM exit (důležité pro real-time VM) |
 | NUMA | Enabled | NUMA-aware VM placement |
 | SR-IOV | Enabled | NIC/GPU virtualizace |
 | Adjacent Sector Prefetch | Enabled (Intel) | Lepší sekvenční čtení |
 | DCU Streamer / IP Prefetcher | Enabled | HW prefetch pro VM workload |
 | Patrol Scrub | Disabled (vSAN/Ceph) | Může způsobovat latency spikes u SDS |
 ### Výběr hypervisoru podle varianty
 | Kritérium | VMware vSphere | Proxmox VE | Hyper-V | OpenStack |
 |-----------|---------------|------------|---------|-----------|
 | **Velikost** | SME - Enterprise | SME | SME - Enterprise | Hyperscale |
 | **Storage** | vSAN, SAN, NFS | Ceph, ZFS, NFS | Storage Spaces, SAN | Ceph, manila |
 | **License** | ~$1-5k/core | Zdarma (support ~$500/host) | Součást Windows Server | Open source |
 | **Familiarita** | Nejvyšší | Střední | Windows admin | Nízká |
 | **Automation** | Terraform, Ansible, PowerCLI | Ansible, Terraform, PBS | PowerShell, SCVMM | Terraform, Heat, Ansible |
 | **Ekosystém** | Nejširší (Veeam, Zerto, SRM) | Rostoucí (PBS, vzdálená migrace) | Windows ecosystem | Open source (Kolla, TripleO) |
 ---
@@ -250,36 +678,80 @@ net.core.netdev_max_backlog = 65535
 ---
-## Rychlý decision tree — výběr serveru
+## Rychlý decision tree — výběr serveru podle workloadu, velikosti a storage
 ```mermaid
 flowchart TD
    W["Jaký workload?"] --> DB["Databáze"]
    W --> HV["Virtualizace"]
    W --> K8s["Kubernetes"]
    W --> AI["AI/ML"]
    W --> ST["Storage server"]
    W --> WEB["Web / API"]
    DB --> DBS{"Velikost firmy"}
    DBS -->|"< 500"| DB1["1× EPYC 8-16C, 64-256 GB<br/>NVMe RAID10, 2× 25GbE"]
    DBS -->|"500-5000"| DB2{"Storage"}
    DB2 -->|"Lokální"| DB2L["1-2× EPYC 16-24C, 128-512 GB<br/>NVMe RAID10, 4× 25GbE"]
    DB2 -->|"Ceph"| DB2C["2× EPYC 16-32C, 256-512 GB<br/>RBD, 4× 25/100GbE"]
    DBS -->|"Enterprise"| DB3{"Storage"}
    DB3 -->|"FC SAN"| DB3F["2× EPYC 48-128C, 512-2048 GB<br/>SAN LUN + 2× FC 32/64G"]
    DB3 -->|"Ceph"| DB3C["2× EPYC 32-64C, 256-512 GB<br/>RBD, 4× 100GbE"]
    DBS -->|"Cloud"| DBC["RDS/Azure SQL/CloudSQL<br/>Managed, Multi-AZ"]
    DB --> ORACLE{"Oracle architektura?"}
    ORACLE -->|"Standalone"| ORA1["1-2× EPYC 8-24C<br/>64-512 GB, ASM local/FC<br/>2× 25GbE + FC 32G"]
    ORACLE -->|"Data Guard"| ORA2["2× EPYC 32-64C<br/>256-1024 GB, FC SAN<br/>2× 25/100GbE + 2× FC 64G<br/>2× 25GbE (DG sync)"]
    ORACLE -->|"RAC 2-4 nodes"| ORA3["Per node: 2× EPYC 32-64C<br/>512-2048 GB, FC SAN<br/>2× 100GbE (app)<br/>2× FC 64G (storage)<br/>2× 100GbE RoCE (interconnect)"]
    ORACLE -->|"Exadata"| ORA4["Engineered system<br/>2-8 DB servers + 3-18 storage<br/>RoCE 100GbE, Smart Scan<br/>15-30 kW/rack"]
    HV --> HVS{"Počet hostů"}
    HVS -->|"2-3"| HV1["1× EPYC 12-24C, 128-256 GB<br/>RAID5/6 SSD, 2-4× 10/25GbE"]
    HVS -->|"3-6"| HV2{"HCI"}
    HV2 -->|"vSAN"| HV2V["1-2× EPYC 16-32C, 256-512 GB<br/>NVMe cache + SSD, 4× 25GbE"]
    HV2 -->|"Ceph"| HV2C["1× EPYC 12-24C, 128-256 GB<br/>4-8× HBA NVMe/SSD, 4× 25GbE"]
    HVS -->|"6+"| HV3["2× EPYC 32-64C, 512-2048 GB<br/>FC SAN 32/64G, 4-8× 25/100GbE"]
    HVS -->|"20+"| HV4["2× EPYC 64-128C, 512-1024 GB<br/>OpenStack + Ceph, 4-8× 100GbE"]
    K8s --> K8T{"Typ uzlu"}
    K8T -->|"General"| K8G["16-32C, 64-128 GB<br/>2× NVMe, 2× 25GbE"]
    K8T -->|"Memory"| K8M["32-64C, 256-512 GB<br/>3× NVMe, 2× 25GbE"]
    K8T -->|"GPU"| K8U["32-64C, 512-1024 GB<br/>6-10× NVMe, H100/B200, 4× 100GbE"]
    K8T -->|"Storage"| K8S["16-32C, 64-128 GB<br/>6-14× HBA NVMe, 4× 25GbE"]
    AI --> AIT{"Účel"}
    AIT -->|"Trénování"| AITR["GPU H100/B200, NVLink<br/>InfiniBand 400Gb/s, liquid cooling"]
    AIT -->|"Inference"| AIIR["A100/H200, MIG<br/>PCIe 5.0, 2× 100GbE"]
    ST --> STT{"Typ"}
    STT -->|"Ceph OSD"| STC["EPYC (PCIe lanes)<br/>4-8 GB/OSD, HBA, 2× 25/100GbE"]
    STT -->|"MinIO"| STM["EPYC 8-16C, 32-64 GB<br/>4-16× NVMe direct, 2× 25/100GbE"]
    STT -->|"NAS (ZFS)"| STN["EPYC 16-32C, 64-128 GB<br/>RAID-Z, SLOG NVMe, 2-4× 10/25GbE"]
    WEB --> WEBE["EPYC high clock, 8-32C<br/>32-128 GB, 2× NVMe RAID1, 2× 10/25GbE"]
 ```
-Jaký workload?
+
-│
+### Connectivity summary podle platformy
-├── Databáze (OLTP)
+
-│   → EPYC, high clock, 8-16 GB/core, RAID10 NVMe, huge pages
+| Platforma | App / VM síť | Storage síť | Replikace / Cluster | Management |
-│
+|-----------|-------------|-------------|---------------------|------------|
-├── Databáze (OLAP)
+| **DB lokální (malá)** | 2× 25 GbE LACP | — | 2× 25 GbE (sdílené) | 1× 1 GbE (iLO) |
-│   → Xeon AMX/AVX-512, 16-64 GB/core, many cores
+| **DB lokální (střední)** | 2× 25/100 GbE LACP | — | 2× 25 GbE dedikované | 1× 1 GbE (iLO) |
-│
+| **DB FC SAN** | 2× 25/100 GbE LACP | 2× 32/64 Gb FC multipath | FC replication | 1× 1 GbE (iLO) + SAN mgmt |
-├── Virtualizace
+| **DB Ceph** | 2× 25/100 GbE | 2× 25/100 GbE (Ceph public) | 2× 25/100 GbE (Ceph cluster) | 1× 1 GbE (iLO) |
-│   → EPYC, many cores, 4-8 GB/core, shared storage (SAN/NFS/vSAN)
+| **Hypervisor lokální** | 2-4× 10/25 GbE LACP | — (lokální) | — | 1× 1 GbE (iLO) |
-│
+| **Hypervisor vSAN** | 2× 25/100 GbE LACP | 2× 25/100 GbE (vSAN) | vSAN traffic | 1× 1 GbE (iLO) |
-├── Kubernetes
+| **Hypervisor FC SAN** | 2-4× 25/100 GbE LACP | 2× 32/64 Gb FC multipath | 2× 25 GbE (vMotion) | 1× 1 GbE (iLO) |
-│   → EPYC, balance, 2-4 GB/core, local NVMe
+| **Hypervisor Ceph** | 2× 25/100 GbE LACP | 2× 25/100 GbE (Ceph) | 2× 25 GbE (migration) | 1× 1 GbE (iLO) |
-│
+| **Kubernetes** | 2× 25/100 GbE | 2× 25/100 GbE (Ceph/Longhorn) | 2× 25/100 GbE (K8s cluster) | 1× 1 GbE (BMC) |
-├── AI/ML training
+| **Web/API** | 2× 10/25 GbE LACP | — | — | 1× 1 GbE (BMC) |
-│   → GPU node (H100/B200), NVLink, InfiniBand, liquid cooling
+| **Oracle Standalone** | 2× 25 GbE LACP | 2× FC 32G nebo NVMe local | Data Guard 2× 25 GbE | 1× 1 GbE (iLO) + ASM mgmt |
-│
+| **Oracle Data Guard** | 2× 25/100 GbE LACP | 2× FC 64G multipath | 2× 25 GbE (DG sync) | 1× 1 GbE (iLO) + SAN mgmt |
-├── AI/ML inference
+| **Oracle RAC** | 2× 100 GbE LACP (VIP/SCAN) | 2× FC 64G multipath | 2× 100 GbE RoCE (Cache Fusion) | 1× 1 GbE (iLO) + Clusterware |
-│   → A100/H200, MIG, large VRAM, PCIe 5.0
+| **Oracle Exadata** | 4-8× 100 GbE RoCE | NVMe over Fabric | RDMA interconnect | Exadata CLI + OEDA |
 │
 ├── Storage (Ceph/SDS)
 │   → EPYC (PCIe lanes), HBA mode, 4-8 GB/OSD
 │
 └── Web / API
    → EPYC, high clock, 2-4 GB/core, 10 GbE
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
-```
+
 *Poslední revize: 2026-06-03*
--- a/SERVER-HW.md
+++ b/SERVER-HW.md
@@ -157,6 +157,27 @@ AMD EPYC má 12 memory channels (vs Intel 8), což dává o 50 % vyšší teoret
 4. Heterogenní mix: vyšší rank count do bílých slotů
 5. **Nemíchat**: 3DS s non-3DS, x4 s x8, různé ranky v channelu, 16 Gb / 24 Gb / 32 Gb DRAM
 #### HPE Gen11/Gen12 s AMD EPYC 9005 (a50012817enw)
 AMD EPYC 9005 (Turin) přináší 12 memory channels na CPU a podporu DDR5-6400.
 | Vlastnost | Detail |
 |-----------|--------|
 | **Memory channels** | 12 per CPU (vs 8 u Intel) |
 | **Max DIMM slots** | 24 per CPU (2 DPC) |
 | **Max speed** | DDR5-6400 (1 DPC), DDR5-4800–5600 (2 DPC) |
 | **Max capacity** | 6 TB+ (12× 256 GB 3DS RDIMM) |
 | **DIMM typy** | RDIMM (1R/2R/4R/8R), 3DS RDIMM, LRDIMM |
 | **Population** | 1 DPC (bílé sloty): 12 DIMMs, plná rychlost; 2 DPC: 24 DIMMs, snížená rychlost |
 | **Optimum** | 12× identických DIMMů (1 DPC na každém channelu) = max bandwidth |
 **Pravidla pro AMD EPYC 9005:**
 1. Osazovat po stejných kapacitách v rámci channelu
 2. 1 DPC = plná rychlost 6400 MT/s, 2 DPC = nižší rychlost
 3. Pro optimální bandwidth: 12 DIMMů (1DPC) na CPU — využito všech 12 channelů
 4. Maximální kapacita: 24 DIMMů (2DPC) — 24× 256 GB = 6 TB na CPU
 5. Nemíchat RDIMM a LRDIMM ve stejném systému
 ### Memory population — decision flow
 ```
@@ -193,7 +214,8 @@ Závěr: 8 DIMMů na CPU (1DPC) = nejvyšší výkon
 **Doporučení výrobců:**
 - **Dell**: 16× identických DIMMů (8 per CPU), 1DPC, 5600 MT/s = optimální výkon
- **HPE**: Vždy plnit bílé sloty první, pro max výkon 1DPC, pro max kapacitu 2DPC
+- **HPE Intel**: Vždy plnit bílé sloty první, pro max výkon 1DPC, pro max kapacitu 2DPC
 - **HPE AMD EPYC 9005**: 12 channelů na CPU, 1DPC = 12 DIMMů na CPU při 6400 MT/s (max bandwidth); 2DPC = 24 DIMMů na CPU (max kapacita 6 TB)
 - **Supermicro**: Sledovat konkrétní manual pro daný model (DSG, GPU, storage)
 - **Lenovo**: Stejná pravidla jako Intel/AMD platforma — preferovat 1DPC
@@ -327,3 +349,5 @@ Detailní kapitola o síťové a storage konektivitě: [CONNECTIVITY.md](CONNECT
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 *Poslední revize: 2026-06-03*
--- a/STORAGE.md
+++ b/STORAGE.md
@@ -85,6 +85,164 @@ RADOS (Reliable Autonomic Distributed Object Store)
 - Vyšší CPU režie, nižší IOPS
 - Doporučeno pro cold data (RGW) místo replikace
 ## Výrobci enterprise storage
 ### Hitachi VSP (Virtual Storage Platform)
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **VSP 5200/5600** | Active-active, scale-up/out, 2–12 controllerů | 69.3 PB raw, 287 PBe | 33M IOPS, 39 µs | FC-NVMe 32Gb, FC 16/32Gb, FICON 16Gb, iSCSI 10Gb | Mission-critical, mainframe, enterprise consolidation |
 | **VSP E590/E790/E1090** | Symmetric active-active, až 65 nodů/130 controllerů | 10.62 PB raw (E1090) | 8.4M IOPS, <41 µs | FC 32Gb, iSCSI 25Gb, FC-NVMe 32Gb | Midrange enterprise, hybrid workloads |
 **Klíčové vlastnosti**: SVOS společný pro celé portfolio, AI-driven data reduction 4:1 garance, Global-Active Device metro clustering, 8 nines availability (HW), 100% data availability guarantee.
 ---
 ### Huawei OceanStor Dorado
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **Dorado 8000/18000 V6** | SmartMatrix full-mesh, až 32 controllerů | 32 TB cache, 6400 SSD | 40M IOPS, 0.05 ms | FC 32/64Gb, FC-NVMe, iSCSI, NFS, SMB, NVMe/RoCE, S3 | Mission-critical, finance, govt, carrier |
 | **Dorado 8000/18000 V7 (2025)** | SmartMatrix 4.0, až 64/128 controllerů | 500 PB+ | >100M IOPS, 0.03 ms | FC, RoCE, NVMe/TCP, NFS, SMB, S3 | AI workloads, converged block/file/object |
 **Klíčové vlastnosti**: SmartMatrix přežije 7/8 controllerů, FlashEver (3-gen online HW upgrade za 10 let), RAID-TP (triple SSD failure), DPU-based SmartNIC, ML-based I/O prefetch, 100% ransomware detection (Tolly), #1 SPC-1 benchmark.
 ---
 ### Dell PowerStore & PowerMax
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **PowerStore 1500/5500/9500 (Gen 3)** | Active-active dual-node, PCIe Gen5, DDR5, RDMA 200GbE | 1.2 PB raw, 5.8 PBe | 3× IOPS oproti Gen2 | FC 32/64Gb, iSCSI, NVMe/FC, NVMe/TCP, NFSv4, SMB3 | Midrange-to-high-end, VMware, containerized |
 | **PowerMax 2500/8500** | Scale-out NVMe, Dynamic Fabric, až 16 nodů | 8.8 PBe (2500), 18 PBe (8500) | 6 nines availability | FC 64Gb, FICON, NVMe/FC, NVMe/TCP, iSCSI, NFS, SMB | Mission-critical, mainframe, OLTP, cyber vault |
 **Klíčové vlastnosti**: PowerStore 6:1 DRR garance, unified block/file/vVols out of box, Cyber Detect AI anomaly; PowerMax 5:1 DRR, Secure Snapshots 65M, SRDF/Metro, Flexible RAID až 92% efficient, FIPS 140-3.
 ---
 ### HPE Alletra
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **Alletra 5000** | Active-active hybrid flash, dual controller | 1.2 PB raw | 99.9999% garance | FC, iSCSI | Mixed primary + secondary, cost-efficient hybrid |
 | **Alletra 6000** | Active-active all-NVMe, dual controller | ~368 TB usable | <100 µs | FC, iSCSI | Business-critical DB, VDI, VMware |
 | **Alletra 9000** | Active-active all-NVMe, multi-node scale-out | 2–4 PB+ usable | ~2–3M IOPS, <150 µs | FC, iSCSI, NVMe/FC | Mission-critical ERP, AI, consolidation |
 | **Alletra Storage MP** | Disaggregated modular, block + file + object | 5.8 PB block, 11.8 PB object | 100% availability garance | FC, iSCSI, NVMe/FC, NFS, SMB, S3 | Multi-protocol consolidation, AI/analytics |
 **Klíčové vlastnosti**: Triple Parity RAID (5000), InfoSight AI Ops, HPE GreenLake as-a-service, non-disruptive controller upgrades (MP), 100% data availability guarantee.
 ---
 ### Infinidat
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **InfiniBox SSA G4** | Triple-active controller, AMD EPYC PCIe 5.0, DDR5 | 1.97 PB usable / 5.9 PBe | 2.24M IOPS, 35 µs | FC 32Gb, 25/100GbE, NVMe-oF/TCP, iSCSI, NFS, SMB, S3 | Mission-critical Oracle/SQL, multi-site DR |
 | **InfiniBox G4 Hybrid** | Triple-active hybrid (HDD + flash cache) | 10.9 PB raw / 32.8 PBe | 2.24M IOPS, 64 GB/s | FC, Ethernet, NVMe-oF, iSCSI, NFS, SMB, S3 | Backup, massive unstructured data |
 **Klíčové vlastnosti**: 3-way active jediný na trhu, Neural Cache (ML-driven), InfiniRAID, Immutable snapshots, 100% availability + 1-min snapshot recovery garance, vše v základní ceně (žádný extra licensing).
 ---
 ### Pure Storage FlashArray
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **FlashArray//X (X20–X90 R5)** | Active-active, NVMe DirectFlash | 1.2 PB raw / 4.4 PBe | 250 µs, 5:1 DRR | FC, NVMe/FC, NVMe/RoCE, NVMe/TCP, iSCSI, NFS, SMB | Mission-critical DB, VMware, enterprise |
 | **FlashArray//C (C50–C90 R5)** | Active-active, QLC DirectFlash | 4.2 PB raw / 16.3 PBe | 5:1 DRR | FC, NVMe-oF, iSCSI, NFS, SMB | Capacity-optimized, backup, file |
 | **FlashArray//XL (XL190)** | Active-active, 40 DirectFlash modulů | 1.9 PB raw / 9.4 PBe | >4M IOPS, <100 µs, 45 GB/s | FC 64Gb, 100GbE RoCE, NVMe/FC, NVMe/TCP, NFS, SMB | Největší DB konsolidace, OLTP |
 **Klíčové vlastnosti**: DirectFlash (bez FTL vrstvy), 99.9999% availability, Evergreen (nikdy forklift upgrade), Purity OS jednotný napříč celým portfoliem, ActiveCluster/ActiveDR, Pure1 AIOps.
 ---
 ### Lenovo ThinkSystem
 | Model | Architektura | Max kapacita | IOPS / Latence | Protokoly | Use case |
 |-------|-------------|--------------|----------------|-----------|----------|
 | **DM Series** (DM3200F/5200F/7200F) | Active-active, all-NVMe, NetApp ONTAP | 1.8 PB raw / 6.8 PBe | Až 120 NVMe SSD | FC 64Gb, iSCSI, NVMe/FC, NFS, SMB, S3 | Unified block/file, AI/ML, VMware |
 | **DG Series** (DG5200/7200) | Active-active, all-QLC, ONTAP | 7.4 PB raw / 27 PBe | QLC ekonomie | FC, NVMe/FC, NVMe/TCP, iSCSI, NFS, SMB, S3 | Capacity-optimized, backup, archive |
 | **DE Series** (DE4000F–DE6600F) | Active-active, SAS/NVMe hybrid | 1.84 PB raw | 2M IOPS, <100 µs, 44 GB/s | FC 32Gb, iSCSI 25Gb, NVMe/FC, SAS, NVMe/RoCE | HPC, analytics, video surveillance |
 **Klíčové vlastnosti**: DM/DG využívají ONTAP (SnapMirror, SnapVault, FabricPool, RAID-DP/RAID-TEC); cluster scale-out až 12 HA párů; DE série nejlepší poměr cena/výkon v portfoliu.
 ---
 ### Synology
 | Model | Architektura | Max kapacita | Protokoly | Use case |
 |-------|-------------|--------------|-----------|----------|
 | **UC3200/UC3400** | Active-active dual-controller, SAS backend | 576 TB raw | iSCSI, FC 16Gb, 10/25GbE | SMB/midmarket SAN, VMware, HA |
 | **DS/RS Series** (RS3626xs+, RS6426xs+) | Single-controller / HA pair, Btrfs | 864 TB raw, 1 PB volume | SMB, NFS, iSCSI, FC (HBA) | SME all-in-one NAS/SAN, backup, surveillance |
 **Klíčové vlastnosti**: DSM UC pro SAN, Synology HA, Snapshot Replication (16K snapshots), VMware VAAI/ODX/ALUA, Surveillance Station, nízké TCO.
 ---
 ### Srovnání vendorů — přehled
 | Vendor | Flagship | Max IOPS | Max kapacita | Latence | Garance availability | Hlavní diferentiátor |
 |--------|----------|----------|-------------|---------|---------------------|----------------------|
 | **Hitachi** | VSP 5600 | 33M | 287 PBe | 39 µs | 8 nines (HW) | Mainframe + open; 65-node cluster |
 | **Huawei** | Dorado 18000 V7 | >100M | 500 PB+ | 0.03 ms | 99.99999% | SmartMatrix; #1 SPC-1 |
 | **Dell** | PowerMax 8500 | — | 18 PBe | — | 6 nines | SRDF/Metro; mainframe |
 | **HPE** | Alletra 9000/MP | ~3M | 11.8 PBe | <150 µs | 100% data guarantee | InfoSight AIOps; GreenLake |
 | **Infinidat** | InfiniBox SSA G4 | 2.24M | 32.8 PBe | 35 µs | 100% availability | 3-way active; Neural Cache |
 | **Pure** | FlashArray//XL | >4M | 16.3 PBe | <100 µs | 99.9999% | DirectFlash; Evergreen |
 | **Lenovo** | DM7200F | — | 27 PBe | — | — | ONTAP ecosystem; široké portfolio |
 | **Synology** | UC3400 | 690K | 576 TB | — | — | Nejnižší cena za active-active SAN |
 ---
 ### Výběr storage dle use case
 | Use case | Doporučení | Zdůvodnění |
 |----------|-----------|-------------|
 | **Mainframe + open hybrid** | Hitachi VSP / Dell PowerMax | Jediní s FICON + FC současně |
 | **AI/ML trénování** | Huawei Dorado V7 / Pure //XL | Nejvyšší IOPS, nejnižší latence |
 | **Enterprise DB (Oracle, SQL Server)** | Infinidat / Pure //X | Nízká latence, konzistentní výkon |
 | **Virtualizace (VMware, Hyper-V)** | Dell PowerStore / HPE Alletra 6000 | VAAI, vVols, InfoSight |
 | **SMB / SME** | Synology / Lenovo DE | Nízké TCO, jednoduchá správa |
 | **Object storage / backup** | Pure //C / Lenovo DG / Infinidat Hybrid | QLC ekonomie, vysoká kapacita |
 | **Multi-protocol konsolidace** | HPE Alletra MP / Huawei Dorado | Block + file + object v jedné platformě |
 ## Decision diagram — výběr storage platformy
 ```mermaid
 flowchart TD
    Start(["Storage requirement"]) --> PROTO{"Access type"}
    PROTO -->|"Block (SAN)"| BLOCK
    PROTO -->|"File (NAS)"| FILE
    PROTO -->|"Object"| OBJECT
    BLOCK --> BPERF{"Performance tier"}
    BPERF -->|"Tier 0/1<br/>< 100 µs, > 1M IOPS"| BT1["Infinidat / Pure //XL<br/>Huawei Dorado V7<br/>FC-NVMe, NVMe-oF"]
    BPERF -->|"Tier 2<br/>100-500 µs"| BT2["Dell PowerStore / HPE Alletra 6000<br/>Hitachi VSP / Lenovo DM<br/>FC 32G, iSCSI 25GbE"]
    BPERF -->|"Tier 3<br/>SME / low-cost"| BT3["Synology UC3400<br/>Lenovo DE / Dell PowerVault<br/>iSCSI, SAS"]
    BLOCK --> BECOS{"Ecosystem"}
    BECOS -->|"Mainframe"| BMF["Hitachi VSP / Dell PowerMax<br/>FICON + FC současně"]
    BECOS -->|"VMware"| BVM["Dell PowerStore / HPE Alletra<br/>VAAI, vVols, InfoSight"]
    BECOS -->|"Oracle / SQL Server"| BDB["Infinidat / Pure //X<br/>Nejnižší latence"]
    FILE --> FSIZE{"Škálování"}
    FSIZE -->|"Enterprise"| FE["HPE Alletra MP (file)<br/>Lenovo DM / Dell PowerScale<br/>NFS, SMB, multi-protocol"]
    FSIZE -->|"SMB"| FS["Synology DS/RS<br/>Lenovo DE / TrueNAS<br/>Btrfs, NFS, SMB, nízké TCO"]
    OBJECT --> OUSE{"Use case"}
    OUSE -->|"Backup / archive"| OB["Pure //C / Infinidat Hybrid<br/>Lenovo DG<br/>QLC, erasure coding, nízká cena/TB"]
    OUSE -->|"AI/ML data lake"| OM["MinIO / Pure //C<br/>High throughput S3<br/>NVMe direct, erasure coding"]
    OUSE -->|"Kubernetes PVC"| OK["Ceph RBD / Longhorn / Linstor<br/>SDS na K8s<br/>CSI, replication, snapshots"]
 ```
 ## Zdroje
 Odkazy, knihy a standardy: [sources/infrastructure/sources.md](sources/infrastructure/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | ISBN | Popis |
 |-------|--------|------|-------|
 | Storage Systems | Ganger, Gibson | 978-1680837540 | Učebnice pokrývající návrh, implementaci a provoz úložných systémů — od charakteristik jednotlivých zařízení přes OS, databáze a networking až po distribuce v serverech a large-scale systémech. Nezbytný zdroj pro architekty storage infrastruktury. |
 *Poslední revize: 2026-06-03*
--- a/VEKTOROVE-DB.md
+++ b/VEKTOROVE-DB.md
@@ -0,0 +1,105 @@
 # 🧠 Vektorové databáze
 ## Přehled
 Specializované databáze pro ukládání a vyhledávání **embeddingů** — vektorových reprezentací nestrukturovaných dat (text, obrázky, audio, video). Umožňují **sémantické vyhledávání** na základě podobnosti, nikoliv přesné shody. Klíčový stavební kámen pro RAG (Retrieval-Augmented Generation) a AI aplikace.
 ## Embeddings
 - Mapují nestrukturovaná data do vektorového prostoru (seznam čísel)
 - Blízkost ve vektorovém prostoru = sémantická podobnost
 - Generovány modely: Word2Vec, BERT, OpenAI embeddings, E5, Cohere, Mistral
 - Dimenze: 384 (all-MiniLM) až 3072 (OpenAI text-embedding-3-large)
 ## Indexování vektorů
 | Metoda | Algoritmus | Popis | Přesnost | Rychlost |
 |--------|-----------|-------|----------|----------|
 | **Flat (brute-force)** | Úplné prohledání | Porovnání se všemi vektory | 100 % | O(N) — pomalé pro > 100K |
 | **IVF** (Inverted File) | K-means clustering | Rozdělení do shluků, hledá se v nejbližším shluku | ~95-99 % | O(sqrt(N)) |
 | **HNSW** (Hierarchical Navigable Small World) | Navigovatelný graf | Víceúrovňový graf, greedy search | ~99-100 % | O(log N) |
 | **IVF-PQ** | IVF + Product Quantization | Komprese vektorů, menší paměť | ~90-95 % | O(sqrt(N)) |
 | **DiskANN** | SSD-based graf | Vektory na disku, Vamana graf | ~95-98 % | O(log N) + I/O |
 ### Volba indexu
 | Počet vektorů | Požadavek | Doporučený index |
 |--------------|-----------|-----------------|
 | < 100K | 100% přesnost | Flat |
 | 100K - 10M | Vysoká přesnost, rychlost | HNSW |
 | 10M+ | Paměťová efektivita | IVF-PQ, DiskANN |
 | 100M+ | Škálování na SSD | DiskANN |
 ## Use case: RAG (Retrieval-Augmented Generation)
 ```text
 User query → Embedding model → Vector DB search → Relevant chunks → LLM → Answer
 ```
 Varianty:
 - **Naive RAG** — jeden retrieval + jeden generování
 - **Advanced RAG** — pre-retrieval (query rewriting, HyDE) + post-retrieval (reranking, filtering)
 - **Multi-modal RAG** — text + obrázky + audio do jednoho pipeline
 ## Nástroje — srovnání
 | Nástroj | Typ | Indexy | Cloud | Self-hosted | Poznámka |
 |---------|-----|--------|-------|-------------|----------|
 | **Pinecone** | Managed | HNSW, IVF-PQ | Ano | Ne | Plně spravovaná, žádný ops. Cena dle dimenze a počtu vektorů |
 | **Weaviate** | Open source | HNSW, Flat | Ano (WCD) | Ano | Grafová + vektorová, hybridní dotazy, modulární (generative search) |
 | **Qdrant** | Open source | HNSW, IVF-PQ, quantization | Ano (Cloud) | Ano | Rust, batch API, filtr souběžně s vektorovým search |
 | **Milvus** | Open source | IVF, HNSW, IVF-PQ, DiskANN | Ano (Zilliz) | Ano | GPU akcelerace. Komplexnější ops (K8s required) |
 | **pgvector** | PostgreSQL extension | IVFFlat, HNSW | Vše (díky RDS) | Ano | Embeddingy přímo v PostgreSQL. Hybridní SQL + vektory |
 | **Chroma** | Open source | HNSW | Ne | Ano | Jednoduchý na embedding + retrieval, Python-native |
 | **LanceDB** | Open source | IVF-PQ | Ne | Ano | Multimodální data, Arrow formát, žádný server (embedded) |
 | **Elasticsearch** | Search engine | HNSW (8.0+) | Ano (Cloud) | Ano | Pokud už máte ES, lze použít i pro vektory |
 ### pgvector vs samostatná vektorová DB
 | Vlastnost | pgvector | Samostatná (Pinecone, Qdrant, Milvus) |
 |-----------|----------|---------------------------------------|
 | **Architektura** | Extension v PostgreSQL | Samostatná služba |
 | **Hybridní dotazy** | Nativní SQL + vektory | Nutná koordinace dvou systémů |
 | **Latence** | Vyšší (disk-based PG) | Nižší (in-memory indexy) |
 | **Škálování** | PG replikace / Citus | Nativní sharding, rebalancing |
 | **Konzistence** | PG ACID transakce | Eventual consistency |
 | **Provoz** | Jeden systém | Dva systémy (operational overhead) |
 ## Doporučení — Volba nástroje
 | Scénář | Doporučení | Zdůvodnění |
 |--------|-----------|-------------|
 | **RAG na PostgreSQL datech** | pgvector | Hybridní SQL + vektory v jedné DB |
 | **RAG produkce, žádný ops** | Pinecone | Plně managed, škálovatelné, žádný provoz |
 | **Self-hosted RAG** | Qdrant (jednodušší) / Milvus (výkon) | Open source, kontrola nad daty |
 | **Full-text + vektory** | Elasticsearch / Weaviate | Kombinace BM25 + vektorového skóre |
 | **Výzkum / prototypování** | Chroma | Python-native, rychlý start |
 | **Embedded / edge** | LanceDB | Žádný server, Arrow formát |
 | **Multi-modal data** | Weaviate / LanceDB | Nativní podpora obrázků, audio, videa |
 | **GPU akcelerace** | Milvus | CUDA podpora pro index build |
 ## Kdy vektorovou DB (ne)použít
 **Použít** když:
 - Potřebujete sémantické vyhledávání (podobnost podle významu, ne klíčových slov)
 - Stavíte RAG / AI asistenta nad vlastními daty
 - Deduplikace dokumentů, obrázků (near-duplicate detection)
 - Doporučovací systémy (podobný obsah, podobní uživatelé)
 **Nepoužít** když:
 - Potřebujete přesnou shodu (klíče, ID, foreign keys) → SQL
 - Full-text search stačí (BM25, stemming) → Elasticsearch, PostgreSQL full-text
 - Vektory jen jako doplněk k primární DB → pgvector (jednoduchost)
 - Méně než 1000 dokumentů → postačí brute-force v aplikaci
 ## Zdroje
 Odkazy, knihy a standardy: [sources/databases/sources.md](sources/databases/sources.md)
 ### Doporučená literatura
 | Kniha | Autoři | Popis |
 |-------|--------|-------|
 | Vector Databases | Borwankar (2026) | Komplexní průvodce vektorovými DB od konceptů po produkční nasazení |
 *Poslední revize: 2026-06-03*
--- a/sources/.DS_Store
+++ b/sources/.DS_Store
--- a/sources/cicd/sources.md
+++ b/sources/cicd/sources.md
@@ -15,8 +15,8 @@
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
 | The DevOps Handbook | Kim, Humble, Debois, Willis | 978-1942788003 | `[done]` |
-| Infrastructure as Code (2nd ed.) | Kief Morris | 978-1098114671 | `[todo]` |
+| Infrastructure as Code (2nd ed.) | Kief Morris | 978-1098114671 | `[done]` |
-| Terraform: Up and Running (3rd ed.) | Yevgeniy Brikman | 978-1098166045 | `[todo]` |
+| Terraform: Up and Running (3rd ed.) | Yevgeniy Brikman | 978-1098166045 | `[done]` |
 | Continuous Delivery | Humble, Farley | 978-0321601912 | `[done]` |
 ## Standardy
--- a/sources/cloud/sources.md
+++ b/sources/cloud/sources.md
@@ -13,20 +13,20 @@
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
-| Cloud Architecture Patterns | Bill Wilder | 978-1449319779 | `[todo]` |
+| Cloud Architecture Patterns | Bill Wilder | 978-1449319779 | `[done]` |
-| Building Evolutionary Architectures | Ford, Parsons, Kua | 978-1492097549 | `[todo]` |
+| Building Evolutionary Architectures | Ford, Parsons, Kua | 978-1492097549 | `[done]` |
 ## Nové knihy (2024–2026)
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
-| Multi-Cloud Administration Guide | — | 978-1-5015-1948-2 | `[todo]` |
+| Multi-Cloud Administration Guide | Jeroen Mulder | 978-1-5015-1948-2 | `[done]` |
-| AWS for Solutions Architects (3rd ed.) | Shrivastava, Srivastav, Thakur | 978-1-83664-193-3 | `[todo]` |
+| AWS for Solutions Architects (3rd ed.) | Shrivastava, Srivastav, Thakur | 978-1-83664-193-3 | `[done]` |
-| Engineering Resilient Systems on AWS | Schwarz, Moran, Bachmeier | 978-1-098-16241-2 | `[todo]` |
+| Engineering Resilient Systems on AWS | Schwarz, Moran, Bachmeier | 978-1-098-16241-2 | `[done]` |
-| Building Resilient Architectures on AWS | — | 978-1-83588-711-0 | `[todo]` |
+| Building Resilient Architectures on AWS | — | 978-1-83588-711-0 | `[done]` |
-| Multi-Cloud Handbook for Developers | Natarajan, Jacob | 978-1-80461-709-0 | `[todo]` |
+| Multi-Cloud Handbook for Developers | Natarajan, Jacob | 978-1-80461-709-0 | `[done]` |
-| The Azure Cloud Native Architecture Mapbook (2nd ed.) | Stéphane Eyskens | 978-1-80580-505-2 | `[todo]` |
+| The Azure Cloud Native Architecture Mapbook (2nd ed.) | Stéphane Eyskens | 978-1-80580-505-2 | `[done]` |
-| Cloud Computing: AWS, Azure, and Google Cloud | Azhar ul Haque Sario | 978-3384756886 | `[todo]` |
+| Cloud Computing: AWS, Azure, and Google Cloud | Azhar ul Haque Sario | 978-3384756886 | `[done]` |
 ## Certifikace
--- a/sources/databases/sources.md
+++ b/sources/databases/sources.md
@@ -16,14 +16,14 @@
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
 | Designing Data-Intensive Applications (1st ed.) | Martin Kleppmann | 978-1449373320 | `[done]` |
-| Designing Data-Intensive Applications (2nd ed.) | Kleppmann, Riccomini | 978-1098119058 | `[todo]` |
+| Designing Data-Intensive Applications (2nd ed.) | Kleppmann, Riccomini | 978-1098119058 | `[done]` |
 | Database Internals | Alex Petrov | 978-1492040346 | `[done]` |
-| High Performance MySQL | Schwartz, Zaitsev, Tkachenko | 978-1492080510 | `[todo]` |
+| High Performance MySQL | Schwartz, Zaitsev, Tkachenko | 978-1492080510 | `[done]` |
-| PostgreSQL: Up and Running | Regina Obe, Leo Hsu | 978-1491963418 | `[todo]` |
+| PostgreSQL: Up and Running | Regina Obe, Leo Hsu | 978-1491963418 | `[done]` |
-| Architecting an Apache Iceberg Lakehouse | Alex Merced | 978-1-63343-510-0 | `[todo]` |
+| Architecting an Apache Iceberg Lakehouse | Alex Merced | 978-1-63343-510-0 | `[done]` |
-| More SQL Antipatterns | Bill Karwin | 979-8888652060 | `[todo]` |
+| More SQL Antipatterns | Bill Karwin | 979-8888652060 | `[done]` |
-| AI-Ready PostgreSQL 18 | Vibhor Kumar, Marc Linster | 978-1-80602-847-4 | `[todo]` |
+| AI-Ready PostgreSQL 18 | Vibhor Kumar, Marc Linster | 978-1-80602-847-4 | `[done]` |
-| Vector Databases | Nitin Borwankar | 978-1-098-17758-4 | `[todo]` |
+| Vector Databases | Nitin Borwankar | 978-1-098-17758-4 | `[done]` |
 ## Články / přednášky
@@ -31,4 +31,4 @@
 |-------|-----|--------|
 | CAP Theorem (Eric Brewer) | https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/ | `[done]` |
 | PACELC theorem | https://www.cs.umd.edu/~abadi/papers/abadi-pacelc.pdf | `[done]` |
-| Amazon Dynamo DB paper | https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf | `[todo]` |
+| Amazon Dynamo DB paper | https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf | `[done]` |
--- a/sources/infrastructure/sources.md
+++ b/sources/infrastructure/sources.md
@@ -30,23 +30,23 @@ Rozděleno do samostatných souborů:
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
-| The Data Center as a Computer (1st ed. → 4th ed. 2025) | Barroso, Hölzle, Ranganathan | 978-3-031-99488-3 | `[todo]` |
+| The Data Center as a Computer (1st ed. → 4th ed. 2025) | Barroso, Hölzle, Ranganathan | 978-3-031-99488-3 | `[done]` |
-| Storage Systems | Ganger, Gibson | 978-1680837540 | `[todo]` |
+| Storage Systems | Ganger, Gibson | 978-1680837540 | `[done]` |
-| Virtualization Essentials | Matthew Portnoy | 978-1119481513 | `[todo]` |
+| Virtualization Essentials | Matthew Portnoy | 978-1119481513 | `[done]` |
-| VMware vSphere Design (2nd ed.) | Forbes Guthrie, Scott Lowe | 978-1119130312 | `[todo]` |
+| VMware vSphere Design (2nd ed.) | Forbes Guthrie, Scott Lowe | 978-1119130312 | `[done]` |
-| AI Data Center Network Design and Technologies (1st ed.) | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | `[todo]` |
+| AI Data Center Network Design and Technologies (1st ed.) | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | `[done]` |
-| Electronics Cooling: From the Chip to the Datacenter | Abraham et al. | 978-0-443-47084-4 | `[todo]` |
+| Electronics Cooling: From the Chip to the Datacenter | Abraham et al. | 978-0-443-47084-4 | `[done]` |
-| The AI Cloud Infrastructure Blueprint | Thummarakoti, Vududala, Madupati, Kaushik | 978-1-041-16642-9 | `[todo]` |
+| The AI Cloud Infrastructure Blueprint | Thummarakoti, Vududala, Madupati, Kaushik | 978-1-041-16642-9 | `[done]` |
 ## Server connectivity
 | Zdroj | URL | Status |
 |-------|-----|--------|
-| HPE Gen11 NIC selection guide | https://www.hpe.com/psnow/doc/a50007643enw | `[todo]` |
+| HPE Gen11 NIC selection guide | https://www.hpe.com/psnow/doc/a50007643enw | `[done]` |
-| Broadcom / Emulex FC HBA specs | https://www.broadcom.com/products/storage/fibre-channel-host-bus-adapters | `[todo]` |
+| Broadcom / Emulex FC HBA specs | https://www.broadcom.com/products/storage/fibre-channel-host-bus-adapters | `[done]` |
-| NVIDIA Mellanox Ethernet + InfiniBand adapters | https://www.nvidia.com/en-us/networking/ethernet/ | `[todo]` |
+| NVIDIA Mellanox Ethernet + InfiniBand adapters | https://www.nvidia.com/en-us/networking/ethernet/ | `[done]` |
-| NVMe-oF specification (NVM Express Inc.) | https://nvmexpress.org/specifications/ | `[todo]` |
+| NVMe-oF specification (NVM Express Inc.) | https://nvmexpress.org/specifications/ | `[done]` |
-| Dell PowerEdge R760 NIC placement guide | https://www.dell.com/support/manuals/en-us/oth-r760/per760_ism_pub/ | `[todo]` |
+| Dell PowerEdge R760 NIC placement guide | https://www.dell.com/support/manuals/en-us/poweredge-r760/per760_ism_pub/ | `[done]` |
 ## Server memory — osazování DIMM
@@ -56,9 +56,26 @@ Rozděleno do samostatných souborů:
 | Dell PowerEdge R760 — General Memory Module Installation Guidelines | https://www.dell.com/support/manuals/en-al/oth-r760/per760_ism_pub/general-memory-module-installation-guidelines | `[done]` |
 | HPE Gen11 Server Memory Population Rules (4th Gen Intel Xeon) | https://www.hpe.com/psnow/doc/a50007437enw | `[done]` |
 | HPE Gen11 Server Memory Population Rules (5th Gen Intel Xeon) | https://www.hpe.com/psnow/doc/a50010242enw | `[done]` |
-| HPE Gen11/Gen12 Server Memory Population Rules (AMD EPYC 9005) | https://www.hpe.com/psnow/doc/a50010243enw | `[todo]` |
+| HPE Gen11/Gen12 Server Memory Population Rules (AMD EPYC 9005) | https://www.hpe.com/psnow/doc/a50012817enw | `[done]` |
 | Single Rank vs Dual Rank vs Quad Rank vs Octa Rank Memory | https://corewavelabs.com/single-rank-vs-dual-rank-vs-quad-vs-octa-memory/ | `[done]` |
 ## Enterprise storage
 | Zdroj | URL | Status |
 |-------|-----|--------|
 | Hitachi VSP 5000 series datasheet | https://www.hitachivantara.com/en-us/products/storage/vsp-5000-series | `[done]` |
 | Hitachi VSP E series datasheet | https://www.hitachivantara.com/en-us/products/storage/vsp-e-series | `[done]` |
 | Huawei OceanStor Dorado V6 datasheet | https://e.huawei.com/en/products/storage/all-flash-storage/dorado-8000 | `[done]` |
 | Huawei OceanStor Dorado V7 announcement | https://e.huawei.com/en/news/2025/oceanstor-dorado-v7 | `[done]` |
 | Dell PowerStore documentation | https://www.dell.com/en-us/dt/storage/powerstore.htm | `[done]` |
 | Dell PowerMax documentation | https://www.dell.com/en-us/dt/storage/powermax.htm | `[done]` |
 | HPE Alletra documentation | https://www.hpe.com/us/en/storage/alletra.html | `[done]` |
 | Infinidat InfiniBox SSA G4 datasheet | https://www.infinidat.com/en/products/infinibox-ssa | `[done]` |
 | Pure Storage FlashArray documentation | https://www.purestorage.com/products/flasharray.html | `[done]` |
 | Lenovo ThinkSystem DM series docs | https://lenovopress.com/storage/thinkstorage/dm-series | `[done]` |
 | Lenovo ThinkSystem DE series docs | https://lenovopress.com/storage/thinkstorage/de-series | `[done]` |
 | Synology Unified Controller datasheet | https://www.synology.com/en-us/products/UC3400 | `[done]` |
 ## Výrobci hardware
 | Výrobce | Serverové řady | Management |
--- a/sources/monitoring/sources.md
+++ b/sources/monitoring/sources.md
@@ -14,8 +14,8 @@
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
 | Site Reliability Engineering | Beyer, Jones, Petoff, Murphy | 978-1491929124 | `[done]` |
-| The Site Reliability Workbook | Beyer, Jones, Petoff, Murphy | 978-1492029502 | `[todo]` |
+| The Site Reliability Workbook | Beyer, Jones, Petoff, Murphy | 978-1492029502 | `[done]` |
-| Observability Engineering | Majors, Fong-Pong | 978-1492076445 | `[todo]` |
+| Observability Engineering | Majors, Fong-Pong | 978-1492076445 | `[done]` |
 ## Články
@@ -31,19 +31,19 @@
 |-------|-------|------|--------|
 | Mastering OpenTelemetry and Observability | Steve Flanders | 978-1-394-25312-8 | `[done]` |
 | OpenTelemetry Cookbook | — | 978-9349174238 | `[done]` |
-| Cloud Observability in Action | — | — | `[todo]` |
+| Cloud Observability in Action | Michael Hausenblas | — (Manning, 2023) | `[done]` |
-| Observability in the AI-Native Era | Lipsig, Grabner, Rati | 978-1-80638-959-9 | `[todo]` |
+| Observability in the AI-Native Era | Lipsig, Grabner, Rati | 978-1-80638-959-9 | `[done]` |
-| Mastering Prometheus | William Hegedus | 978-1-80512-566-2 | `[todo]` |
+| Mastering Prometheus | William Hegedus | 978-1-80512-566-2 | `[done]` |
-| Observability with Grafana (LGTM stack) | — | 978-1-80324-964-3 | `[todo]` |
+| Observability with Grafana (LGTM stack) | Chapman, Holmes | 978-1-80324-964-3 | `[done]` |
-| Open Source Observability | Corless, Pawar | — (O'Reilly, 2025) | `[todo]` |
+| Open Source Observability | Corless, Pawar | — (O'Reilly, 2025) | `[done]` |
-| Hands-On Monitoring and Alerting with Prometheus | Muhammad Badawy | 978-9349887565 | `[todo]` |
+| Hands-On Monitoring and Alerting with Prometheus | Muhammad Badawy | 978-9349887565 | `[done]` |
 ## Nové nástroje (2024–2026)
 | Nástroj | Popis | URL | Status |
 |---------|-------|-----|--------|
-| Grafana Sigil | AI observability (OpenTelemetry-native) | https://github.com/grafana/sigil | `[todo]` |
+| Grafana Sigil | AI observability (OpenTelemetry-native) | https://github.com/grafana/sigil | `[done]` |
-| InfraLens | eBPF-based zero-instrumentation observability | https://github.com/Herenn/Infralens | `[todo]` |
+| InfraLens | eBPF-based zero-instrumentation observability | https://github.com/Herenn/Infralens | `[done]` |
-| Ingero | GPU causal observability (eBPF) | https://github.com/ingero-io/ingero | `[todo]` |
+| Ingero | GPU causal observability (eBPF) | https://github.com/ingero-io/ingero | `[done]` |
-| GreptimeDB | Unified observability DB (OTel-native) | https://github.com/GreptimeTeam/greptimedb | `[todo]` |
+| GreptimeDB | Unified observability DB (OTel-native) | https://github.com/GreptimeTeam/greptimedb | `[done]` |
-| Netdata | AI-powered full-stack observability | https://github.com/netdata/netdata | `[todo]` |
+| Netdata | AI-powered full-stack observability | https://github.com/netdata/netdata | `[done]` |
--- a/sources/networking/sources.md
+++ b/sources/networking/sources.md
@@ -24,17 +24,17 @@
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
 | Computer Networking: A Top-Down Approach | Kurose, Ross | 978-0133594140 | `[done]` |
-| TCP/IP Illustrated | W. Richard Stevens | 978-0321336316 | `[todo]` |
+| TCP/IP Illustrated | W. Richard Stevens | 978-0321336316 | `[done]` |
 ## Nové knihy (2024–2026)
 | Název | Autor | ISBN | Status |
 |-------|-------|------|--------|
-| AI Data Center Network Design and Technologies | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | `[todo]` |
+| AI Data Center Network Design and Technologies | Subramaniam, Styszynski, Tambakuwala | 978-0-13-543628-8 | `[done]` |
-| Cloud Networking and Resilience | Cristian Critelli | 979-8868824357 | `[todo]` |
+| Cloud Networking and Resilience | Cristian Critelli | 979-8868824357 | `[done]` |
-| Zero Trust in Resilient Cloud and Network Architectures | Halley, Prajapati, Leza, Saini | 978-0-13-820460-0 | `[todo]` |
+| Zero Trust in Resilient Cloud and Network Architectures | Halley, Prajapati, Leza, Saini | 978-0-13-820460-0 | `[done]` |
-| The Segmentation Blueprint | Kulkarni, Sivakumar, Morais, Lloyd | 978-0-13-546236-2 | `[todo]` |
+| The Segmentation Blueprint | Kulkarni, Sivakumar, Morais, Lloyd | 978-0-13-546236-2 | `[done]` |
-| Segment Routing for SP and Enterprise Networks | Deragisch et al. | 978-0-13-823101-9 | `[todo]` |
+| Segment Routing for SP and Enterprise Networks | Deragisch et al. | 978-0-13-823101-9 | `[done]` |
-| Understanding and Designing Azure Networking | Stuart, Moreno | — (2025) | `[todo]` |
+| Understanding and Designing Azure Networking | Stuart, Moreno | — (2025) | `[done]` |
-| Mastering Next-Gen Juniper Data Centers | — | 978-0-13-533636-6 | `[todo]` |
+| Mastering Next-Gen Juniper Data Centers | Aninda Chatterjee | 978-0-13-533636-6 | `[done]` |
-| Intelligent Cloud Networking: AI-Driven Resource Management | Manoj Yadav | 9364220110 | `[todo]` |
+| Intelligent Cloud Networking: AI-Driven Resource Management | Manoj Yadav | 9364220110 | `[done]` |