DynamoDB: Tajná zbraň serverless designu

Intro

Dělal jsem kdysi pro malý startup jeden projekt a měl jsem vymazlený docker-based setup, který mi dělal radost. Už to bylo pár let, co jsem prvně viděl docker-compose magii, kterou jsem si velmi oblíbil: pěkně si ten systém dekomponujete, zabalíte tam frontend, backend, databázi, proxynu, všechno open-source technologie... no a pak to prostě pustíte. A ono to jede.

Je v tom ale jeden háček. Musíte mít, kde to pustit.

Pro vývojáře je to super. Celý setup běží na jejich stroji, přes VS Code si tam vlezete, pustíte debugger, prostě paráda. A když se to pustí na serveru, tak to běží úplně stejně – stačí jen (jednou) nakonfigurovat firewall, DNSku, certifikáty a jedete. Než jsem pořádně poznal cloud, který v té době pro mě byl prostě "počítače, které nevlastním, ale pronajímám si je", měl jsem za to, že tohle není jen nejlepší způsob, jak to dělat. Že je to jediný způsob.

No jo, ale teď přišla otázka: Jak to vyškálujeme?

Měl jsem tam sice výkonnou Postgres databázi, ale už jsem viděl, jak mi to zkuhrává, když se tam připojí několik lidí najednou (měli jsme pronajatý poměrně levný a malý server). A já – člověk, který se nerad zasekává v lokálních optimech – jsem si řekl, že je načase to prostě zahodit a začít znovu.

A tak jsem se dostal do světa AWS, kde jsem jako jednu z prvních služeb poznal DynamoDB.

Co je to vlastně to Dynamo?

Pro uživatele (programátora) je tahle databáze prakticky jen hashovací tabulka, která má v každém chlívku pro hodnoty ještě B-stromy kvůli řazení hodnot v rámci jednoho chlívku. Na první pohled extrémně jednoduchý setup, který se komplexním relačním joinům nikdy nemůže rovnat.

Kouzlo je v tom, jak se ptáte. Funguje to na principu dvou klíčů:

• Partition Key (Hash): Odpovídá na otázku "Kde najdu data?". V realitě identifikuje fyzický stroj, na kterém jsou data uložena. Díky tomu databáze ví přesně, kam sáhnout. Je to operace v konstantním čase (lusknutím prstu) nezávislá na tom, kolik dat ve skutečnosti máte.
• Sort Key (Range): Uvnitř té jedné partition umožňuje data řadit a modelovat vztahy. Třeba 1:N (Zákazník -> Objednávky) nebo hierarchické vztahy.

Zbytek položky je (téměř) libovolný JSON.

Dynamo je ale mnohem víc než jen obyčejný key/value store. Všem zájemcům doporučuju přečíst klasickou The DynamoDB Book, která mně osobně výrazně pomohla pochopit, jak tuhle technologii ohnout ve svůj prospěch.

Alternativy? Proč nejdu s davem

Nejsme jediní, kdo DynamoDB využívá, ale zdaleka nejsme ve většině. K lednu 2026 je Dynamo až 18. z hlediska popularity mezi vývojáři. Je to poměrně obskurní databáze, a mám spoustu kolegů, kteří o ní ani neslyšeli. Proč ho tedy používám, když ostatní evidentně jedou na něčem jiném?

1. Relační klasika (SQL, Postgres, MySQL)

To je stará škola. Jsou optimalizované pro úložiště – data normalizujeme, abychom je neukládali dvakrát.

• Výhoda: Flexibilita. Objeví se nový požadavek od byznysu? Nevadí, napíšeme nový SQL dotaz.
• Problém: Škálování. Relační databáze velmi špatně škálují horizontálně (přidávání serverů). Musíte kupovat větší a silnější stroje (vertikální škálování). A to nejde dělat do nekonečna.
• Verdikt: U SQL platíte za flexibilitu obtížným škálováním.

2. Redis

Redis je primárně in-memory cache. Je rychlý, ale data drží v RAM. Velmi užitečné pro dočasné ukládání dat pro rychlé znovupoužití, ale...

• Problém: Není to databáze pro trvalé uložení (objednávky, transakce). Jakmile se server restartuje nebo vypne proud, data zmizí.

3. MongoDB (fan favorite)

Mongo je fajn, vývojáři ho milují, protože tam "prostě hodí JSON". Ale v produkční zátěži má řadu nevýhod, které jsou okamžitý stop, kdykoliv se nad architekturou systému zamyslím:

• tzv. Connection Exhaustion: Mongo vyžaduje trvalé spojení přes TCP. Kdyby se najednou připojilo tisíc serverless funkcí, Mongo spadne na "Too many connections". Dynamo používá prosté HTTP, což je bezestavový protokol (jednorázová komunikace) – pošlete na něj sto tisíc dotazů naráz a ani to s ním nehne.
• Falešná flexibilita: Do Monga můžete naházet cokoliv a dělat nad tím libovolné dotazy snadno. Ale jakmile máte 10 milionů záznamů, jeden špatný dotaz položí celý server (scan celé kolekce). Místo 10 ms čekáte 10 vteřin, uživatele refreshují jako diví, a to zcela zbytečně.
• Údržba: Mongo pořád běží na nějakém clusteru. Někdo musí řešit verze, upgrady, servisní okna. Dynamo je služba, která prostě je. Žádné verze, žádné výpadky kvůli údržbě.

Kdybych to měl shrnout v jedné větě, volba mezi Mongem a Dynamem je volba mezi tím, co je snadné, a tím, co je správné.

Serverless? Co to znamená?

Je tu ještě jeden faktor, o kterém jsem zatím nemluvil. Faktor zajímavý nejen pro mě, ale hlavně i pro klienty. Náklady na provoz.

Ať už se bavíme o SQL, Mongu nebo mém starém docker-compose setupu, všechny spojuje jedna věc: server.
Stroj, který běží 24/7, každý den, každý měsíc, každý rok. Běží zbytečně v noci (kdy platíte za nic) a mele z posledního ve špičce (kdy nestíhá). Musíte řešit nejen patche, zálohy, upgrady verzí a podobně, ale k tomu ještě platit DevOpsákovo čas, aby se o server staral. Když vypadne elektřina, máte hotovo. Pokud nemáte perfektně replikovatelný, automatický setup, může se stát, že příjemné letní odpoledne, večer, noc, a kus rána strávíte znovunasazováním procesů, které drží klientský systém v chodu.

V podstatě od první chvíle, kdy jsem se dostal do světa cloudu, jsem přepnul na serverless. Neboli "bez serveru".
Funguje to jednoduše:

1. Přijde tisíc dotazů? Pustí se tisíc malých "kontejneříků", někde.
2. Obslouží se to.
3. Všechno se vypne.

Provider (jako třeba AWS) zařídí, aby to někde běželo. A co je fajn: Platíte jen za dobu, kdy se reálně něco počítalo. Je noc a uživatelé spí? Neplatíte ani korunu. Přijde deset dotazů? Pustí se deset obslužných kontejnerů. Přijde tisíc dotazů? Pustí se jich tisíc. Všechno pěkně automaticky a máme jistotu, že zátěž nemá vliv na výkon systému pro koncového uživatele.

Jak to vypadá v praxi?

Řekněme, že chceme vypsat objednávky z května 2025.

• Díky Hash Key ORDER ví Dynamo router přesně, na kterém fyzickém stroji data jsou.
• Díky Sort Key DATE#2025-05 a operaci begins_with vytahá z SSD disku jen ty konkrétní záznamy, které jsou fyzicky vedle sebe. A ony jsou vedle sebe, protože Dynamo ví, že když je tam dá, tak je bude moct extrémně rychle a tudíž i levně přečíst.

Neplatíte za běžící CPU, neplatíte za čekající routery. Platíte jen za těch pár kilobajtů, které se přečetly (tzv. RCU - Read Capacity Units). Znalý architekt tohle ví a navrhne data tak, aby čtení bylo co nejlevnější.

Závěr

Když se podíváme na starý svět, je plný SQL. Ale moderní cloudové systémy využívají serverless architektury, kde DynamoDB dominuje. Podle reportů Datadog ji využívá polovina firem, které přešly na moderní serverless stack.

Pro mě osobně je to ale spíš takový zajímavý hlavolam: jak na začátku projektu navrhnout data tak, aby byla odezva minimální a provoz stál minimum peněz, než se zbytek týmu pustí do bouchání kódu. :-)