MongoDB vs. Cassandra – Welches ist am besten für Internet-of-Things-Daten [geschlossen]

tldr; Ich werde sagen, dass Cassandra wahrscheinlich die bessere Wahl für Sie ist.

möglicherweise viele Sensoren, einschließlich Kamera für Fotos oder Videos] - Wo der Datenfluss riesig ist.

Aufgrund ihrer protokollbasierten Natur ist das Verfolgen von Sensordaten ein guter Anwendungsfall für Cassandra. Die Fähigkeit, große Mengen an Schreibdurchsatz zu bewältigen, ist eine Stärke von Cassandra, und Sie können linear skalieren, indem Sie so viele Knoten wie nötig hinzufügen, um die Arbeitslast zu bewältigen. Sie werden auch feststellen, dass das Sharding von Replikaten über mehrere Knoten mit Cassandra (aufgrund der Implementierung virtueller Knoten) einfacher zu konfigurieren ist.

Der Client fragt, ob er eine Datenbank auswählen möchte, deren Programmiersprache T-SQL ähnelt

Die Cassandra Query Language (CQL) ist SQL sehr ähnlich. Einige der Befehle sind genau gleich. Dies wurde absichtlich getan, um zu versuchen, die Lernkurve für Cassandra zu senken.

Allerdings ist dies auch ein zweischneidiges Schwert. Obwohl sie sich ähnlich anfühlen, sind CQL und SQL nicht dasselbe. Die Mehrheit meiner Mitarbeiter bei StackOverflow kommt von der Unterstützung von Entwicklern bei CQL-Abfragen, die sie mit einer SQL/relationalen Denkweise angegangen sind. Um es kurz zu machen, Sie können sich in Schwierigkeiten bringen, indem Sie SQL-basierte Annahmen über CQL machen, also müssen Sie und/oder Ihr Kunde damit vorsichtig sein.

MongoDB verwendet eine Javascript-basierte Abfragesprache. Obwohl es SQL nicht im Entferntesten ähnlich ist, kommen erfahrene Javascript-Hacker in der Regel gut damit zurecht.

Einige zusätzliche Warnhinweise zu Cassandra:

• Die gleiche protokollbasierte Natur, die Cassandra eine gute Leistung bei der Verarbeitung großer Mengen an Schreibdurchsatz ermöglicht, macht es auch problematisch, wenn es um das Löschen von Daten geht. Wenn Sie planen, Daten häufig zu löschen, ist Cassandra möglicherweise nicht die beste Lösung.
• Bei Cassandra ist das Datenmodell alles. Sie müssen einen tabellenbasierten Entwurfsansatz für die Modellierung wählen. Dies bedeutet, dass Sie möglicherweise eine Tabelle für jede Abfrage erstellen lassen, die durchgeführt werden könnte, und bedeutet normalerweise das Denormalisieren und/oder Duplizieren von Daten über einige Tabellen hinweg. MongoDB funktioniert genauso, aber meiner Erfahrung nach verzeiht Cassandra weniger, wenn Sie ein schlechtes Datenmodell haben.
• Sekundärindizes können manchmal bei der Abfrageflexibilität helfen. Aber sie haben den Ruf, ein Leistungskiller zu sein, also ist es am besten, sie mit Cassandra zu meiden. Wenn Sie ein entsprechendes Datenmodell erstellen, sollten Sie sie überhaupt nicht benötigen. Ich habe keine Erfahrung damit, sie in großem Umfang mit MongoDB zu verwenden, aber sie können eine bessere Leistung erbringen.

Zusammenfassend klingt Cassandra besser für Sie geeignet (vorausgesetzt, Sie erstellen ein gutes Datenmodell und löschen nicht oft), da es diese Kriterien erfüllt:

• Fähigkeit, mit großen Datenmengen umzugehen.
• Viele bestehende Cassandra-Anwendungsfälle für sensorbasierte Daten.
• CQL sollte als "SQL-vertraute" Abfragesprache durchgehen.

Zunächst einmal: Wenn Ihr Kunde Sie etwas fragt, das Sie aufgrund Ihrer eigenen Kenntnisse und Erfahrungen nicht gründlich beantworten können, ist es meiner Meinung nach eine sehr schlechte Geschäftspraxis, Vorschläge zu machen.

Bemerkungen zu Cassandra vs/und MongoDB

Die Anforderungen sind auch etwas matschig, um es gelinde auszudrücken.

Wo der Datenfluss riesig ist

Bei richtiger Einrichtung können sowohl Cassandra als auch MongoDB riesige Datenmengen verarbeiten. Nochmal: wenn richtig eingestellt . Beide DBMS erfordern einiges an Wissen und Erfahrung, um die Last effizient zu handhaben. Da es scheint, dass beides weder auf Ihrer noch auf Kundenseite vorhanden ist, ist es kurz- bis mittelfristig unvermeidlich, jemanden einzustellen, der sowohl Wissen als auch Erfahrung hat. Solch eine weitreichende Technologieentscheidung sollte auf Fakten und Analysen basieren, nicht auf bloßen Annahmen oder oberflächlicher Dokumentation.

Außerdem bittet mein Kunde darum, DB zu wählen, dessen Programmiersprache T-SQL ähnelt

Natürlich ist er das, da der Kunde davon ausgeht , dass im Unternehmen vorhandenes Wissen wiederverwendet werden kann. Meistens ist dies eine fehlerhafte Schlussfolgerung, wie @Aaron eloquent beschrieben hat . Ich empfehle dringend, eine Entscheidung nicht nach Zugangssprache zu treffen, sondern nach Eignung für den beabsichtigten Zweck. Wie bereits erwähnt, muss diese Eignung durch die Analyse der Anwendungsfälle und anderer Anforderungen bestimmt werden.

Alternativen

Wenn auch nicht ausdrücklich erwähnt, handelt es sich vermutlich um Zeitreihendaten. Es könnte sich lohnen, einen Blick auf InfluxDB zu werfen , das Teil einer ganzen Sammlung von Software ist, die sich mit Zeitreihendaten befasst, von der Erfassung bis zur Metaanalyse.