MongoDB vs Cassandra: NoSQL-Datenbanken im Vergleich

MongoDB vs Cassandra: NoSQL-Datenbanken im Vergleich

  • Orchestrierung
6 Minuten Lesezeit Aktualisiert Mar 8, 2019

Auf einen Blick: Ein Vergleich von MongoDB und Cassandra hebt ihre unterschiedlichen Datenmanagement-Ansätze hervor. MongoDB verwendet JSON-Dokumente, während Cassandra eine spaltenorientierte Struktur verwendet, die sowohl auf Skalierbarkeit als auch auf Datenintegrität abzielt.

  • MongoDB unterstützt geografische Daten über GEOJson.
  • Cassandras flaches Schema erhöht die Rückholgeschwindigkeit.

Hier machen wir einen direkten Vergleich von MongoDB und Cassandra. Wir liefern Beispiele mit Befehlen und Code und nicht nur eine narrative Erklärung.

Zusammenfassend ist Cassandra die moderne Version der relationalen Datenbank, allerdings sind die Daten nach Spalten statt nach Zeilen gruppiert, um einen schnellen Abruf zu gewährleisten. MongoDB speichert Datensätze als Dokumente im JSON-Format. Es verfügt über eine JavaScript-Shell und eine reiche Funktionsmenge, was die Handhabung erleichtert. Beide Systeme sind darauf ausgelegt, enorm skalierbar zu sein.

Datenstruktur

Apache Cassandra ist eine spaltenorientierte Datenbank. MongoDB speichert Datensätze im JSON-Format. Die MongoDB-Shells unterstützen außerdem JavaScript, sodass Sie Abfragen sowie Datenkonvertierungen und -manipulationen schrittweise erstellen können, wobei jede Operation in einer JavaScript-Variable gespeichert wird.

Ein JSON-Datendatensatz ist selbstbeschreibend, weil der Feldname und der Datenwert am selben Ort gespeichert sind, also innerhalb des Dokuments. Während ein Schema mit MongoDB nicht erforderlich ist, da JSON per Definition keines benötigt, kann man eines erstellen:

    var schema = new mongoose.Schema({
cachedContents : {
largest : String,
non_null : Number,
null : Number,
top : [{
item : String,
count : Number
}],
smallest : String,
format : {
displayStyle : String,
align : String
}
}
});

In dieser Einführung in Cassandra erklären wir, dass Cassandra-Tabellen ein Schema verwenden, ähnlich wie eine traditionelle relationale Datenbank. Aber es verzichtet auf den Begriff der Datenbanknormalisierung. Oracle-Administratoren würden sagen, dass das Cassandra-Schema flach ist. Der Grund dafür ist, dass Speicher über ein Netzwerk von Commodity-Servern günstig ist, sodass es keinen Grund gibt, Joins zum Datenabruf zu machen, was die Datenabrufe verlangsamt. Stattdessen ist Redundanz in Ordnung. Außerdem erfordern Cassandra-Tabellen nicht, dass jedes Feld gefüllt wird. Es gibt also keinen Aufwand für das Speichern leerer Daten.

Cassandra bietet außerdem JSON-Unterstützung an:

    use json;

CREATE type json.sale ( id int, item text, amount int );

CREATE TABLE json.customers ( id int  PRIMARY KEY, name text, balance int, sales list> );

INSERT INTO json.customers (id, name, balance, sales) 
VALUES (123, 'Greenville Hardware', 700,
 [{ id: 5544, item : 'tape', amount : 100},
  { id: 5545, item : 'wire', amount : 200}]) ;
select * from customers;

 id  | balance | name                | sales
-----+---------+---------------------+--------------------------------------------------------------------------------
 123 |     700 | Greenville Hardware | [{id: 5544, item: 'tape', amount: 100}, {id: 5545, item: 'wire', amount: 200}]

Daten hinzufügen

Cassandra:

MongoDB:

    CREATE TABLE Library.book (       
ISBN text, 
copy int, 
title text,  
PRIMARY KEY (ISBN, copy)
 );

INSERT INTO  Library.book (ISBN, copy, title) VALUES('1234',1, 'Bible');

MongoDB:

    db.collection.insertOne( { isbn: 100 } )
{
"acknowledged" : true,
"insertedId" : ObjectId("5c4493aa750820eae9756a15")
}

Index erstellen

Cassandra:

MongoDB:

    CREATE TABLE  Library.patron (      
ssn int PRIMARY KEY,  
checkedOut set 
);

INSERT INTO Library.patron (ssn, checkedOut) values (123,{'1234','5678'});

create index on Library.patron (checkedOut);

MongoDB:

    db.address.createIndex( { "location": "2dsphere"} )

Clusterbildung

Wir erklären, wie man einen Cassandra-Cluster und eine MongoDB-Cluster-Installation einrichtet.

MongoDB (mongod-Daemon) verwendet einen Mongo Master, Mongo Shard und Mongo Config-Server, um Daten zu replizieren. Der Abfrageserver, auch Router genannt (Mongo-Daemon), bestimmt, an welchen Server Anfragen und Datenoperationen gesendet werden, zum Beispiel das Hinzufügen eines Datensatzes.

Cassandra hat keinen Konfigurationsserver zur Steuerung des Betriebs anderer Server. Es gibt keine Master-Slave-Beziehung. Stattdessen gibt es einen Ring von Servern, die jeweils gleiche Funktionen erfüllen, jedoch unterschiedliche Teile (d. h. Shards) der Daten speichern.

Sharding

Sharding bedeutet, Daten über einen Cluster zu verteilen. Dies geschieht, indem ein Algorithmus auf einen Teil eines gesamten Dokuments oder Index angewendet wird. MongoDB und Cassandra bieten beide ein feines Maß an Kontrolle darüber.

Cassandra macht dies mit Cassandra-Partitionsschlüssel, Composite-Schlüssel und Clustering Columns und verwendet Tokens zur Verteilung von Cassandra-Daten. Kurz gesagt, jede Tabelle benötigt einen eindeutigen Primärschlüssel. Das erste aufgeführte Feld ist der Partitionsschlüssel, da sein gehashter Wert verwendet wird, um den Knoten zu bestimmen, an dem die Daten gespeichert werden. Wenn diese Felder in Klammern eingewickelt sind, ist der Partitionsschlüssel zusammengesetzt. Andernfalls ist das erste Feld der Partitionsschlüssel. Alle nach dem Primärschlüssel aufgeführten Felder werden als Cluster-Spalten bezeichnet. Diese speichern die Daten in aufsteigender oder absteigender Reihenfolge innerhalb der Partition, um ähnliche Werte schnell wiederzufinden. Alle Felder zusammen sind der Primärschlüssel.

Und hier wird MongoDB-Sharding erklärt. Im Grunde weist man verschiedene Datenteile verschiedenen Servern mit einem Index zu. Zum Beispiel könnten Datensätze mit den Indexkunden auf einem Serversatz und Anbieter auf dem anderen sein. Wenn man jedoch eine völlig zufällige Verteilung möchte, verwendet man einen gehashten Wert für den Index. Man kann auch Servern Daten mit einem Wertebereich zuweisen.

    sh.enableSharding("tobacco")
{ "ok" : 1 }

Datenkonsistenz durch Replikation

Replikation bedeutet, mehr als eine Kopie von Daten herzustellen, um Datenverluste durch Hardware- oder andere Ausfälle zu verhindern.

MongoDB verwendet ein Konzept namens ReplicaSets, konfiguriert mit rs.initiate:

    rs.initiate()
{
	"info2" : "no configuration specified. Using a default configuration for the set",


ConfigReplSet:SECONDARY> rs.status()
{
	"set" : "ConfigReplSet",

Wir erklären die Konfiguration der Apache Cassandra-Datenkonsistenz. Sie erstellen die Replikation folgendermaßen:

    CREATE KEYSPACE Library
      WITH REPLICATION = { 'class' : 'SimpleStrategy', 'replication_factor' : 3 };

Unterstützung für GEO-Operationen

MongoDB bietet eine überlegene Unterstützung für das Speichern und Abfragen geografischer Daten. Ein offensichtlicher Grund dafür ist das universelle Format dafür GEOJson. Schauen Sie sich Tweets nach geografischem Standort verfolgen und MongoDB nach GeoLocation abfragen.

Hier ist eine MongoDB-Abfrage, um Datensätze in der Nähe einer bestimmten Länge und Breite zu finden:

    db.address.find ({
  location: {
     $near: {
       $geometry: {
          type: "Point" ,
          coordinates: [ -72.7738706,41.6332836 ]
       },
       $maxDistance: 4,
       $minDistance: 0
     }
   }
})

Und da die Mongo-Shell Javascript unterstützt, kannst du Abfragen in Variablen speichern:

    var connecticut = db.address.find ({location:
     {$geoWithin:
       {$geometry: {
       type: "Polygon",
       coordinates:
 [[ [ -73.564453125, 41.178653972331674 ],
   [ -71.69128417968749, 41.178653972331674 ],
   [ -71.69128417968749, 42.114523952464246 ],
   [ -73.564453125, 42.114523952464246 ],
   [ -73.564453125, 41.178653972331674 ]
   ]]
}}}});

Stresstests

Wir sprechen über Speicherverwaltung und Leistungsoptimierung in Stresstests und Performance Tuning, Apache Cassandra und MongoDB Speichernutzung

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.

Mehr aus Orchestrierung

Interessieren Sie sich für mehr von BMC?

The Brief ist unsere monatliche E-Mail zum Mainframe und zur Enterprise-Orchestrierung: Recherchen, Kundenberichte, Produktnachrichten, Events.

Mit der Registrierung für dieses Angebot bestätigen Sie, dass Sie die Datenschutzrichtlinie von BMC gelesen und zugestimmt haben.

Sie haben The Brief abonniert

Das Briefing umfasst die Mainframe- und Enterprise-Orchestrierung – BMC AMI und Control-M – sowie die Analystenforschung, Kundeneinsätze und Events in beiden Bereichen.