Die beste Art, Sensordaten für schnelle Lesevorgänge zu speichern

Question

Ich sehe mir ein Projekt an, bei dem ich hunderte Messwerte pro Tag von einem Sensor speichern müsste (1/min). Der Wert, den ich in die Datenbank eingeben möchte, enthält einige Ganzzahlen, eine Sensor-Seriennummer, einen Zeitstempel und eine UID. Das Problem ist, dass ich diese auch schnell lesen kann.

Ich muss in der Lage sein, die letzten n Messwerte (die letzten 500 oder 1000 Messwerte) grafisch darzustellen und nach Sensorseriennummer zu sortieren. Wenn ich 1000 Sensoren habe, die jede Minute Daten senden, dann sind das 1,44 Millionen Datensätze pro Tag, und in ein paar Jahren werden Milliarden von Datensätzen entstehen.

Was ist der beste Weg, um diese Daten zu speichern, so dass ich schnell auf die Daten zugreifen kann, aber immer noch große Mengen davon speichern?

Wenn meine Ingenieure das vergangene Jahr von Daten von einem Sensor oder von ein paar Sensoren sehen wollen, sind das 525.600 Datenzeilen. Wie schnell würde ich das verarbeiten können? Millisekunden? Std? Tage?

Der Grund, warum ich die Daten aufbewahren muss, ist, dass ich in der Lage sein muss, Gleichungen zu verwenden, um zukünftige Sensordaten vorherzusagen. Mach vielleicht auch Maschinen lernen. Wäre es von Vorteil, diese Daten nach ein oder zwei Jahren offline zu speichern, um Speicherplatz zu sparen, oder spielt dies für k/v-Datenbanken keine Rolle?

Zuerst dachte ich RDB, aber da wir den Wachstumsfaktor wollen, scheint die k/v/noSQL-Datenbank der Weg zu sein. Ich plante, amazon DynamoDB zu hosten und eine Webapp, um die Daten zu sehen.

Was ist eine große Datenbank? Tausende von Reihen, Millionen, Milliarden? Wo ist der Punkt, wo es zu groß wird, um damit umzugehen?

Ich weiß, dass es viele vage Fragen gibt. Jede Antwort und jeder Ratschlag wäre willkommen.

Answer 1

Wir hatten ein ähnliches Szenario, aber die Datenerfassung war 10 Mal pro Sekunde mal Tausende von Geräten. Wir haben uns für MongoDB entschieden, aber wir wollten auch RavenDB in Erwägung ziehen, haben aber noch keine Tests durchgeführt.

Answer 2

Es scheint, als ob Sie mehrere Lösungen gleichzeitig in Betracht ziehen sollten. Wenn ich es richtig verstehe, möchten Sie in der Lage sein, die neuesten n Einträge regelmäßig abzurufen, aber gelegentlich möchten Sie Analysen in großem Umfang durchführen. Warum speichern Sie zum Beispiel die letzten N Tage Ihrer Daten in DynamoDB für schnelle Abfragen und können alle älteren Daten in einem günstigeren Geschäft wie Redshift oder sogar S3 verschieben? Anschließend können Sie diese Daten bei Bedarf mit Lösungen wie Redshift Spectrum, Athena, Quicksight, EMR usw. analysieren. Lassen Sie mich wissen, wenn Sie weitere Details zu diesem Ansatz wünschen.

Answer 3

Um Ihre letzte Frage zuerst zu beantworten. Die Art, wie ich Big Data definiere, ist alles, was nicht auf einen einzelnen Server passt.

In Bezug auf die Architektur sollten Sie transiente Speicher in einer verteilten Warteschlange, z. Kafka, wo Sie Daten für Monate oder Jahre aufbewahren können. Auf diese Weise können Sie große Datenmengen, Ausfallsicherheit und Gegendruck für die nachgelagerte Verarbeitung verarbeiten. Sie können Daten auch für Was-wäre-wenn-Szenarien und Modellierungen usw. wiedergeben. In Kafka können Sie eine Streaming-Engine wie Spark/Flink/Kafka Streaming verwenden, um Ihre Daten zu transformieren und in eine Serving-Schicht zu laden. Redshift für BI oder eine NoSQL-Datenbank für Schlüsselsuchen. Vom vorübergehenden Speicher können Sie Ihre Daten temporär in einen dauerhaften Speicher laden, z. S3 oder HDFS oder sogar ein traditionelles RDBMS. Ich habe eine architecture diagram dafür in meinem Blog-Post.