Welche Backend-Datenbank ist für die IoT-Implementierung geeignet?

15

Ich muss den IoT-Service für meinen Kunden bereitstellen. MQTT-, Kafka- und Rest Services-Komponenten werden verwendet, um die Daten von den Geräten in die Datenbank aufzunehmen. Ich muss einige Analysen über die Daten im Backend durchführen. Die Datengröße würde 135 Bytes / Gerät und 6000 Geräte / Sekunde betragen. Ich habe die Architektur hier geteilt, um die Anforderungen und Komponenten zu verstehen.

Ich habe nach den Datenspeichern (MongoDB, Postgresql (TimescaleDB), Redis, Neo4j, Cassandra) gesucht und jeder Anbieter hat bewiesen, dass seine Datenbank für den IoT-Anwendungsfall geeignet ist. Ich habe mich verwirrt über die Verwendung der bewährten / zuverlässigsten / skalierbaren Datenbank für das IoT.

Welche Datenbank ist am besten geeignet, um so viele Daten aufzunehmen und die Analysen durchzuführen?

Gibt es einen bewährten Benchmark für die geeignete Datenbank für das IoT?

Bitte geben Sie Ihre Gedanken und Vorschläge.

sensors system-architecture data-transfer

— Mourish Khan
quelle

Ich habe ElasticSearch kürzlich für einen ähnlichen Anwendungsfall verwendet. Aber ich kann nicht sagen, warum es besser ist als andere, dieser Teil basiert größtenteils auf Meinungen. Ich habe Kafka buchstäblich benutzt, um Sensoren an DB anzuschließen. Es gibt nette Bibliotheken, die die Stream-Verarbeitung von Kafka mit Elasticsearch unterstützen

— atayenel

2

Der „IoT-Anwendungsfall“ ist viel zu umfassend, um Implementierungen einzustufen. Jeder hat seine Stärken und Schwächen.

— Gilles 'SO- hör auf böse zu sein'

1

Nicht mein Fachgebiet, aber ich würde mich wundern, wenn eine moderne Datenbank hier schlecht passen würde. Verwenden Sie das, was Sie kennen oder über die besten Werkzeuge verfügen.

— Sean Houlihane

4

Sie sind entweder auf NoSQL-Datenbanken beschränkt, da in einer SQL-Datenbank kein 6K-TPS direkt auf dem Server zulässig ist. Sie können auch keinen SaaS-Cloud-Dienst oder eine Plattform verwenden, die bereits auf solche Vorgänge spezialisiert ist - z. B. Telematikdaten über MQTT / Kafka empfangen. Teilen Sie es auf, speichern Sie es für diese 6000 Geräte und stellen Sie eine einfache REST-API für den Zugriff auf die Telemetriedaten bereit. Wie Flespi oder was auch immer.

— shal
quelle

verstanden und danke. Können Sie mir sagen, welche NoSQL-Datenbank für meinen Anwendungsfall am besten geeignet ist?

— Mourish Khan

Es hängt wirklich von Ihrer Erfahrung und Ihrer Laufzeitumgebung ab. Für AWS / GoogleCloud ist dies eine Option. Für die lokale Installation würde ich LevelDB oder einem seiner Konkurrenten empfehlen. Durchsuchen Sie einfach LevelDB auf Google und Sie werden eine vollständige Liste davon sehen. In jeder Variante müssen Sie eine Zwischen-API zwischen Webanwendung und Datenbank implementieren. Dies hängt auch davon ab, welche Art von Back-End Sie für diese verwenden. Genau Ihr in diesem Artikel beschriebener Fall , wenn Sie Daten mit mqtt füllen und über das Web auf mqtt und den Verlauf zugreifen.

— voraussichtlich 20.03.18 Uhr

1

Übrigens habe ich in den letzten 15 Jahren viele dieser NoSQL-Datenbanken ausprobiert. Begonnen von Berkeley DB in seinen frühen Jahren. Wenn Sie in Ihren Anwendungen die volle Leistung und Leistungsfähigkeit benötigen und versuchen, die maximalen IOPs und den Durchsatz der Datenbank auszulasten, sehe ich keine andere Möglichkeit, als eine eigene Datenbank-Engine zu entwickeln, die speziell auf den Anwendungsfall und die Anforderungen der Telematik (IoT) zugeschnitten ist. Aber es war meine Erfahrung +)

— soll

"6K TPS" ?? 6 tB / Sekunde?

— Laut Mawg soll Monica

6.000 Transaktionen / Sekunde

— 30.

3

IoT sind so ziemlich Zeitreihendaten. Es gibt einige TSDBs: InfluxDB, OpenTSDB, GridDB usw. Sie haben alle die Community- / OSS-Version, damit Sie sehen können, ob sie Ihren Anforderungen entspricht. InfluxDB ist sehr beliebt. Beachten Sie jedoch, dass Clustering nur für kostenpflichtige Versionen verfügbar ist. OpenTSD ist pure oss und laut GridDB ist es IoT-orientiert und schneller als InfluxDB. Abhängig von Ihren Bedürfnissen möchten Sie vielleicht nach einem suchen, der schnell aufgenommen wird.

— Codelicious
quelle

2

Timescaledb, eine für Zeitreihen-Datasets angepasste Postgres-Erweiterung, funktioniert sehr gut. Sie erhalten die üblichen relationalen Datenbankfunktionen, SQL-Verwendung, Zuverlässigkeit, Indizes und Skalierbarkeit.

— IOTdev
quelle

0

Zusätzlich zu den vorherigen Antworten empfehle ich, sich Tarantool , ClickHouse und ScyllaDB anzuschauen . Diese Lösungen sind für die meisten Fälle mehr als ausreichend.

Abgesehen davon, dass in einigen Situationen, insbesondere zum Einbetten, die MDBX (oder ähnliches) nützlich sein kann.

— Leo Yuriev
quelle

2

Möchten Sie erläutern, warum Sie diese empfehlen?

— Helmar

0

Die Frage ist weit gefasst und es kann keine genaue Antwort gegeben werden, aber diese Links können helfen:

http://outlyer.com/blog/top10-open-source-time-series-databases/

Follow-up mit Benchmarks: http://outlyer.com/blog/time-series-database-benchmarks/

Anderer Vergleich: https://gist.github.com/sacreman/00a85cf09251147175241d334aafa798

Ich habe einige Regeln festgelegt, um zu versuchen, den Umfang einzuschränken, da dieser Blog sonst niemals enden würde.

Es wurden nur freie und Open Source-Zeitreihendatenbanken und ihre Funktionen verglichen. Deshalb fragt jemand: "Haben Sie Kdb + und Informix ausprobiert?" Die Antwort lautet "Nein". Sie sind aber wahrscheinlich fantastisch.

Die Liste enthält nur Datenbanken, die sich entweder in ihrem Marketingmaterial als Zeitreihen klassifizieren oder in einem Blog von einem coolen Unternehmen als etwas beschrieben wurden, das sie für Zeitreihendaten verwenden.

Was getan wurde, ist das Lesen der offiziellen Dokumente, das Lesen von StackOverflow, das Durchsuchen von Github-Problemen und -Code und das gemeinsame Hacken der Informationen. In diesem Sinne können einige Fakten falsch sein.

Wenn jemand einen Sachverhalt entdeckt, lass es mich wissen und ich aktualisiere den Blog.

Das Benchmarking basiert auf Marketingansprüchen und Schätzungen. Warum? Denn Benchmarking ist ein beträchtlicher Arbeitsaufwand und fehleranfällig. Sie erhalten immer die Meldung, dass Sie diese spezielle undokumentierte Einstellung hätten ändern sollen. Die aufgeführten Zahlen sind für die meisten Datenbanken sehr günstig. Dies sind entweder die Zahlen, über die in der Vergangenheit gebloggt oder auf Twitter behauptet wurde. Wenn Sie der Meinung sind, dass Zahlen falsch sind, lassen Sie es mich wissen und ich werde sie aktualisieren.

— FarO
quelle