Cassandra versus MongoDB

Overweegt u Cassandra of MongoDB als de datastore voor uw volgende project? Wilt u de twee databases vergelijken? Cassandra en MongoDB zijn beide 'NoSQL'-databases, maar de realiteit is dat ze heel verschillend zijn. Ze hebben heel verschillende sterke punten en waardeproposities - dus elke vergelijking moet genuanceerd zijn. Laten we beginnen met de eerste vereisten ... Geen van deze databases vervangt RDBMS, en het zijn ook geen "ACID" -databases. Dus als u een transactiebelasting heeft waarbij normalisatie en consistentie de primaire vereisten zijn, zal geen van deze databases voor u werken. U kunt beter vasthouden aan traditionele relationele databases zoals MySQL, PostgreSQL, Oracle, enz. Nu we relationele databases uit de weg hebben, laten we eens kijken naar de belangrijkste verschillen tussen Cassandra en MongoDB die u zullen helpen de beslissing te nemen. In dit bericht ga ik geen specifieke functies bespreken, maar ik zal u wijzen op enkele strategische verschillen op hoog niveau om u te helpen bij het maken van uw keuze.

1. Expressief objectmodel

MongoDB ondersteunt een rijk en expressief objectmodel. Objecten kunnen eigenschappen hebben en objecten kunnen in elkaar worden genest (voor meerdere niveaus). Dit model is zeer "objectgericht" en kan gemakkelijk elke objectstructuur in uw domein vertegenwoordigen. U kunt ook de eigenschap van elk object op elk niveau van de hiërarchie indexeren - dit is opvallend krachtig! Cassandra daarentegen biedt een vrij traditionele tabelstructuur met rijen en kolommen. Gegevens zijn meer gestructureerd en elke kolom heeft een specifiek type dat kan worden opgegeven tijdens het maken.

Voordeel:als uw probleemdomein een uitgebreid datamodel nodig heeft, dan past MongoDB-hosting beter bij u.

2. Secundaire indexen

Secundaire indexen zijn een eersteklas constructie in MongoDB. Dit maakt het gemakkelijk om elke eigenschap van een object dat is opgeslagen in MongoDB te indexeren, zelfs als het is genest. Dit maakt het heel eenvoudig om te zoeken op basis van deze secundaire indexen. Cassandra heeft slechts oppervlakkige ondersteuning voor secundaire indexen. Secundaire indexen zijn ook beperkt tot enkele kolommen en gelijkheidsvergelijkingen. Als je voornamelijk zoekt met de primaire sleutel, dan zal Cassandra goed voor je werken.

Voordeel:  Als uw app secundaire indexen nodig heeft en flexibiliteit in het querymodel nodig heeft, dan past MongoDB beter bij u.

3. Hoge beschikbaarheid

MongoDB ondersteunt een "single master" -model. Dit betekent dat je een master node en een aantal slave nodes hebt. Als de meester uitvalt, wordt een van de slaven als meester gekozen. Dit proces gebeurt automatisch, maar het kost tijd, meestal 10-40 seconden. Gedurende deze tijd van nieuwe leiderverkiezing is uw replicaset niet beschikbaar en kan deze niet worden geschreven. Dit werkt voor de meeste toepassingen, maar hangt uiteindelijk af van uw behoeften. Cassandra ondersteunt een "multiple master" -model. Het verlies van een enkel knooppunt heeft geen invloed op het vermogen van het cluster om schrijfbewerkingen uit te voeren, dus u kunt 100% uptime voor schrijfbewerkingen bereiken.

Voordeel:als je 100% uptime nodig hebt, past Cassandra beter bij je.

4. Schrijfschaalbaarheid

MongoDB met zijn "single master" -model kan alleen op de primaire schrijven. De secundaire servers kunnen alleen worden gebruikt voor leesbewerkingen. Dus als je een replicaset met drie knooppunten hebt, neemt alleen de master schrijfbewerkingen en worden de andere twee knooppunten alleen gebruikt voor leesbewerkingen. Dit beperkt de schrijfschaalbaarheid aanzienlijk. U kunt meerdere shards implementeren, maar in wezen kan slechts 1/3 van uw gegevensknooppunten schrijfbewerkingen uitvoeren. Cassandra met zijn "multiple master" -model kan op elke server schrijven. In wezen wordt uw schrijfschaalbaarheid beperkt door het aantal servers dat u in het cluster heeft. Hoe meer servers u in het cluster heeft, hoe beter het zal schalen.

Voordeel:als schrijfschaalbaarheid jouw ding is, past Cassandra beter bij jou.

5. Ondersteuning voor querytaal

Cassandra ondersteunt de CQL-querytaal die erg lijkt op SQL. Als je al een team van data-analisten hebt, kunnen ze het grootste deel van hun SQL-vaardigheden overdragen, wat erg belangrijk is voor grote organisaties. CQL is echter geen volwaardige ANSI SQL - het heeft verschillende beperkingen (geen ondersteuning voor joins, geen OR-clausules) enz. MongoDB heeft op dit moment geen ondersteuning voor een querytaal. De queries zijn gestructureerd als JSON-fragmenten.

Uitspraak:als je taalondersteuning nodig hebt, is Cassandra de beste keuze voor jou.

6. Prestatiebenchmarks

Laten we het hebben over prestaties. Op dit moment verwacht u waarschijnlijk een prestatiebenchmarkvergelijking van de databases. Ik heb bewust geen prestatiebenchmarks in de vergelijking opgenomen. Bij elke vergelijking moeten we ervoor zorgen dat we een appel-met-appelvergelijking maken.

1.  Databasemodel  - Het databasemodel/schema van de te testen applicatie maakt een groot verschil. Sommige schema's zijn goed geschikt voor MongoDB en sommige zijn goed geschikt voor Cassandra. Dus bij het vergelijken van databases is het belangrijk om een ​​model te gebruiken dat redelijk goed werkt voor beide databases.
2.  Laadkenmerken – De kenmerken van de benchmarkbelasting zijn erg belangrijk. bijv. In schrijfzware benchmarks zou ik verwachten dat Cassandra MongoDB rookt. In leeszware benchmarks zouden MongoDB en Cassandra echter vergelijkbaar moeten zijn in prestaties.
3. Consistentievereisten - Dit is een lastige. U moet ervoor zorgen dat de gespecificeerde vereisten voor lees-/schrijfconsistentie identiek zijn in beide databases en niet bevooroordeeld zijn naar één deelnemer. Heel vaak worden in een aantal van de 'Marketing'-benchmarks de knoppen gestemd om de andere kant te benadelen. Let dus goed op de consistentie-instellingen.

Een laatste ding om in gedachten te houden is dat de benchmarkbelasting al dan niet de prestaties van uw toepassing weerspiegelt. Dus om benchmarks nuttig te laten zijn, is het erg belangrijk om een ​​benchmarkbelasting te vinden die de prestatiekenmerken van uw toepassing weerspiegelt. Hier zijn enkele benchmarks die u misschien wilt bekijken:
- NoSQL-prestatiebenchmarks
- Cassandra vs. MongoDB vs. Couchbase vs. HBase

7. Gebruiksgemak

Als je deze vraag een paar jaar geleden had gesteld, zou MongoDB de absolute winnaar zijn. Het is een vrij eenvoudige taak om MongoDB aan de gang te krijgen. In de afgelopen jaren heeft Cassandra echter grote vooruitgang geboekt in dit aspect van het product. Met de goedkeuring van CQL als de primaire interface voor Cassandra, is dit een stap verder gegaan - ze hebben het voor legioenen SQL-programmeurs heel eenvoudig gemaakt om Cassandra heel gemakkelijk te gebruiken.

Voordeel:beide zijn vrij eenvoudig te gebruiken en op te voeren.

8. Native aggregatie

MongoDB heeft een ingebouwd aggregatieraamwerk om een ​​ETL-pijplijn uit te voeren om de gegevens die in de database zijn opgeslagen, te transformeren. Dit is geweldig voor kleine tot middelgrote taken, maar naarmate uw gegevensverwerkingsbehoeften ingewikkelder worden, wordt het aggregatieframework moeilijker te debuggen. Cassandra heeft geen ingebouwd aggregatieraamwerk. Hiervoor worden externe tools zoals Hadoop, Spark gebruikt.

9. Modellen zonder schema

In MongoDB kunt u ervoor kiezen om geen enkel schema op uw documenten af ​​te dwingen. Hoewel dit de standaardinstelling was in eerdere versies in de nieuwere versie, heeft u de mogelijkheid om een ​​schema voor uw documenten af ​​te dwingen. Elk document in MongoDB kan een andere structuur hebben en het is aan uw applicatie om de gegevens te interpreteren. Hoewel dit voor de meeste toepassingen niet relevant is, is in sommige gevallen de extra flexibiliteit belangrijk. Cassandra in de nieuwere versies (met CQL als de standaardtaal) biedt statisch typen. U moet vooraf het type kolom definiëren.

Om hier samen te vatten zijn de belangrijke verschillen in tabelvorm:
Als u de volledige infographic wilt bekijken, kunt u onze Cassandra vs MongoDB-vergelijkingspagina bezoeken.