Azure DocumentDB vs. MongoDB

Syntetické srovnání

DocumentDB je databáze typu NoSQL, která je součástí platformy Microsoft Azure. Jako sklad dokumentů spadá do stejné kategorie jako MongoDB, CouchDB nebo RethinkDB a stejně jako tyto zpracovává dokumenty ve formátu JSON.

Při zvažování integrace úložiště dokumentů NoSQL do jejich systémů si mnoho společností vybírá MongoDB, protože patří mezi nejoblíbenější NoSQL motory a v posledních letech se stalo velmi spolehlivým. Mám pocit, že DocumentDB se obvykle při tomto rozhodnutí nebere v úvahu, ačkoli jeho vlastnosti z něj činí vážného uchazeče o MongoDB, v některých situacích dokonce nabízejí silnější výhody.

Protože mám pocit, že DocumentDB nedostává lásku, kterou si zaslouží, rozhodl jsem se napsat toto syntetické a nezaujaté srovnání mezi DocumentDB a MongoDB, podporované odkazy na jejich příslušné dokumentace. Doufám, že vám to může posloužit jako průvodce při pokusech zvážit výhody a nevýhody každé platformy.

Aktualizace tohoto příspěvku

[Listopad 2016] Odstranil všechny zmínky o nedostatku lokálního emulátoru pro DocumentDB, protože společnost Microsoft oznámila obecnou dostupnost takové verze místního vývoje. Všimněte si, že místní emulátor je v současné době k dispozici pouze pro Windows (díky David Mason za navrhovanou úpravu!).

[Listopad 2016] Odstranil zmínku o tom, že dokumenty s automatickým ukončením platnosti jsou funkcí, která je exkluzivní pro DocumentDB, protože Bo Bendtsen laskavě zdůraznil, že MongoDB má podobné schopnosti.

[Leden 2017] Přidána část o předinstalované bezpečnosti DocumentDB, která byla navržena Mary Branscombe.

Podobnosti

Koncepčně existují mezi těmito dvěma databázemi základní podobnosti:

  • Dokumenty jsou ukládány a doručovány ve formátu JSON
  • Dokumenty lze získat pomocí bohatého jazyka dotazů, který dobře hraje syntaxi JSON

Funkce jedinečné pro MongoDB

Začněme vyjmenováním hlavních funkcí MongoDB, které neobsahují žádné (přiměřeně se shodující) protějšky DocumentDB.

Bohaté možnosti dotazů s agregačním potrubím

Agregační potrubí MongoDB je velmi výkonná funkce, která vám umožní vytvořit potrubí složené ze fází zpracování dat, z nichž každá filtruje a transformuje dokumenty pocházející ze kolekce. Možnosti, které tento plynovod nabízí, jsou téměř neomezené a jeho flexibilita může uspokojit prakticky jakýkoli druh dotazu.

Oproti tomu syntaxe dotazu DocumentDB typu SQL umožňuje pouze jednoduché filtrování dokumentů, dokonce postrádá „základní“ konstrukty, jako je počet nebo součet (přestože na nich pracují a mezitím můžete pracovat se serverovým Javascriptem). Praktický dotaz podvádět list najdete zde.

Zmenšení mapy

Funkce MongoDB, která je nějak podobná agregačnímu potrubí, umožňuje mapování dokumentů ve sbírce procházet dvěma samostatnými fázemi, které iterativně transformuje (nebo projekty), a potom dokumenty seskupuje. Obě fáze jsou definovány v Javascriptu.

V DocumentDB takový koncept neexistuje, ačkoli podobných výsledků lze dosáhnout pomocí uložených procedur (viz níže).

Fulltextové indexy

Mezi různými typy indexů dostupných na MongoDB nabízí textový index možnosti fulltextového vyhledávání.

DocumentDB neposkytuje žádné fulltextové indexování. Doporučeným způsobem přidání fulltextového vyhledávání do databáze DocumentDB je spárování se službou Azure Search; mezi nimi existuje dobrý integrační příběh.

Další platformy podporované ovladači na straně klienta

Myslím, že je důležité zmínit, že ovladače MongoDB podporují velmi široké spektrum platforem, zatímco DocumentDB má pouze SDK pro .NET, Java, Python a Node.js - ale díky své podpoře můžete zkusit použít jakýkoli ovladač MongoDB s DocumentDB. pro protokol MongoDB.

Funkce jedinečné pro DocumentDB

Nyní provedeme inverzní cvičení a vyjmenujeme funkce DocumentDB, které v MongoDB nenajdete.

Javascript na straně serveru

To je klíčová vlastnost DocumentDB. Má bohaté Javascript API na straně serveru, což vám umožňuje vytvářet funkce zpracování dat. Tyto funkce na straně serveru mohou mít 3 různé formy:

  • uložené procedury, které dokážou dělat téměř cokoli (vkládání, dotazování, aktualizace dokumentů) a volají se pomocí SDK nebo REST API
  • spouští (nebo háčky), které jsou spuštěny před nebo po konkrétních operacích (například při vkládání dokumentu)
  • UDF (uživatelem definované funkce), které lze vyvolat a rozšířit jazyk dotazů SQL, nějakým způsobem zmenšuje mezeru s bohatými schopnostmi dotazů MongoDB

Nyní může MongoDB také spustit JavaScript na straně serveru, ale chápu to takto:

  • Map-redukovat a $ kde operátor dotazu lze použít pouze pro dotazy, ne pro aktualizace
  • Funkce Javascript, které můžete uložit do speciální kolekce systémů, jsou vhodné pouze pro účely správy nebo údržby.

Dokumentace MongoDB jasně uvádí, že při provádění Javascriptu na straně serveru existují omezení výkonu; ve srovnání je DocumentDB skutečně navržen pro tento účel, protože předkompiluje váš kód Javascript, poté uloží a provede výsledný bytecode.

Transakce

Díky procedurám uloženým v Javascriptu, které jsme právě zmínili, je možné provádět ACID transakce v kolekci DocumentDB. Způsob, jakým to funguje, je opravdu jednoduchý: pokud je vaše funkce Javascriptu dokončena, všechny operace zápisu, které provedl, budou potvrzeny; pokud funkce vyvolá jakoukoli výjimku, všechny operace se vrátí zpět.

Ve skutečnosti neexistuje žádný koncept transakce v MongoDB kromě atomicity jednoho dokumentu, což znamená, že vložení nebo aktualizace dokumentu je zaručeno, že je atomová, ale operace zápisu zahrnující více dokumentů není atomová jako celek.

Ve výchozím nastavení je úplné indexování

DocumentDB přistupuje k indexování poměrně drasticky: ve výchozím nastavení indexuje všechna pole dokumentů, které ukládáte! Mnozí z vás to mohou vidět jako ztrátu času na zpracování a úložný prostor - což je do určité míry upřímné - to však přináší zajímavou výhodu, protože nabízí vynikající výkon dotazů po vybalení z krabice. Pro ty, kteří dávají přednost lepší kontrole toho, co bude indexováno, je vždy možné definovat vlastní zásady indexování.

(Snadná) globální distribuce

Dalším docela novým přírůstkem schopností DocumentDB je globální distribuce. Tato funkce v zásadě umožňuje škálovat instanci DocumentDB napříč různými regiony po celém světě a definovat, jaký typ konzistence očekáváte mezi regiony, od silné po eventuální. Je dokonce možné nakonfigurovat automatické a transparentní převzetí služeb při selhání v různých regionech.

Samozřejmě je možné nasazení celosvětového klastru uzlů MongoDB, ale zde bych chtěl zdůraznit, jak snadné je nastavení takového klastru. To je zjevně mimo hlavní funkce DocumentDB a souvisí s její povahou PaaS, ale nemyslím si, že existuje jakýkoli poskytovatel služeb nabízející takové geo-distribuované nastavení pro MongoDB (za cenu a snadné použití).

Bezpečnostní

Za zmínku stojí, že DocumentDB jako služba poskytuje vestavěné zabezpečení a řízení přístupu, které je ve výchozím nastavení ... Bez administrátorského přístupu bez hesla! Kromě toho také umožňuje kontrolovat přístup ke sbírkám a dokumentům jemným způsobem tím, že vytváří uživatele a propojuje je s těmito prostředky pomocí oprávnění chráněných heslem.

Ceny

Posledním, ale v neposlední řadě kritériem pro srovnání je cena. Měli bychom však dávat pozor, abychom zde nesrovnávali jablka a pomeranče: DocumentDB patří do rodiny PaaS, zatímco MongoDB je databáze, ne služba. Vezměme tedy mLab, nabídku MongoDB PaaS, pro srovnání.

Nejprve bych měl objasnit, jak se účtuje DocumentDB. Každá kolekce je fakturována ve 2 rozměrech:

  • použité úložiště, 0,25 USD za GB / měsíc
  • vyhrazené jednotky žádostí za sekundu, ~ 6 USD za 100 RU / měsíc

Počet RU, které si rezervujete, určuje garantovanou šířku pásma, kterou získáte (chcete se dozvědět více o jednotkách požadavku? Podívejte se na můj příspěvek!). RU v zásadě představuje „zpracování požadované pro čtení jednoho dokumentu 1 kB s 10 vlastnostmi“. Jak již bylo řečeno, není snadné vyhodnotit skutečné náklady na složité operace, jako jsou velké dotazy nebo komplikovaná uložená procedura, ačkoli tento průvodce hodně pomáhá. Můžeme však udělat opačné cvičení, když se podíváme na to, kolik RU bychom mohli získat za cenu plánu mLab.

Co jsem dosud nezmínil, je to, že DocumentDB běží na lokálním SSD, takže abychom mohli spravedlivě porovnat, vezměme z této stránky plán „High Performance M3“, který je v době tohoto psaní (září 2016) cena za 1 300 USD měsíčně za 80 GB úložného prostoru.

  • Těmto 80 GB by bylo účtováno 20 USD na DocumentDB
  • Zůstává 1 370 USD, tedy více než 22 800 RU

Už jsem zmínil, že je obtížné hodnotit „hodnotu“ železničního podniku, ale z mé zkušenosti je 22 800 hodně, něco v rozsahu 200 komplexních dotazů za sekundu. A i když je podobně obtížné hodnotit schopnosti tohoto plánu „High Performance M3“, řekl bych, že hrajeme v podobném měřítku, nebo alespoň ne o řády jiné velikosti.

Kromě toho, co je příjemné s pružností RU, je to, že je navrženo jako jednotka měřítka, což znamená, že můžete začít s malým množstvím RU a (hladce) škálovat to s rostoucím využíváním vašich sbírek, zatímco stále využívat místní výkon SSD od začátku.

A co náklady na uzamčení dodavatele?

Mnoho lidí se obává, že je dodavatel zablokován: pokud používám DocumentDB, nejsem uzamčen pouze u Microsoftu, ale také u Azure jako platformy. Dalo by se dokonce tvrdit, že nedostatek takového blokování měl být uveden ve výhodách MongoDB oproti DocumentDB. Souhlasím. Jaká je skutečná cena tohoto uzamčení?

DocumentDB ukládá dokumenty ve formátu JSON. Jedná se o standardní formát používaný většinou databází NoSQL (hej, dokonce i SQL Server hovoří JSON!), Takže přesunutí dokumentů z DocumentDB a jejich vložení do jiné databáze by nemělo být problém.

Hlavní technické uzamčení, které musíte řešit, je rozhraní dotazů: každá databáze má svůj vlastní způsob dotazování dokumentů. Většinu času tyto dotazy provádíte pomocí některé sady SDK nebo ovladače, takže z pohledu kódu aplikace přichází blokování nebo dodržování určité databáze hlavně z rozhraní dané sady SDK. Ale pokud to vaši vývojáři dělají správně, mělo by být toto rozhraní zapouzdřeno za nějakým druhem rozhraní pro přístup k datům, které skryje podrobnosti implementace pro zbytek aplikace.

A pokud máte obavy, že budete možná chtít migrovat do MongoDB v pozdější fázi, pamatujte, že DocumentDB má kompatibilitu s protokolem s MongoDB, což znamená, že můžete použít jakýkoli ovladač MongoDB pro přístup k DocumentDB a provádět většinu operací CRUD.

Jak mohu doporučit vaše rozhodnutí

Zabalení, zde jsou první otázky, o kterých si myslím, že byste si mohli položit otázku, kdy si musíte vybrat mezi těmito databázemi (v žádném konkrétním pořadí):

  • Složitost dotazů: vyžadují vaše dotazy plný výkon agregačního potrubí MongoDB, nebo je můžete implementovat pomocí SQL DocumentDB a nějakého Javascriptu na straně serveru?
  • Transakce: Vyžaduje vaše obchodní logika transakce v celé kolekci, více dokumentů, nebo je atomicita jednoho dokumentu MongoDB dostačující pro vaše požadavky?

Na základě vašich odpovědí a obecného směřování pak můžete upřesnit svou analýzu a zvážit zbývající funkce, které jsem zmínil (fulltextové vyhledávání, globální distribuce atd.)

Prosím komentář!

Snažil jsem se provést toto srovnání čestným a nezaujatým způsobem, ale v některých aspektech jsem se mohl mýlit. Neváhejte nás tedy oslovit, pokud máte pocit, že některé funkce chybí nebo byly nadhodnoceny nebo podceňovány! Mám v úmyslu tento příspěvek se postupem času vyvíjet a doplňovat, aby se stal dobrým referenčním bodem pro srovnání mezi DocumentDB a MongoDB.

Děkuji za přečtení!