Již je tomu několik let, co Amazon v rámci svého cloudového řešení AWS představil DynamoDB. DynamoDB je Amazonem plně spravovaná dokumentová NoSQL databáze. Možná nenabízí zásadně nové věci ve světě NoSQL databází, přesto má některé vlastnosti, kvůli kterým se o ní vyplatí uvažovat (Zvlástě pokud již Amazon AWS aktivně používáte).
Předně je třeba přiznat, že DynamoDB je prorietární technologie Amazonu. Pokud nehodláte Amazon AWS používat, je pro Vás DynamoDB mimo dosah. DynamoDB byla od počátku vyvíjeno jako cloudová databáze se všemi vlastnostmi, které jsou pro cloudy vlastní, jako škálovatelnost, vysoká dostupnost a bezpečnost Vašich dat. Není žádným tajemstvím, že v rámci platformy AWS sám Amazon DynamoDB aktivně používá.
Komunikace s databází probíhá pomocí HTTP protokolu a jak je již u Amazonu zvykem - nabízí knihovny pro všemožné (i nemožné) programovací jazyky. DynamoDB se tedy snadno používá a velmi snadno konfiguruje - V podstatě musíte pouze založit tabulku a říct Amazonu, jaký výkon potřebujete - zbytek zařídí Amazon. Jak už tomu u většiny NoSQL databází bývá, tak DynamoDB je schemaless.
Příjemnou vlastností DynamoDB je pružnost. Výkon pro čtení a zápis se řídí takzvanými Read Units respektive Write Units. Tyto je třeba pro každou tabulku při vytvoření zvolit, ale netřeba se bát přestřelení či podstřelení těchto hodnot. DynamoDB umožňuje za běhu tyto parametry snadno měnit. V extrému pak můžeme ve špičkách škálovat směrem vzhůru a během klidnějších období škálovat směrem dolů podle potřeby klidně několikrát za den.
Snadnější je to s Write Units, které udávají kolik zápisů během vteřiny je možné provést. Pokud tedy zvolíme 100 Write Units můžeme provést 100 zápisů během vteřiny. V tomto případě počítáme s tím, že blok dat má méně než 1KB, pokud má více, pak dostaneme poměrně méně zápisů během vteřiny. Toto naštěstí můžeme snadno monitorovat a můžeme být i upozorněni na eventualitu, kdy jsou všechny naše Write Units vyčerpány.
Jenom o málo složitější je to s Read Units. V zásadě máme dva možné režimy čtení: Strongly consistent read a Eventually consistent read. Strongly consistent read znamená, že vždy přečteme aktuální stav databáze. Eventually consistent read je optimalizován pro maximální propustnost, ale může se stát, že takto přečtená data nemusí reflektovat poslední zápis nad danou tabulkou. Odměnou za použití eventually consistent readu je nám dvojnásobná propustnost. Je tedy potřeba zvážit, co pro daný use case potřebujeme. Například pokud máme 100 Read units můžeme provést až 100 strongly consistent čtení za sekundu (do velikosti bloku 4KB) nebo 200 eventually consistent čtení za sekundu.
Cenový model je nesmírně jednoduchý. Platíme Amazonu za velkost naší databáze a za počet Read respektive Write Units. Dále máme možnost platit pouze za to, co aktuálně používáme nebo si můžeme určitou kapacitu Read/Write Units rezervovat, pak ale za tyto můsíme platit i kdybychom je nepoužívali.
Jako u většiny svých služeb na AWS i zde Amazon nabízí Free tier, kdy můžeme DynamoDB s určitými parametry používat zdarma. Pokud si tedy vystačíte s kapacitou do 25 GB, 25 Read Units a 25 Write Units, můžete využívat DynamoDB zcela zdarma.
Při vytváření tabulky v DynamoDB je zapotřebí specifikovat primární klíč této tabulky. Máme dvě možnosti, jak toto provést.
Partition key - jednoduchý primární klíč, který se zkládá právě z jednoho atributu. Ná základě tohoto klíče DynamoDB určí fyzickou lokaci (partition), kam se daný záznam uloží. Tento primární klíč musí být unikátní pro každý záznam v dané tabulce.
Partition key and sort key - Složený primární klíč ze dvou atributů. První je partion key podobně jako v předchozím případě. Zde ovšem nemusí být unikátní pro celou tabulku, na druhou stranu ovšem kombinace partition key a sort key unikátní být musí. Složený klíč nám dává větší flexibilitu (Pokud bychom měli tabulku Song a zvolili bychom partion key - “Artist” a sort key - “SongName” - pak můžeme snadno a efektivně napsat query pro songy interpreta).
Query - Query slouží pro nalezení záznamu v tabulce pomocí atributů primárního klíče. Případně je možné specifikovat, které atributy nás zajímají, jinak jsou vráceny všechny atributy tabulky. Na výstup lze aplikovat filtr a omezit tak výstup jen na záznamy, které nás zajímají. Tento přístup je analogický k index scanu v RDBMS.
|
|
Scan - Scan, jak již samotný název napovídá, provádí čtení celé tabulky. Stejně jako v předchozím případě můžeme omezit výstupní atributy, případně aplikovat filtr. Scan je samozřejmě mnohem pomalejší než Query a hodí se jen na opravdu malé tabulky.
|
|
Každá technologie má samozřejmě některé příjemné vlastnosti (o těch jste si mohli přečíst výše), ale i některé mínusy. Bohužel v základu není možné provádět téměř žádné agregační dotazy (Je ovšem dostupná integrace s Amazon EMR). Primární klíč a indexy mohou být vytvořené pouze na top level atributech. Maximální velikost result setu je 1MB, poté musíme výsledek stránkovat, a také samotný dotazovací jazyk není příliš mocný.
Pokud se přes nedostatky z poslední kapitoly dokážete přenést, dokáže AmazonDB nabídnout zajímavou alternativu. Osvobozuje Vás od správy databáze, přesto dává k dispozici zajímavou výkonnost, škálovatelnost a cloudu vlastní vysokou dostupnost. Zvláště kombinací CloudFront, Lambda a DynamoDB se dá vytvořit serverless architektura, která bude vysoce dostupná, bude mít minimální náklady pro správu a i cenově bude vcelku přívětivá (ale o tom zase někdy jindy).