Programování

Azure Cosmos DB funguje bez serveru

Azure Cosmos DB je jednou ze základen platformy a poskytuje mnoho jejích klíčových služeb. Navržen od základu jako distribuovaná databáze, implementuje sadu různých modelů konzistence, které vám umožní vyměnit výkon a latenci pro vaše aplikace. Pak existují různé modely pro práci s daty, od známých rozhraní NoSQL a SQL API, podpory rozhraní API Mongo DB až po grafický databázový stroj Gremlin.

V Cosmos DB je dost na podporu nejběžnějších scénářů vývoje cloudu, což vám dává konzistentní datovou platformu, která může sdílet data v globálním měřítku. Microsoft ji často popisuje jako „databázi v planetárním měřítku“, vhodný popis.

Bezserverová alternativa k zřízené propustnosti

Pro všechny výhody má Cosmos DB některé nevýhody; v neposlední řadě jeho náklady. I když je k dispozici relativně omezená bezplatná možnost, její spuštění v měřítku může být nákladné, a to musíte brát v úvahu při vytváření aplikací kolem ní. Rozpočet pro jednotky požadavku Cosmos DB je složitý proces, který je těžké získat hned na první pohled, zvláště když zohledníte měřítko, ať už ručně nebo automaticky.

Společnost Microsoft již nějakou dobu spustila náhled možnosti bez serveru pro Cosmos DB na základě svého základního rozhraní SQL API. Je to zajímavá alternativa k tradičně zajišťované možnosti. Účtuje vám to pouze v případě, že je spuštěn požadavek, a pozastaví vaši instanci, když se nic neděje. V databázových operacích bude existovat další latence, protože vaše instance se musí roztočit, když bude pozastavena. Úložiště je samozřejmě zpoplatněno, ale to je stejné s jakoukoli databází Azure. Počáteční zkušební verze byla nyní rozšířena na všechna rozhraní Cosmos DB API, přičemž obecná dostupnost v budoucnu nebude příliš daleko.

Přidání možnosti bez serveru do Cosmos DB má velký smysl pro mnoho typů úloh, kde dostáváte požadavky v malém počtu a v dávkách. Pro malé pracovní vytížení s nepravidelným vzorem operací má cenový model založený na spotřebě velký smysl - a může dlouhodobě ušetřit značné množství peněz, protože neexistuje žádný závazek zajišťovat propustnost.

Náklady jsou nízké: Za jednotku požadavku bez serveru zaplatíte 0,282 USD, a to až za milion RU ve fakturačním cyklu. Pokud potřebujete spolehlivější server, můžete nastavit zónu dostupnosti, což ale zvyšuje náklady o 1,25x. To je stále rozumná dohoda a to, co ztratíte na předvídatelnosti, získáte na nižších nákladech. Náklady na úložiště zůstávají stejné pro manuální i automatickou zřízenou propustnost.

Začínáme s Cosmos DB bez serveru

Skákání je dost snadné. Stejně jako standardní účet Cosmos DB jej budete muset zřídit k předplatnému a přidat instanci bez serveru do skupiny prostředků. Dále vyberte API, které plánujete použít pro dotazy, a když budete požádáni o výběr režimu kapacity, vyberte spíše bez serveru než zřízenou propustnost. Nakonec jej propojte s oblastí a nezapomeňte, že můžete použít serverless pouze v jedné oblasti Azure; neexistuje možnost geo-redundance. Nebudete jej moci používat ani na bezplatné úrovni.

Jakmile je vaše instance bez serveru spuštěna, můžete pomocí jejích rozhraní API načítat data a provádět dotazy. Stejně jako standardní instance Cosmos DB můžete vytvářet funkce a spouštěče JavaScriptu, které běží uvnitř databáze, a také používat jejich mnoho různých API ke správě dotazů.

Serverless Cosmos DB by se měl brzy odebrat z náhledu a přidává podporu pro všechny své API, dokonce i pro své nedávné API Cassandra. Jelikož se jedná o veřejný náhled, můžete jej nastavit a prozkoumat jeho provoz přímo z Azure Portal. Zatímco v náhledu neexistuje žádná podpora pro ARM nebo jinou infrastrukturu jako nástroje pro nasazení kódu, měla by tam být, jakmile je služba obecně dostupná. Konfiguraci a nasazení nemůžete automatizovat, takže ji zatím nebudete moci používat jako součást kanálu CI / CD (průběžná integrace / průběžné doručování), protože nasazení bude muset být manuální.

Vytváření kódu se serverem Cosmos DB

Jedno místo, které byste měli získat ze serveru Cosmos DB bez serveru, je paralelní s Azure Functions. Dvě prostředí bez serveru fungují dobře a jsou ideální pro rychlé, maloobjemové aplikace založené na událostech. Serverless Cosmos DB může rychle stoupat z nuly na 5 000 jednotek požadavku za sekundu, takže pokud píšete kód, který pomocí funkcí sleduje chyby nebo jiné výstrahy, je to možnost rychlého shromažďování a ukládání dat.

Společnost Microsoft doporučuje používat jej jako součást vývojového prostředí, kde pořizujete data o požadavcích, které vaše aplikace potřebuje. Jelikož jednotky zajišťování požadavků jsou něco jako černé umění, je užitečným vývojovým nástrojem implementace bez serveru spuštěná se všemi vašimi databázovými kódy. Můžete nastavit provozní prostředí, spustit testy, zachytit počet použitých požadavků a poté použít tato data k zajištění propustnosti pro produkční nasazení.

Pochopení omezení bez serveru

Existují omezení používání účtu Cosmos DB bez serveru. Snad nejdůležitější je, že nemáte přístup k multiregionovým nasazením, protože účty bez serveru běží pouze v jedné oblasti. Je to omezení, které dává smysl: Implementace Multiregion Cosmos DB vyžadují více instancí spuštěných současně pro meziregionální replikaci a konzistenci. Pokud se instance bez serveru budou spouštět pouze v době, kdy zpracovávají požadavky, neexistuje žádná záruka, že další oblast bude online pro zpracování replikace. Výsledkem jsou změny cíle služby Cosmos DB pro instance bez serveru, u kterých se očekává, že zápis bude 30 ms nebo méně a přečte 10 ms nebo méně.

Dalším klíčovým omezením je maximálně 5 000 jednotek požadavku za sekundu. Opět by to mělo stačit pro většinu jednoduchých nebo vývojových implementací, ale vyžaduje to, abyste sledovali své aplikace a byli připraveni přejít na zřízenou instanci Cosmos DB, pokud pravidelně překračujete své limity. Současně může každý kontejner bez serveru uložit pouze 50 GB dat a indexů. Microsoft poskytuje nástroje na portálu Azure Portal, které pomáhají monitorovat operace i v Azure Monitor.

Přidání možnosti bez serveru do Cosmos DB odpovídá na mnoho otázek ohledně nákladů. Pro scénáře s nízkým využitím, kde nepotřebujete globální pokrytí, by to měla být vaše první volba. Přechod na používání instance zřízené propustnosti se provede pouze v případě, že jste schopni porozumět vzoru požadavku vaší aplikace a můžete podle toho rozpočet.