Cassandra vs. MongoDB
Zvažujete Cassandru nebo MongoDB jako úložiště dat pro váš další projekt? Chcete obě databáze porovnat? Cassandra a MongoDB jsou databáze „NoSQL“, ale realita je taková, že se velmi liší. Mají velmi odlišné silné stránky a hodnotové nabídky – takže každé srovnání musí být jemné. Začněme počátečními požadavky... Žádná z těchto databází nenahrazuje RDBMS, ani se nejedná o „ACID“ databáze. Pokud tedy máte transakční zátěž, kde jsou primárními požadavky normalizace a konzistence, žádná z těchto databází vám nebude fungovat. Je lepší zůstat u tradičních relačních databází, jako je MySQL, PostgreSQL, Oracle atd. Nyní, když máme relační databáze z cesty, podívejme se na hlavní rozdíly mezi Cassandrou a MongoDB, které vám pomohou při rozhodování. V tomto příspěvku nebudu diskutovat o konkrétních funkcích, ale poukážu na některé strategické rozdíly na vysoké úrovni, které vám pomohou při výběru.
1. Expresivní objektový model
MongoDB podporuje bohatý a expresivní objektový model. Objekty mohou mít vlastnosti a objekty lze do sebe vnořovat (pro více úrovní). Tento model je velmi „objektově orientovaný“ a může snadno reprezentovat jakoukoli objektovou strukturu ve vaší doméně. Můžete také indexovat vlastnosti libovolného objektu na jakékoli úrovni hierarchie – to je překvapivě mocné! Cassandra na druhou stranu nabízí poměrně tradiční strukturu tabulky s řádky a sloupci. Data jsou strukturovanější a každý sloupec má specifický typ, který lze specifikovat při vytváření.
Verdikt:Pokud vaše problémová doména potřebuje bohatý datový model, pak je pro vás hosting MongoDB vhodnější.
2. Sekundární indexy
Sekundární indexy jsou prvotřídní konstrukcí v MongoDB. To usnadňuje indexování jakékoli vlastnosti objektu uloženého v MongoDB, i když je vnořený. Díky tomu je opravdu snadné dotazovat se na základě těchto sekundárních indexů. Cassandra má pouze zběžnou podporu pro sekundární indexy. Sekundární indexy jsou také omezeny na jednotlivé sloupce a porovnání rovnosti. Pokud se většinou budete dotazovat pomocí primárního klíče, Cassandra pro vás bude dobře fungovat.
Verdikt: Pokud vaše aplikace potřebuje sekundární indexy a potřebuje flexibilitu v modelu dotazu, pak je pro vás MongoDB vhodnější.
3. Vysoká dostupnost
MongoDB podporuje model „single master“. To znamená, že máte hlavní uzel a několik podřízených uzlů. V případě, že pán sestoupí, jeden z otroků je zvolen jako pán. Tento proces probíhá automaticky, ale trvá to dlouho, obvykle 10-40 sekund. Během této doby volby nového vůdce je vaše sada replik mimo provoz a nelze zapisovat. To funguje pro většinu aplikací, ale nakonec záleží na vašich potřebách. Cassandra podporuje model „multiple master“. Ztráta jednoho uzlu neovlivní schopnost clusteru zapisovat – můžete tedy dosáhnout 100% dostupnosti pro zápisy.
Verdikt:Pokud potřebujete 100% dostupnost, Cassandra je pro vás lepší volbou.
4. Write Scalability
MongoDB se svým „single master“ modelem může zapisovat pouze na primární. Sekundární servery lze použít pouze pro čtení. Takže v podstatě, pokud máte sadu replik tří uzlů, pouze master provádí zápisy a další dva uzly se používají pouze pro čtení. To značně omezuje škálovatelnost zápisu. Můžete nasadit více fragmentů, ale v podstatě pouze 1/3 vašich datových uzlů může provádět zápisy. Cassandra s modelem „multiple master“ může zapisovat na jakýkoli server. Škálovatelnost zápisu je v podstatě omezena počtem serverů, které máte v clusteru. Čím více serverů v clusteru máte, tím lépe se bude škálovat.
Verdikt:Pokud vám záleží na škálovatelnosti zápisu, Cassandra je pro vás lepší volbou.
5. Podpora dotazovacího jazyka
Cassandra podporuje dotazovací jazyk CQL, který je velmi podobný SQL. Pokud již máte tým datových analytiků, budou schopni přenést většinu svých dovedností SQL, což je pro velké organizace velmi důležité. CQL však není plnohodnotný ANSI SQL – má několik omezení (žádná podpora spojení, žádné klauzule OR) atd. MongoDB v tomto bodě nemá podporu pro dotazovací jazyk. Dotazy jsou strukturovány jako fragmenty JSON.
Verdikt:Pokud potřebujete podporu jazyka dotazů, Cassandra je pro vás tím nejvhodnějším řešením.
6. Srovnání výkonu
Pojďme mluvit o výkonu. V tuto chvíli pravděpodobně očekáváte srovnání výkonu databází. Záměrně jsem do srovnání nezahrnul výkonnostní benchmarky. Při jakémkoli srovnání se musíme ujistit, že provádíme srovnání jablek s jablky.
1. Databázový model - Databázový model/schéma testované aplikace je velký rozdíl. Některá schémata jsou vhodná pro MongoDB a některá jsou vhodná pro Cassandru. Takže při porovnávání databází je důležité použít model, který funguje přiměřeně dobře pro obě databáze.
2. Charakteristiky zatížení – Charakteristiky referenční zátěže jsou velmi důležité. Např. V benchmarcích náročných na zápis bych očekával, že Cassandra bude kouřit MongoDB. V benchmarcích náročných na čtení by však měly mít MongoDB a Cassandra podobný výkon.
3. Požadavky na konzistenci - Tohle je ošemetné. Musíte se ujistit, že specifikované požadavky na konzistenci čtení/zápisu jsou identické v obou databázích a nejsou zaujaté vůči jednomu účastníkovi. Velmi často v řadě „Marketingových“ benchmarků jsou knoflíky vyladěny tak, aby znevýhodňovaly druhou stranu. Věnujte tedy velkou pozornost nastavení konzistence.
Poslední věc, kterou je třeba mít na paměti, je, že zatížení benchmarku může, ale nemusí odrážet výkon vaší aplikace. Aby tedy byly benchmarky užitečné, je velmi důležité najít zatížení benchmarku, které odráží výkonnostní charakteristiky vaší aplikace. Zde jsou některé srovnávací hodnoty, na které byste se mohli chtít podívat:
- Srovnání výkonu NoSQL
- Cassandra vs. MongoDB vs. Couchbase vs. HBase
7. Snadné použití
Pokud byste tuto otázku položili před několika lety, MongoDB by byl konečným vítězem. Zprovoznit MongoDB a spustit jej je poměrně jednoduchý úkol. V posledních několika letech však Cassandra udělala v tomto aspektu produktu velký pokrok. S přijetím CQL jako primárního rozhraní pro Cassandru se to posunulo o krok dále – velmi zjednodušili zástupům SQL programátorů velmi snadno Cassandru používat.
Verdikt:Oba se poměrně snadno používají a rozšiřují.
8. Nativní agregace
MongoDB má vestavěný agregační rámec pro provozování ETL kanálu pro transformaci dat uložených v databázi. To je skvělé pro malé až střední úlohy, ale jak se vaše potřeby zpracování dat stávají složitějšími, agregační rámec se obtížně ladí. Cassandra nemá vestavěný agregační rámec. K tomu slouží externí nástroje jako Hadoop, Spark.
9. Modely bez schématu
V MongoDB se můžete rozhodnout, že nebudete u svých dokumentů vynucovat žádné schéma. I když to bylo výchozí v předchozích verzích, v novější verzi máte možnost pro své dokumenty vynutit schéma. Každý dokument v MongoDB může mít jinou strukturu a je na vaší aplikaci, jak data interpretuje. I když to není pro většinu aplikací relevantní, v některých případech je důležitá dodatečná flexibilita. Cassandra v novějších verzích (s CQL jako výchozím jazykem) poskytuje statické psaní. Musíte předem definovat typ samotného sloupce.
Pro shrnutí uvádíme důležité rozdíly ve formě tabulky: 
Pokud si chcete prohlédnout celou infografiku, můžete navštívit naši stránku srovnání Cassandra vs MongoDB.