DynamoDB umí hledat podle významu. AWS odstranilo jeden důležitý mezikrok pro AI aplikace

DynamoDB už nehledá jen přesný klíč

Amazon DynamoDB je cloudová NoSQL databáze určená především pro aplikace, které potřebují rychle ukládat a načítat data bez správy serverů. Typicky v ní najdete uživatelské profily, objednávky, stav herních účtů nebo historii konverzací AI agenta.

Nová funkce přidává další způsob práce s daty: vektorové vyhledávání. To nefunguje jako klasické hledání podle přesného textu. Místo toho porovnává číselné reprezentace obsahu, takzvané embeddingy. Věta „jak ušetřit za elektřinu“ tak může najít dokument o spotřebě domácnosti, i když v něm přesná fráze vůbec není.

AWS oznámilo obecnou dostupnost této funkce 5. srpna 2026. Podle firmy dokáže DynamoDB provádět přibližné hledání nejbližších sousedů s latencí v jednotkách milisekund a recall přes 99 %. Jde o údaje uváděné AWS, nikoli o nezávislý benchmark porovnávající všechny konkurenční databáze. Oficiální oznámení AWS zároveň uvádí podporu pro datové sady v řádu miliard až bilionů vektorů.

Jak vektorové vyhledávání funguje v praxi

Nejprve je potřeba text, obrázek nebo jiný obsah převést pomocí embeddingového modelu na vektor. Ten si lze představit jako dlouhý seznam čísel, která zachycují význam daného obsahu. Dva podobné texty pak mají v tomto číselném prostoru podobnou polohu.

Embedding může vzniknout například v Amazon Bedrocku, ale AWS neomezuje vývojáře na jeden konkrétní model. Použít lze model podle vlastního výběru, pokud jeho výstup odpovídá nastavenému počtu dimenzí. DynamoDB podporuje vektory až do 4096 dimenzí. Nový vektorový index se následně vytvoří nad atributem tabulky a dotaz se provádí přes API SearchVectors.

Vývojář si při vytváření indexu vybírá také způsob měření podobnosti:

• Cosine porovnává směr vektorů a hodí se pro sémantické hledání v dokumentech nebo produktových popisech.
• Dot product zohledňuje směr i velikost vektoru, což může být užitečné například u doporučovacích systémů.
• Euclidean měří přímou vzdálenost mezi body a dává smysl například při hledání podobných obrázků nebo anomálií.

Podrobnosti k indexům a podporovaným funkcím popisuje dokumentace DynamoDB. Důležitý detail: vektorový index není totéž co běžný sekundární index. Klasický index pracuje s přesnou shodou nebo rozsahem hodnot, zatímco vektorový index hledá přibližně nejpodobnější položky.

Proč je společné úložiště důležité

Dosud musel tým, který chtěl nad daty v DynamoDB používat sémantické hledání, často postavit druhou část infrastruktury. Data se kopírovala do OpenSearch nebo jiné vektorové databáze, embeddingy se generovaly v samostatném procesu a změny se synchronizovaly přes streamy či exporty.

AWS tento model stále podporuje. Zero-ETL integrace DynamoDB s OpenSearch umožňuje kombinovat provozní data s pokročilým vyhledáváním a analytikou. Jenže každá další služba přidává vlastní konfiguraci, oprávnění, monitoring a možnost, že se data na chvíli rozejdou.

U nativního vektorového indexu je embedding uložený přímo u položky v DynamoDB. Když aplikace najde podobný dokument, produkt nebo vzpomínku z konverzace, může získat i příslušná aplikační data bez dalšího dotazu do primární databáze. To je podobné jako mít katalog a rejstřík v jedné skříni, místo abyste pro každou položku běhali do jiné budovy.

Právě synchronizace bývá v produkčních AI aplikacích nepříjemnější než samotné vytvoření embeddingů. Pokud někdo smaže produkt, aktualizuje dokument nebo změní oprávnění uživatele, musí se změna propsat také do vektorového úložiště. Jedna databáze tento problém neřeší úplně automaticky, ale odstraňuje jednu z hlavních příčin nekonzistence.

Nejzajímavější scénáře pro AI aplikace

AWS uvádí několik případů použití, které dávají technický smysl:

• RAG aplikace: jazykový model si před odpovědí vyhledá relevantní dokumenty podle významu.
• Paměť AI agentů: starší konverzace, rozhodnutí a uživatelské preference lze ukládat jako embeddingy a později vyhledávat podle kontextu.
• Doporučování: systém může hledat podobné produkty, články, videa nebo uživatele.
• Sémantické vyhledávání: zákazník nemusí znát přesný název produktu ani formulaci dokumentu.
• Detekce anomálií: nové chování lze porovnat s běžnými vzory nebo známými podvody.

Pro české firmy je podstatné, že nejde o samostatnou aplikaci s českým rozhraním, ale o cloudovou vývojářskou službu. Funkce je dostupná v komerčních AWS regionech včetně evropských regionů. Dostupnost v evropském regionu sama o sobě neřeší požadavky na rezidenci a zpracování dat. Dokumentace a konzole AWS jsou primárně v angličtině. Samotné vyhledávání ale může pracovat s českými texty, pokud použitý embeddingový model češtinu dostatečně podporuje. AWS u této funkce negarantuje konkrétní úroveň kvality pro český jazyk, takže ji bude nutné otestovat na vlastních datech.

Výkon zní dobře, účet může být zajímavější

Vektorové vyhledávání není automaticky levné jen proto, že je serverless. Podle aktuální dokumentace AWS má vektorový index vlastní vector index capacity units (VIU) a používá třídu DynamoDB Standard. Při odhadu nákladů je proto potřeba oddělit několik položek: běžné účtování tabulky DynamoDB, kapacitu a uložená data samotného vektorového indexu, data zpracovaná při dotazech a náklady na generování embeddingů v Amazon Bedrocku nebo jiné službě.

Vývojáři mohou náklady ovlivnit několika praktickými volbami. Menší počet dimenzí znamená méně uložených dat. U velkých datových sad pomáhá také rozdělení indexu pomocí partition key. Dotaz pak nemusí prohledávat celý vektorový prostor.

Rozpočet proto nestačí počítat pouze podle ceny tabulky. Samostatně je nutné sledovat kapacitu a úložiště vektorového indexu, objem dat zpracovaných při dotazech a také cenu služby, která embeddingy vytváří. Konkrétní částka se bude odvíjet od velikosti vektorů, počtu zápisů, frekvence hledání a počtu přidělených vector index capacity units.

DynamoDB není univerzální náhradou za vektorovou databázi

Novinka dává největší smysl firmám, které už DynamoDB používají jako hlavní databázi a potřebují k ní přidat sémantické hledání. Pro menší až střední RAG aplikaci, paměť agenta nebo produktové doporučování může být jednodušší mít data na jednom místě.

Neznamená to ale, že OpenSearch, S3 Vectors nebo specializované vektorové databáze ztrácejí smysl. OpenSearch nabízí širší vyhledávací funkce včetně fulltextu, analytiky a hybridního hledání. S3 Vectors je navržený pro velké objemy vektorů s důrazem na nákladově efektivní úložiště. AWS samo ve svém přehledu databází doporučuje různé služby podle typu workloadu, nikoli jeden univerzální produkt.

Dalším limitem je, že vektorové hledání pracuje s přibližným výsledkem. Výhoda spočívá ve škálovatelnosti a rychlosti, nikoli v matematicky absolutní jistotě, že pokaždé najde všechny relevantní položky. U právních dokumentů, medicínských dat nebo finančních systémů proto stále dává smysl kombinovat vektorové hledání s přesnými filtry, oprávněními a následnou kontrolou výsledků.

Verdikt: méně lepidla mezi službami, ne méně práce

AWS přidalo do DynamoDB funkci, která může výrazně zjednodušit architekturu AI aplikací. Největší přínos není v samotném vyhledávání embeddingů, protože to dnes umí řada databází. Podstatné je, že vektorový index je nyní součástí stejného datového modelu jako provozní položky aplikace.

Pro vývojáře to znamená méně synchronizačních mechanismů, méně přesunů dat a jednodušší návrh aplikací, které kombinují klasické dotazy s hledáním podle významu. Dotazy mohou filtrovat atributy, návrh ale musí počítat s partition key vektorového indexu a s rozsahem prohledávaných dat.

DynamoDB se tím nestává nejlepší volbou pro každý vektorový workload. Stává se ale podstatně zajímavější volbou pro týmy, které už v něm mají aplikaci a nechtějí kvůli AI stavět druhý datový systém. V cloudu je to často rozdíl mezi architekturou, kterou lze vysvětlit na jedné tabuli, a architekturou, na kterou potřebujete šipky, barvy a trochu kávy.

FAQ

Zdroje: AWS – oznámení dostupnosti vektorového vyhledávání, AWS – dokumentace k vektorovým indexům, AWS Database Blog – praktická ukázka a účtování, InfoQ – komentář k uvedení funkce.