it-swarm.com.de

Was ist die optimale Lösung zum Speichern von Echtzeit-Zeitreihen in MariaDB / MySQL?

Anwendungsfall: Eine Messung erzeugt eine bestimmte Anzahl von Bildern. Für jedes Bild müssen wir einen kleinen Satz von Qualitätsindikatoren (Floats, Doubles) zusammen mit einer Bild-Ganzzahl [1 ... N], einem Zeitstempel und einem oder zwei Fremdschlüsselwerten speichern. Dies sollte dann in einer Webanwendung (PHP) in "Echtzeit" aufgezeichnet werden, damit Benutzer es bewerten können.

Jeder Webclient fragt die Datenbank alle 5 Sekunden ab. Das Speichern und Abrufen jedes Satzes von Qualitätsindikatoren sollte idealerweise <2 Sekunden (ungefähr) dauern. Im schlimmsten Fall können ~ 30 Web-Clients gleichzeitig abgefragt werden, und es können ungefähr 10 Messungen gleichzeitig geschrieben werden, was zu Schreibbursts von ca. 1000 Sätze von Qualitätsindikatoren pro Sekunde.

In einer Programmiersprache würden diese Daten wahrscheinlich in Arrays oder Listen gespeichert. Da mir in der MariaDB/MySQL-Welt nichts Ähnliches bekannt ist, verwende ich nur eine reguläre InnoDB-Tabelle mit einer Spalte für jeden der oben genannten Werte. Dies hat bereits mehr als 90 Millionen Zeilen und wird voraussichtlich in den kommenden Monaten schneller wachsen.

Ist InnoDB insgesamt die beste Speicher-Engine dafür, oder sollte ich andere in Betracht ziehen? Ist es empfehlenswert, Daten nach einer Weile zu archivieren, möglicherweise nachdem alle Bilder der Messungen verarbeitet wurden? Würde es helfen, die Komprimierung zu aktivieren, oder hätte dies sehr negative Auswirkungen auf die Leistung?

4
dbdemon

Mit nur MySQL/MariaDB würde ich beschäftigen:

  • Hochgeschwindigkeitsaufnahme: http://mysql.rjweb.org/doc.php/staging_table
  • Übersichtstabellen (um das Abrufen der Daten zu beschleunigen): http://mysql.rjweb.org/doc.php/summarytables
  • Ich würde sogar in Betracht ziehen , die Rohdaten nicht zu speichern; Fassen Sie stattdessen die Daten zusammen und werfen Sie sie dann weg. Wenn dies praktisch ist, werden die meisten Fragen, die Sie stellen, vermieden.
  • (Wenn Daten gelöscht werden müssen): Schnelles Löschen alter Daten: http://mysql.rjweb.org/doc.php/partitionmaint
  • Ich würde FOREIGN KEYS Wegen des zusätzlichen Overheads vermeiden. (Stattdessen würde ich die SQL debuggen.)
  • Ich würde keine UUID-Schlüssel verwenden; Leistung degeneriert schrecklich in riesigen Tischen. ( http://mysql.rjweb.org/doc.php/uuid )
  • Ich würde zusätzliche Indizes vermeiden - Verwenden Sie nicht AUTO_INCREMENT, Wenn eine andere Spalte eindeutig ist.
  • Sie erwähnen Spatial - Bitte erläutern Sie. 2D-Lookups sind schwierig; SPATIAL ist ein Ansatz; Hier ist eine andere: http://mysql.rjweb.org/doc.php/latlng

Ihr letzter Absatz wirft Fragen in die Küche (Toku, MyRocks, Archiv, Komprimierung, Verlaufstabelle). Ich bin überrascht, dass das Posting nicht getötet wurde, weil es "zu breit" ist. Bitte erläutern Sie, wie Ihre Daten und Anfragen aussehen. Ansonsten können wir nur ein Spülbecken voller Lösungen werfen.

Sie sagen "Echtzeit", benötigen aber "Tausende/Sek.". Können Sie eine Verzögerung von 1 Minute in Echtzeit zulassen? 1 Sek? Sie können nicht 1ms bekommen; 1s wird schwer zu erreichen sein. Wie lange dauert ein Ausbruch? Was ist ein Burst pro Minute? 1K/Sek. Wird wahrscheinlich in den nächsten Sekunden verschüttet. 6K/Minute ist nicht viel Ärger.

Wie viele Clients speichern Daten? Einige Lösungen funktionieren gut mit einem einzelnen Client. Für mehrere Clients werden unterschiedliche Lösungen benötigt.

Denken Sie daran, dass Benchmarks so abgestimmt sind, dass sie eines zeigen und selten mit dem wirklichen Leben übereinstimmen.

6
Rick James

Es gibt dort einige große Fragen, die wahrscheinlich näher untersucht werden müssen, als hier erreicht werden können, da es so viele Abhängigkeiten gibt (stellen Sie fest, dass Sie das wissen!). Es gibt eine Reihe von Foliensätzen aus Präsentationen auf den Seiten Percona Live und Percona Live Europe zu Zeitreihen, die Ihnen dabei helfen können, den Weg weiter zu finden. Zum Beispiel über die Verwendung von ClickHouse von Yandex

https://www.percona.com/live/17/program/schedule/time-series

https://www.percona.com/live/e17/program-open-source-databases

Vielleicht finden Sie auch einige der Blog-Beiträge interessant. Dieser betrachtet TokuDB im Vergleich zu InnoDB als Zeitreihen-Benchmark.

https://www.percona.com/blog/2013/09/05/tokudb-vs-innodb-timeseries-insert-benchmark/

In diesem Fall geht es um MongoDB und TokuMX https://www.percona.com/blog/2015/05/26/storing-time-series-data-with-mongodb-and-tokumx/

Hoffe diese Hilfe.

3