Ich schreibe eine Anwendung, die große Mengen an elektrischen und Temperaturdaten speichern und analysieren muss.

Grundsätzlich muss ich große Mengen an stündlichen Stromverbrauchsmessungen für die letzten Jahre und für viele Jahre für Zehntausende von Standorten speichern und dann die Daten auf nicht sehr komplexe Weise analysieren.

Die Informationen, die ich (vorerst) speichern muss, sind Standort-ID, Zeitstempel (Datum und Uhrzeit), Temperatur und Stromverbrauch.

Bezüglich der Menge der Daten, die gespeichert werden müssen, handelt es sich um eine Annäherung, aber in diesem Sinne:
20 000+ Standorte, 720 Datensätze pro Monat (stündliche Messungen, ungefähr 720 Stunden pro Monat), 120 Monate (vor 10 Jahren) ) und viele Jahre in die Zukunft. Einfache Berechnungen ergeben folgende Ergebnisse:

20 000 Standorte x 720 Datensätze x 120 Monate (10 Jahre zurück) = 1 728 000 000 Datensätze .

Dies sind die bisherigen Datensätze. Neue Datensätze werden monatlich importiert. Das sind ungefähr 20.000 x 720 = 14.400.000 neue Datensätze pro Monat .

Auch die Gesamtstandorte werden stetig wachsen.

Für all diese Daten müssen die folgenden Vorgänge ausgeführt werden:

1. Abrufen der Daten für ein bestimmtes Datum UND einen bestimmten Zeitraum: Alle Datensätze für eine bestimmte Standort-ID zwischen dem 01.01.2013 und dem 01.01.2017 sowie zwischen 07:00 und 13:00 Uhr.
2. Einfache mathematische Operationen für einen bestimmten Datums- UND Zeitbereich, z. B. MIN-, MAX- und AVG-Temperatur und Stromverbrauch für eine bestimmte Standort-ID für 5 Jahre zwischen 07:00 und 13:00 Uhr.

Die Daten werden monatlich geschrieben, aber (mindestens) von Hunderten von Benutzern ständig gelesen, sodass die Lesegeschwindigkeit von wesentlich größerer Bedeutung ist.

Ich habe keine Erfahrung mit NoSQL-Datenbanken, aber nach dem, was ich gesammelt habe, sind sie die beste Lösung, um sie hier zu verwenden. Ich habe die beliebtesten NoSQL-Datenbanken gelesen, aber da sie sehr unterschiedlich sind und auch eine sehr unterschiedliche Tabellenarchitektur zulassen, konnte ich nicht entscheiden, welche Datenbank die beste ist.

Meine Hauptentscheidungen waren Cassandra und MongoDB, aber da ich nur sehr begrenzte Kenntnisse und keine wirkliche Erfahrung in Bezug auf große Datenmengen und NoSQL habe, bin ich mir nicht ganz sicher. Ich habe auch gelesen, dass PostreSQL auch mit solchen Datenmengen gut umgehen kann.

Meine Fragen sind folgende:

1. Sollte ich eine NoSQL-Datenbank für so große Datenmengen verwenden? Wenn nicht, kann ich mich an MySQL halten?
2. Welche Datenbank soll ich verwenden?
3. Sollte ich Datum und Uhrzeit in getrennten, indizierten (wenn möglich) Spalten aufbewahren, um die Daten für bestimmte Zeit- und Datumsperioden schnell abzurufen und zu verarbeiten, oder kann dies durch Aufbewahren des Zeitstempels in einer einzelnen Spalte erfolgen?
4. Ist hier ein Zeitreihendatenmodellierungsansatz angebracht, und wenn nicht, können Sie mir Hinweise für ein gutes Tabellendesign geben?

Danke.

Dies ist genau das, was ich jeden Tag mache, außer dass ich anstelle der Stundendaten die 5-Minuten-Daten verwende. Ich lade jeden Tag ungefähr 200 Millionen Datensätze herunter, daher ist die Menge, über die Sie hier sprechen, kein Problem. Die 5-Minuten-Daten sind ungefähr 2 TB groß und ich habe Wetterdaten, die 50 Jahre zurückliegen, auf Stundenbasis nach Standort. Lassen Sie mich Ihre Fragen beantworten, basierend auf meinen Erfahrungen:

1. Verwenden Sie dazu kein NoSQL. Die Daten sind stark strukturiert und passen perfekt in eine relationale Datenbank.
2. Ich persönlich verwende SQL Server 2016 und habe keine Probleme damit, Berechnungen für dieses Datenvolumen durchzuführen. Es befand sich ursprünglich auf einer PostgreSQL-Instanz, als ich meinen Job startete, und es konnte das Datenvolumen nicht verarbeiten, wie es sich auf einer kleinen AWS-Instanz befand.
3. Es wird dringend empfohlen, den Stundenanteil des Datums zu extrahieren und getrennt vom Datum selbst zu speichern. Glauben Sie mir, lernen Sie aus meinen Fehlern!
4. Ich speichere die meisten Daten in Listenform (DATUM, ZEIT, DATAPOINT_ID, WERT), aber so wollen die Leute die Daten nicht interpretieren. Seien Sie auf einige horrende Abfragen bezüglich der Daten und auf eine enorme Menge an Pivoting vorbereitet. Haben Sie keine Angst davor, eine de-normalisierte Tabelle für Ergebnismengen zu erstellen, die einfach zu groß sind, um im laufenden Betrieb berechnet zu werden.

Allgemeiner Tipp: Ich speichere die meisten Daten zwischen zwei Datenbanken, die erste sind reine Zeitreihendaten und normalisiert. Meine zweite Datenbank ist sehr de-normalisiert und enthält voraggregierte Daten. So schnell mein System ist, ich bin nicht blind für die Tatsache, dass Benutzer nicht einmal 30 Sekunden auf das Laden eines Berichts warten möchten - auch wenn ich persönlich der Meinung bin, dass 30 Sekunden zum Knacken von 2 TB Daten extrem schnell sind.

Um zu erläutern, warum ich empfehle, die Stunde getrennt vom Datum zu speichern, hier ein paar Gründe, warum ich das so mache:

1. Die Darstellung der elektrischen Daten erfolgt nach Stundenende- Daher ist 01:00 der Durchschnitt der elektrischen Leistung für die vorherige Stunde und 00:00 das Ende der 24. Stunde suchen plus die erste Marke des Folgetages.) Die Wetterdaten werden jedoch tatsächlich vorwärts dargestellt (aktuell und prognostiziert für die nächste Stunde). Nach meiner Erfahrung mit diesen Daten möchten Verbraucher die Auswirkungen analysieren, die das Wetter auf den Strompreis / -bedarf hat. Wenn Sie einen direkten Datumsvergleich verwenden würden, würden Sie tatsächlich den Durchschnittspreis für die vorherige Stunde mit der Durchschnittstemperatur für die folgende Stunde vergleichen, obwohl die Zeitstempel gleich sind.DATETIME Säule.
2. Performance. Ich würde sagen, dass mindestens 90% der von mir erstellten Berichte Diagramme sind, in denen normalerweise der Preis gegen die Stunde entweder für ein einzelnes Datum oder für einen Zeitraum von Datumsangaben aufgetragen wird. Wenn Sie die Zeit vom Datum trennen müssen, kann dies die Geschwindigkeit der Abfrage beeinträchtigen, mit der der Bericht generiert wird. Dies hängt vom gewünschten Datumsbereich ab. Es ist nicht ungewöhnlich, dass Verbraucher in den letzten 30 Jahren ein einziges Datum im Jahresvergleich sehen möchten (tatsächlich ist dies für das Wetter erforderlich, um die 30-Jahres-Normalwerte zu generieren) - dies kann langsam sein. Natürlich können Sie Ihre Abfrage optimieren und Indizes hinzufügen und mir vertrauen, dass ich einige verrückte Indizes habe, die ich lieber nicht hätte, aber das System läuft dadurch schnell.
3. Produktivität. Ich hasse es, mehr als einmal dasselbe Stück Code schreiben zu müssen. Früher habe ich Datum und Uhrzeit in derselben Spalte gespeichert, bis ich dieselbe Abfrage immer wieder schreiben musste, um den Zeitanteil zu extrahieren. Nach einer Weile hatte ich es satt, dies zu tun und extrahierte es in eine eigene Spalte. Je weniger Code Sie schreiben müssen, desto geringer ist die Wahrscheinlichkeit eines Fehlers. Wenn Sie weniger Code schreiben müssen, können Sie Ihre Berichte schneller veröffentlichen, und niemand möchte den ganzen Tag auf Berichte warten.
4. Endverbraucher. Nicht alle Endbenutzer sind Hauptbenutzer (dh sie können SQL schreiben). Wenn die Daten bereits in einem Format gespeichert sind, das mit minimalem Aufwand in Excel (oder ein anderes ähnliches Tool) importiert werden kann, werden Sie zu einem Helden im Büro. Wenn die Benutzer nicht einfach auf die Daten zugreifen oder diese manipulieren können, verwenden sie Ihr System nicht. Glauben Sie mir, ich habe vor ein paar Jahren das perfekte System entwickelt und niemand hat es aus diesem Grund verwendet. Beim Datenbankdesign geht es nicht nur darum, vordefinierte Regeln / Richtlinien einzuhalten, sondern das System nutzbar zu machen.

Wie ich oben sagte, basiert dies alles auf meiner persönlichen Erfahrung, und lassen Sie mich Ihnen sagen, es waren einige harte Jahre und eine Menge Umgestaltungen, um dahin zu gelangen, wo ich jetzt bin. Tun Sie nicht das, was ich getan habe, lernen Sie aus meinen Fehlern und stellen Sie sicher, dass Sie die Endbenutzer Ihres Systems (oder Entwickler, Berichtsautoren usw.) in die Entscheidungen über Ihre Datenbank einbeziehen.

PostgreSQL- und BRIN-Indizes

Testen Sie es selbst. Dies ist kein Problem auf einem 5 Jahre alten Laptop mit einer SSD.

EXPLAIN ANALYZE
CREATE TABLE electrothingy
AS
  SELECT
    x::int AS id,
    (x::int % 20000)::int AS locid,  -- fake location ids in the range of 1-20000
    now() AS tsin,                   -- static timestmap
    97.5::numeric(5,2) AS temp,      -- static temp
    x::int AS usage                  -- usage the same as id not sure what we want here.
  FROM generate_series(1,1728000000) -- for 1.7 billion rows
    AS gs(x);

                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series gs  (cost=0.00..15.00 rows=1000 width=4) (actual time=173119.796..750391.668 rows=1728000000 loops=1)
 Planning time: 0.099 ms
 Execution time: 1343954.446 ms
(3 rows)

So dauerte es 22 Minuten, um die Tabelle zu erstellen. Vor allem, weil der Tisch bescheidene 97GB hat. Als nächstes erstellen wir die Indizes,

CREATE INDEX ON electrothingy USING brin (tsin);
CREATE INDEX ON electrothingy USING brin (id);    
VACUUM ANALYZE electrothingy;

Die Erstellung der Indizes dauerte ebenfalls sehr lange. Weil sie BRIN sind, sind sie nur 2-3 MB groß und können problemlos im RAM gespeichert werden. Das Lesen von 96 GB erfolgt nicht sofort, ist jedoch für meinen Laptop bei Ihrer Arbeitsbelastung kein wirkliches Problem.

Jetzt fragen wir es ab.

explain analyze
SELECT max(temp)
FROM electrothingy
WHERE id BETWEEN 1000000 AND 1001000;
                                                                 QUERY PLAN                                                                  
---------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=5245.22..5245.23 rows=1 width=7) (actual time=42.317..42.317 rows=1 loops=1)
   ->  Bitmap Heap Scan on electrothingy  (cost=1282.17..5242.73 rows=993 width=7) (actual time=40.619..42.158 rows=1001 loops=1)
         Recheck Cond: ((id >= 1000000) AND (id <= 1001000))
         Rows Removed by Index Recheck: 16407
         Heap Blocks: lossy=128
         ->  Bitmap Index Scan on electrothingy_id_idx  (cost=0.00..1281.93 rows=993 width=0) (actual time=39.769..39.769 rows=1280 loops=1)
               Index Cond: ((id >= 1000000) AND (id <= 1001000))
 Planning time: 0.238 ms
 Execution time: 42.373 ms
(9 rows)

Update mit Zeitstempeln

Hier generieren wir eine Tabelle mit verschiedenen Zeitstempeln, um die Anforderung zum Indexieren und Durchsuchen einer Zeitstempelspalte zu erfüllen. Die Erstellung dauert etwas länger, da sie to_timestamp(int)wesentlich langsamer ist als now()(was für die Transaktion zwischengespeichert wird).

EXPLAIN ANALYZE
CREATE TABLE electrothingy
AS
  SELECT
    x::int AS id,
    (x::int % 20000)::int AS locid,
    -- here we use to_timestamp rather than now(), we
    -- this calculates seconds since epoch using the gs(x) as the offset
    to_timestamp(x::int) AS tsin,
    97.5::numeric(5,2) AS temp,
    x::int AS usage
  FROM generate_series(1,1728000000)
    AS gs(x);

                                                               QUERY PLAN                                                                
-----------------------------------------------------------------------------------------------------------------------------------------
 Function Scan on generate_series gs  (cost=0.00..17.50 rows=1000 width=4) (actual time=176163.107..5891430.759 rows=1728000000 loops=1)
 Planning time: 0.607 ms
 Execution time: 7147449.908 ms
(3 rows)

Jetzt können wir stattdessen eine Abfrage für einen Zeitstempelwert ausführen.

explain analyze
SELECT count(*), min(temp), max(temp)
FROM electrothingy WHERE tsin BETWEEN '1974-01-01' AND '1974-01-02';
                                                                        QUERY PLAN                                                                         
-----------------------------------------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=296073.83..296073.84 rows=1 width=7) (actual time=83.243..83.243 rows=1 loops=1)
   ->  Bitmap Heap Scan on electrothingy  (cost=2460.86..295490.76 rows=77743 width=7) (actual time=41.466..59.442 rows=86401 loops=1)
         Recheck Cond: ((tsin >= '1974-01-01 00:00:00-06'::timestamp with time zone) AND (tsin <= '1974-01-02 00:00:00-06'::timestamp with time zone))
         Rows Removed by Index Recheck: 18047
         Heap Blocks: lossy=768
         ->  Bitmap Index Scan on electrothingy_tsin_idx  (cost=0.00..2441.43 rows=77743 width=0) (actual time=40.217..40.217 rows=7680 loops=1)
               Index Cond: ((tsin >= '1974-01-01 00:00:00-06'::timestamp with time zone) AND (tsin <= '1974-01-02 00:00:00-06'::timestamp with time zone))
 Planning time: 0.140 ms
 Execution time: 83.321 ms
(9 rows)

Ergebnis:

 count |  min  |  max  
-------+-------+-------
 86401 | 97.50 | 97.50
(1 row)

So können wir in 83.321 ms 86.401 Datensätze in einer Tabelle mit 1,7 Milliarden Zeilen zusammenfassen. Das sollte vernünftig sein.

Stundenende

Die Berechnung des Stundenendes ist ebenfalls recht einfach. Schneiden Sie die Zeitstempel ab und fügen Sie dann einfach eine Stunde hinzu.

SELECT date_trunc('hour', tsin) + '1 hour' AS tsin,
  count(*),
  min(temp),
  max(temp)
FROM electrothingy
WHERE tsin >= '1974-01-01'
  AND tsin < '1974-01-02'
GROUP BY date_trunc('hour', tsin)
ORDER BY 1;
          tsin          | count |  min  |  max  
------------------------+-------+-------+-------
 1974-01-01 01:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 02:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 03:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 04:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 05:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 06:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 07:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 08:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 09:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 10:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 11:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 12:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 13:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 14:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 15:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 16:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 17:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 18:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 19:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 20:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 21:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 22:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-01 23:00:00-06 |  3600 | 97.50 | 97.50
 1974-01-02 00:00:00-06 |  3600 | 97.50 | 97.50
(24 rows)

Time: 116.695 ms

Es ist wichtig zu beachten, dass kein Index für die Aggregation verwendet wird, obwohl dies möglich ist. Wenn das Ihre typische Abfrage ist, möchten Sie wahrscheinlich einen BRIN date_trunc('hour', tsin)darin haben, ein kleines Problem, date_truncdas nicht unveränderlich ist, also müssen Sie es zuerst umbrechen, um es so zu machen.

Partitionierung

Ein weiterer wichtiger Punkt in Bezug auf PostgreSQL ist, dass PG 10 Partitionierungs-DDL bringt . So können Sie beispielsweise problemlos Partitionen für jedes Jahr erstellen. Unterteilen Sie Ihre bescheidene Datenbank in kleine Datenbanken. Dabei sollten Sie in der Lage sein, Btree-Indizes anstelle von BRIN zu verwenden und zu verwalten, was sogar noch schneller wäre.

CREATE TABLE electrothingy_y2016 PARTITION OF electrothingy
    FOR VALUES FROM ('2016-01-01') TO ('2017-01-01');

Oder Wasauchimmer.

Es wundert mich, dass hier niemand das Benchmarking erwähnt hat - bis @EvanCarroll mit seinem hervorragenden Beitrag daherkam!

Wenn ich Sie wäre, würde ich einige Zeit (und ja, ich weiß, es ist ein kostbares Gut!) Damit verbringen, Systeme einzurichten und das auszuführen, was Sie denken (hier können Sie Eingaben von Endbenutzern machen!), Sagen wir, Ihre 10 häufigsten Anfragen.

Meine eigenen Gedanken:

NoSQL-Lösungen können für bestimmte Anwendungsfälle sehr gut funktionieren, sind jedoch häufig für Ad-hoc-Abfragen unflexibel. Eine amüsante Darstellung von NoSQL durch Brian Aker - ehemaliger Chefarchitekt von MySQL - finden Sie hier !

Ich stimme @ Mr.Brownstone zu, dass Ihre Daten hervorragend für eine relationale Lösung geeignet sind (und diese Meinung wurde von Evan Carroll bestätigt )!

Wenn ich mich auf irgendwelche Ausgaben festlegen würde, dann auf meine Festplattentechnologie! Ich würde jedes Geld, das mir zur Verfügung steht, für NAS oder SAN oder für einige SSD-Festplatten ausgeben, um meine selten geschriebenen aggregierten Daten zu speichern!

Zuerst würde ich schauen, was ich zur Verfügung habe jetzt . Führen Sie einige Tests durch und zeigen Sie den Entscheidungsträgern die Ergebnisse. Sie haben bereits einen Vertreter in Form der Arbeit von EC ! Aber ein oder zwei schnelle Tests, die auf Ihrer eigenen Hardware durchgeführt wurden, wären überzeugender!

Dann denken Sie an Geld ausgeben! Wenn Sie Geld ausgeben möchten, sollten Sie sich zuerst die Hardware und nicht die Software ansehen. AFAIK, Sie können die Festplattentechnologie für einen Testzeitraum ausleihen oder, noch besser, ein paar Proof-of-Concept-Tests in der Cloud durchführen.

Meine persönliche erste Anlaufstelle für ein Projekt wie dieses wäre PostgreSQL. Das heißt nicht, dass ich eine proprietäre Lösung ausschließen würde, aber die Gesetze der Physik und der Festplatten sind für alle gleich! "Yae cannae beet die Gesetze der Physik Jim" :-)

Wenn Sie dies noch nicht getan haben, schauen Sie sich ein Zeitreihen-DBMS an, da es für das Speichern und Abfragen von Daten optimiert ist, bei denen der primäre Fokus auf dem Datums- / Zeit-Typ liegt. In der Regel werden Zeitreihendatenbanken zum Aufzeichnen von Daten im Minuten- / Sekunden- / Subsekundenbereich verwendet. Daher bin ich mir nicht sicher, ob sie für stündliche Inkremente geeignet sind. Allerdings scheint diese Art von DBMS einen Blick wert zu sein. Derzeit scheint InfluxDB die etablierteste und am weitesten verbreitete Zeitreihendatenbank zu sein.

Natürlich ist dies kein NoSQL-Problem, aber ich würde vorschlagen, dass eine RDBMS-Lösung zwar funktioniert, ein OLAP-Ansatz jedoch besser geeignet ist. Angesichts der sehr begrenzten Datenbereiche empfehle ich dringend, die Verwendung einer spaltenbasierten Datenbank zu untersuchen lieber als zeilenbasiert. Stellen Sie sich das so vor, Sie haben vielleicht 1,7 Milliarden Daten, aber Sie brauchen immer noch nur 5 Bits, um jeden möglichen Wert von Stunde oder Tag des Monats zu indizieren.

Ich habe Erfahrung mit einer ähnlichen Problemdomäne, in der Sybase IQ (jetzt SAP IQ) verwendet wird, um bis zu 300 Millionen Zähler pro Stunde mit Leistungsdaten für Telekommunikationsgeräte zu speichern. Ich bezweifle jedoch, dass Sie das Budget für eine solche Lösung haben. In der Open-Source-Arena ist MariaDB ColumnStore ein vielversprechender Kandidat, aber ich würde auch empfehlen, MonetDB zu untersuchen.

Da die Abfrageleistung ein wichtiger Treiber für Sie ist, sollten Sie überlegen, wie Abfragen formuliert werden. Hier zeigen OLAP und RDBMS die größten Unterschiede: - Mit OLAP normalisieren Sie die Abfrageleistung, nicht die Wiederholung, den Speicherbedarf oder sogar die Konsistenz. Zusätzlich zum ursprünglichen Zeitstempel (Sie haben sich hoffentlich daran erinnert, die Zeitzone zu erfassen?) Gibt es ein separates Feld für den UTC-Zeitstempel, weitere Felder für Datum und Uhrzeit sowie weitere Felder für Jahr, Monat, Tag, Stunde und Minute und UTC-Offset. Wenn Sie zusätzliche Informationen zu Standorten haben, können Sie diese in einer separaten Standorttabelle aufbewahren, die bei Bedarf nachgeschlagen werden kann. Sie können den Schlüssel zu dieser Tabelle in Ihrem Hauptdatensatz beibehalten, aber den vollständigen Standortnamen in Ihrer Haupttabelle beibehalten na ja, immerhin

Verwenden Sie abschließend separate Tabellen für häufig verwendete aggregierte Daten und füllen Sie diese mithilfe von Stapeljobs auf. Auf diese Weise müssen Sie die Übung nicht für jeden Bericht wiederholen, der einen aggregierten Wert verwendet und Abfragen vornimmt, die den aktuellen Wert mit dem historischen Wert oder dem aktuellen Wert vergleichen historisch zu historisch viel einfacher und viel, viel schneller.