Cassandra vs. MongoDB

Overvejer du Cassandra eller MongoDB som datalageret til dit næste projekt? Vil du sammenligne de to databaser? Cassandra og MongoDB er begge "NoSQL"-databaser, men virkeligheden er, at de er meget forskellige. De har meget forskellige styrker og værdiforslag - så enhver sammenligning skal være nuanceret. Lad os starte med indledende krav ... Ingen af disse databaser erstatter RDBMS, og de er heller ikke "ACID"-databaser. Så hvis du har en transaktionsmæssig arbejdsbyrde, hvor normalisering og konsistens er de primære krav, vil ingen af disse databaser fungere for dig. Du er bedre stillet til at holde fast i traditionelle relationsdatabaser som MySQL, PostgreSQL, Oracle osv. Nu hvor vi har relationelle databaser af vejen, lad os overveje de store forskelle mellem Cassandra og MongoDB, som vil hjælpe dig med at træffe beslutningen. I dette indlæg vil jeg ikke diskutere specifikke funktioner, men vil påpege nogle strategiske forskelle på højt niveau for at hjælpe dig med at træffe dit valg.

1. Ekspressiv objektmodel

MongoDB understøtter en rig og udtryksfuld objektmodel. Objekter kan have egenskaber, og objekter kan indlejres i hinanden (for flere niveauer). Denne model er meget "objektorienteret" og kan nemt repræsentere enhver objektstruktur i dit domæne. Du kan også indeksere egenskaben for ethvert objekt på et hvilket som helst niveau i hierarkiet – det er slående kraftfuldt! Cassandra tilbyder derimod en ret traditionel tabelstruktur med rækker og kolonner. Data er mere struktureret, og hver kolonne har en specifik type, som kan specificeres under oprettelsen.

Bedømmelse:Hvis dit problemdomæne har brug for en rig datamodel, så passer MongoDB-hosting bedre til dig.

2. Sekundære indekser

Sekundære indekser er en førsteklasses konstruktion i MongoDB. Dette gør det nemt at indeksere enhver egenskab for et objekt, der er gemt i MongoDB, selvom det er indlejret. Dette gør det virkelig nemt at forespørge baseret på disse sekundære indekser. Cassandra har kun overfladisk understøttelse af sekundære indekser. Sekundære indekser er også begrænset til enkelte kolonner og lighedssammenligninger. Hvis du for det meste skal forespørge med den primære nøgle, vil Cassandra fungere godt for dig.

Bedømmelse: Hvis din applikation har brug for sekundære indekser og har brug for fleksibilitet i forespørgselsmodellen, passer MongoDB bedre til dig.

3. Høj tilgængelighed

MongoDB understøtter en "single master"-model. Det betyder, at du har en masterknude og et antal slaveknudepunkter. I tilfælde af at mesteren går ned, vælges en af slaverne som herre. Denne proces sker automatisk, men det tager tid, normalt 10-40 sekunder. I denne tid med ny ledervalg er dit replikasæt nede og kan ikke tåle skrivninger. Dette virker til de fleste applikationer, men afhænger i sidste ende af dine behov. Cassandra understøtter en "multiple master"-model. Tabet af en enkelt node påvirker ikke klyngens evne til at tage skrivninger – så du kan opnå 100 % oppetid for skrivninger.

Bedømmelse:Hvis du har brug for 100 % oppetid, passer Cassandra bedre til dig.

4. Skriv skalerbarhed

MongoDB med sin "single master"-model kan kun tage skrivninger på den primære. De sekundære servere kan kun bruges til læsninger. Så i det væsentlige, hvis du har tre noder replikasæt, er det kun masteren, der tager skrivninger, og de to andre noder bruges kun til læsninger. Dette begrænser skriveskalerbarheden i høj grad. Du kan implementere flere shards, men i det væsentlige kan kun 1/3 af dine dataknuder tage skrivninger. Cassandra med sin "multiple master"-model kan tage skrivninger på enhver server. Grundlæggende er din skriveskalerbarhed begrænset af antallet af servere, du har i klyngen. Jo flere servere du har i klyngen, jo bedre skaleres den.

Bedømmelse:Hvis skriveskalerbarhed er din ting, passer Cassandra bedre til dig.

5. Sprogstøtte til forespørgsler

Cassandra understøtter CQL-forespørgselssproget, som minder meget om SQL. Hvis du allerede har et team af dataanalytikere, vil de være i stand til at overføre størstedelen af deres SQL-færdigheder, hvilket er meget vigtigt for store organisationer. CQL er dog ikke fuldt udbygget ANSI SQL – Det har flere begrænsninger (ingen join-understøttelse, ingen OR-klausuler) osv. MongoDB har på dette tidspunkt ingen understøttelse af et forespørgselssprog. Forespørgslerne er struktureret som JSON-fragmenter.

Bedømmelse:Hvis du har brug for støtte til forespørgselssprog, er Cassandra den bedst egnede for dig.

6. Ydeevnebenchmarks

Lad os tale præstation. På dette tidspunkt forventer du sandsynligvis en performance benchmark sammenligning af databaserne. Jeg har bevidst ikke inkluderet præstationsbenchmarks i sammenligningen. I enhver sammenligning skal vi sørge for, at vi foretager en æbler-til-æbler-sammenligning.

1. Databasemodel - Databasemodellen/skemaet for den applikation, der testes, gør en stor forskel. Nogle skemaer er velegnede til MongoDB og nogle er velegnede til Cassandra. Så når man sammenligner databaser, er det vigtigt at bruge en model, der fungerer rimeligt godt for begge databaser.
2. Belastningsegenskaber – Egenskaberne ved benchmark-belastningen er meget vigtige. For eksempel. I skrivetunge benchmarks ville jeg forvente, at Cassandra ryger MongoDB. Men i læsetunge benchmarks bør MongoDB og Cassandra være ens i ydeevne.
3. Konsistenskrav - Det her er en vanskelig en. Du skal sikre dig, at de specificerede læse/skrive-konsistenskrav er identiske i begge databaser og ikke er forudindtaget i forhold til én deltager. Meget ofte i en række af 'Marketing' benchmarks, er knapperne indstillet til at være til ulempe for den anden side. Så vær meget opmærksom på konsistensindstillingerne.

En sidste ting at huske på er, at benchmarkbelastningen muligvis afspejler din applikations ydeevne eller ikke. Så for at benchmarks kan være nyttige, er det meget vigtigt at finde en benchmark-belastning, der afspejler din applikations ydeevnekarakteristika. Her er nogle benchmarks, du måske vil se på:
- NoSQL Performance Benchmarks
- Cassandra vs. MongoDB vs. Couchbase vs. HBase

7. Brugervenlighed

Hvis du havde stillet dette spørgsmål for et par år siden, ville MongoDB være vinderen. Det er en ret simpel opgave at få MongoDB op at køre. I de sidste par år har Cassandra dog gjort store fremskridt i dette aspekt af produktet. Med vedtagelsen af CQL som den primære grænseflade for Cassandra, har det taget dette et skridt videre – de har gjort det meget nemt for legioner af SQL-programmører at bruge Cassandra meget nemt.

Bedømmelse:Begge er forholdsvis nemme at bruge og øger.

8. Native aggregation

MongoDB har en indbygget Aggregation-ramme til at køre en ETL-pipeline for at transformere de data, der er gemt i databasen. Dette er fantastisk til små til mellemstore job, men efterhånden som dine databehandlingsbehov bliver mere komplicerede, bliver aggregeringsrammen vanskelig at fejlfinde. Cassandra har ikke en indbygget aggregeringsramme. Eksterne værktøjer som Hadoop, Spark bruges til dette.

9. Modeller uden skema

I MongoDB kan du vælge ikke at håndhæve noget skema på dine dokumenter. Selvom dette var standard i tidligere versioner i den nyere version, har du mulighed for at håndhæve et skema for dine dokumenter. Hvert dokument i MongoDB kan have en anden struktur, og det er op til din applikation at fortolke dataene. Selvom dette ikke er relevant for de fleste applikationer, er den ekstra fleksibilitet i nogle tilfælde vigtig. Cassandra i de nyere versioner (med CQL som standardsprog) giver statisk skrivning. Du skal definere typen af meget kolonne på forhånd.

For at opsummere her er de vigtige forskelle i tabelform:
Hvis du ønsker at se den fulde infografik, kan du besøge vores Cassandra vs MongoDB sammenligningsside.