Cassandra mot MongoDB
Överväger du Cassandra eller MongoDB som datalager för ditt nästa projekt? Vill du jämföra de två databaserna? Cassandra och MongoDB är båda "NoSQL"-databaser, men verkligheten är att de är väldigt olika. De har väldigt olika styrkor och värdeförslag – så varje jämförelse måste vara nyanserad. Låt oss börja med initiala krav... Ingen av dessa databaser ersätter RDBMS, och de är inte heller "ACID"-databaser. Så om du har en transaktionsbelastning där normalisering och konsistens är de primära kraven, kommer ingen av dessa databaser att fungera för dig. Du är bättre att hålla fast vid traditionella relationsdatabaser som MySQL, PostgreSQL, Oracle, etc. Nu när vi har relationsdatabaser ur vägen, låt oss överväga de stora skillnaderna mellan Cassandra och MongoDB som hjälper dig att fatta beslutet. I det här inlägget kommer jag inte att diskutera specifika funktioner utan kommer att peka på några strategiska skillnader på hög nivå för att hjälpa dig göra ditt val.
1. Expressiv objektmodell
MongoDB stöder en rik och uttrycksfull objektmodell. Objekt kan ha egenskaper och objekt kan kapslas in i varandra (för flera nivåer). Denna modell är väldigt "objektorienterad" och kan enkelt representera vilken objektstruktur som helst i din domän. Du kan också indexera egenskapen för vilket objekt som helst på vilken nivå som helst i hierarkin – detta är slående kraftfullt! Cassandra, å andra sidan, erbjuder en ganska traditionell tabellstruktur med rader och kolumner. Data är mer strukturerad och varje kolumn har en specifik typ som kan specificeras under skapandet.
Bedömning:Om din problemdomän behöver en rik datamodell passar MongoDB-värd bättre för dig.
2. Sekundära index
Sekundära index är en förstklassig konstruktion i MongoDB. Detta gör det enkelt att indexera alla egenskaper för ett objekt som är lagrat i MongoDB även om det är kapslat. Detta gör det väldigt enkelt att fråga baserat på dessa sekundära index. Cassandra har endast översiktligt stöd för sekundära index. Sekundära index är också begränsade till enstaka kolumner och jämställdhetsjämförelser. Om du mestadels kommer att fråga med primärnyckeln kommer Cassandra att fungera bra för dig.
Bedömning: Om din applikation behöver sekundära index och behöver flexibilitet i frågemodellen passar MongoDB bättre för dig.
3. Hög tillgänglighet
MongoDB stöder en "single master"-modell. Det betyder att du har en masternod och ett antal slavnoder. Om befälhavaren går ner, väljs en av slavarna till herre. Denna process sker automatiskt men det tar tid, vanligtvis 10-40 sekunder. Under den här tiden av ny ledareval är din replikuppsättning nere och tål inte skrivningar. Detta fungerar för de flesta applikationer men beror i slutändan på dina behov. Cassandra stöder en "multiple master"-modell. Förlusten av en enskild nod påverkar inte klustrets förmåga att ta skrivningar – så du kan uppnå 100 % drifttid för skrivningar.
Bedömning:Om du behöver 100 % drifttid passar Cassandra bättre för dig.
4. Skriv skalbarhet
MongoDB med sin "single master"-modell kan bara ta skrivningar på den primära. De sekundära servrarna kan endast användas för läsningar. Så i huvudsak om du har tre noder repliker är det bara mastern som tar skrivningar och de andra två noderna används bara för läsningar. Detta begränsar kraftigt skrivskalbarheten. Du kan distribuera flera skärvor men i princip bara 1/3 av dina datanoder kan ta skrivningar. Cassandra med sin "multiple master"-modell kan ta skrivningar på vilken server som helst. Din skrivskalbarhet är i huvudsak begränsad av antalet servrar du har i klustret. Ju fler servrar du har i klustret, desto bättre skalas det.
Bedömning:Om skrivskalbarhet är din grej, passar Cassandra bättre för dig.
5. Språkstöd för frågor
Cassandra stöder frågespråket CQL som är mycket likt SQL. Om du redan har ett team av dataanalytiker kommer de att kunna överföra en majoritet av sina SQL-kunskaper, vilket är mycket viktigt för stora organisationer. Men CQL är inte fullt utvecklad ANSI SQL – den har flera begränsningar (inget join-stöd, inga OR-klausuler) etc. MongoDB har för närvarande inget stöd för ett frågespråk. Frågorna är strukturerade som JSON-fragment.
Bedömning:Om du behöver stöd för frågespråk passar Cassandra bäst för dig.
6. Prestandabenchmarks
Låt oss prata prestation. Vid det här laget förväntar du dig förmodligen en jämförelse av databasernas prestandabenchmark. Jag har medvetet inte tagit med prestandabenchmarks i jämförelsen. I alla jämförelser måste vi se till att vi gör en jämförelse mellan äpplen och äpplen.
1. Databasmodell - Databasmodellen/schemat för applikationen som testas gör stor skillnad. Vissa scheman är väl lämpade för MongoDB och vissa är väl lämpade för Cassandra. Så när man jämför databaser är det viktigt att använda en modell som fungerar någorlunda bra för båda databaserna.
2. Belastningsegenskaper – Egenskaperna för benchmarkbelastningen är mycket viktiga. T.ex. I skrivtunga riktmärken skulle jag förvänta mig att Cassandra skulle röka MongoDB. Men i lästunga benchmarks bör MongoDB och Cassandra vara lika i prestanda.
3. Konsekvenskrav – Det här är en knepig sådan. Du måste se till att de angivna läs/skrivkonsistenskraven är identiska i båda databaserna och inte är partiska mot en deltagare. Mycket ofta i ett antal av "Marketing"-riktmärkena är rattarna inställda för att missgynna den andra sidan. Så var noga med konsistensinställningarna.
En sista sak att tänka på är att referensbelastningen kanske eller kanske inte återspeglar prestandan för din applikation. Så för att benchmarks ska vara användbara är det mycket viktigt att hitta en benchmarkbelastning som återspeglar prestandaegenskaperna för din applikation. Här är några riktmärken du kanske vill titta på:
- NoSQL Performance Benchmarks
- Cassandra vs. MongoDB vs. Couchbase vs. HBase
7. Användarvänlighet
Om du hade ställt den här frågan för ett par år sedan skulle MongoDB vara den absoluta vinnaren. Det är en ganska enkel uppgift att få MongoDB igång. Under de senaste åren har dock Cassandra gjort stora framsteg i denna aspekt av produkten. Med antagandet av CQL som det primära gränssnittet för Cassandra, har det tagit detta ett steg längre – de har gjort det mycket enkelt för legioner av SQL-programmerare att använda Cassandra mycket enkelt.
Bedömning:Båda är ganska lätta att använda och ökar.
8. Native Aggregation
MongoDB har ett inbyggt Aggregation-ramverk för att köra en ETL-pipeline för att transformera data som lagras i databasen. Detta är bra för små till medelstora jobb, men eftersom dina databehandlingsbehov blir mer komplicerade blir aggregeringsramverket svårt att felsöka. Cassandra har inget inbyggt aggregeringsramverk. Externa verktyg som Hadoop, Spark används för detta.
9. Schemalösa modeller
I MongoDB kan du välja att inte genomdriva något schema på dina dokument. Även om detta var standard i tidigare versioner i den nyare versionen har du möjlighet att använda ett schema för dina dokument. Varje dokument i MongoDB kan ha olika struktur och det är upp till din applikation att tolka data. Även om detta inte är relevant för de flesta applikationer, är i vissa fall den extra flexibiliteten viktig. Cassandra i de nyare versionerna (med CQL som standardspråk) ger statisk typning. Du måste definiera typen av kolumn i förväg.
För att sammanfatta här är de viktiga skillnaderna i tabellform: 
Om du vill se hela infografiken kan du besöka vår jämförelsesida för Cassandra vs MongoDB.