Großer Geodatensatz (> 22 Billionen Elemente) mit schneller Abfrageleistung (<1s)

Ich bin dabei, ein neues System für einen großen Geodatensatz zu entwerfen, für den eine schnelle Leseabfrageleistung erforderlich ist. Daher möchte ich sehen, ob jemand der Meinung ist, dass es in der folgenden Situation möglich ist oder Erfahrung / Ratschläge zu geeigneten DBMSs, Datenstrukturen oder alternativen Methoden hat, um die erforderliche Leistung zu erzielen:

Daten werden kontinuierlich aus verarbeiteten Satellitenradardaten erzeugt, die eine globale Abdeckung haben werden. Basierend auf der Satellitenauflösung und der Landbedeckung des Globus schätze ich, dass der gesamte Datensatz Werte an 75 Milliarden diskreten Orten auf dem Globus liefert. Über die Lebensdauer eines einzelnen Satelliten werden an jedem dieser Standorte bis zu 300 Werte ausgegeben (also ein Gesamtdatensatz von> 22 Billionen Werten). Dies gilt für einen Satelliten, und es gibt bereits einen zweiten Satelliten im Orbit, wobei zwei weitere in den nächsten Jahren geplant sind. Es wird also eine Menge Daten geben! Ein einzelnes Datenelement ist sehr einfach und besteht nur aus (Längengrad, Breitengrad, Wert), aber aufgrund der Anzahl der Elemente schätze ich, dass ein einzelner Satellit bis zu 100 TB produzieren kann.

Die geschriebenen Daten sollten niemals aktualisiert werden müssen, da sie nur wachsen, wenn neue Satellitenerfassungen verarbeitet werden. Die Schreibleistung ist nicht wichtig, aber die Leseleistung ist entscheidend. Das Ziel dieses Projekts ist es, die Daten über eine einfache Oberfläche wie einen Layer über Google Maps zu visualisieren, wobei jeder Punkt einen Farbwert hat, der auf dem Durchschnitt, dem Gradienten oder einer Funktion über die Zeit basiert. (Demo am Ende des Beitrags).

Ausgehend von diesen Anforderungen muss die Datenbank skalierbar sein, und wir werden wahrscheinlich nach Cloud-Lösungen suchen. Das System muss in der Lage sein, Geodatenabfragen wie "Punkte in der Nähe (lat, lon)" und "Punkte innerhalb (box)" zu verarbeiten und eine Leseleistung von <1s für die Lokalisierung eines einzelnen Punkts sowie Polygone mit bis zu 50.000 Punkte (obwohl bis zu 200.000 Punkte vorzuziehen wären).

Bisher habe ich einen Testdatensatz von ~ 750 Millionen Datenelementen an 111 Millionen Standorten. Ich habe eine postgres / postGIS-Instanz ausprobiert, die einwandfrei funktioniert hat, aber ohne die Möglichkeit des Splitterns kann ich dies nicht, da die Daten wachsen. Ich habe auch eine mongoDB-Instanz ausprobiert, was wiederum für OK erscheint und mit Sharding kann es ausreichend sein, mit dem Datenvolumen zu skalieren. Ich habe kürzlich etwas über Elasticsearch gelernt, daher sind Kommentare dazu hilfreich, da sie für mich neu sind.

Hier ist eine kurze Animation dessen, was wir mit dem gesamten Datensatz erreichen wollen:

Dieses GIF (aus meiner Postgres-Testversion) liefert (6x3) vorberechnete Raster-Kacheln, die jeweils ~ 200.000 Punkte enthalten und jeweils ~ 17 Sekunden benötigen, um sie zu generieren. Durch Klicken auf einen Punkt wird das Diagramm erstellt, indem alle historischen Werte in <1s an der nächstgelegenen Position gezogen werden.

Entschuldigung für den langen Beitrag, alle Kommentare / Ratschläge sind willkommen.

Sie könnten nach Ort scherben. Teilen Sie den Globus in ein Raster, und weisen Sie jedem Quadrat in diesem Raster einen Server zu. Da Sie Cloud erwähnt haben, wäre das gut für Cloud geeignet. Natürlich müssen Sie die Ergebnisse von mehreren Servern manuell zusammenführen.

Auf diese Weise können Sie jede beliebige Datenbanklösung verwenden. Es muss nicht eigenständig skalierbar sein.

Die einzelnen Quadrate enthalten unterschiedliche Datenmengen. Sie können für sie unterschiedlich große Computer verwenden (da dies eine Cloud ist) oder mehrere kleine Shards auf demselben Computer platzieren.

Dieses Sharding-Schema eignet sich hervorragend für die Art von Abfragen, die Sie ausführen, da jede Abfrage nur sehr wenige Shards berühren muss. Die Zeitverschiebung ist schlechter, da für jede Abfrage alle Zeitverschiebungen berührt werden müssen. Zufälliges Sharding hat das gleiche Problem.

Alles in allem ist dies ein einfacher Sharding-Fall, da das Abfragemuster so gut zum Sharding-Schema passt.

Eigentlich frage ich mich, ob Sie dafür überhaupt eine Datenbank brauchen. Vielleicht können Sie den Globus in 1000x1000 Kacheln oder kleiner unterteilen und für jede Kachel eine flache Datei im Blob-Speicher haben. Die Speicherung von Blobs macht 1M-Blobs überhaupt nichts aus.

Das Ausführen einer Abfrage ist mit diesem Speicherschema konzeptionell sehr einfach. Sie können die Daten auch redundant in mehreren Rasterauflösungen speichern.

Wie aktuell müssen Ihre Leseanfragen sein?

Sie können die Datenbank nach Zeit partitionieren, wenn auf der Karte nur die aktuellste Messung angezeigt werden soll. Dies würde Ihre Abfragelast für die Karte verringern.

Für den Verlauf eines bestimmten Punkts können Sie einen zweiten Speicher halten, indem x und y den Verlauf anzeigen. Dies kann mit einer nächtlichen Aktualisierung / Aktualisierung erfolgen, da sich die Verlaufsdaten nicht ändern.

Dann könnten Sie Durchschnittswerte mit gröberen Auflösungen vorberechnen, um Karten mit verschiedenen Zoomstufen zu integrieren. Dies würde die Anzahl der abzurufenden Punkte für große Kartenbereiche verringern (verkleinern). Feinere Auflösungen würden für stärker gezoomte Karten verwendet, die kleinere Bereiche abfragen. Wenn Sie dies wirklich beschleunigen müssen, können Sie Kacheln als Blobs berechnen und in Ihrer Anwendung interpretieren.

Da dies eine Neuberechnung der aggregierten Informationen mit sich bringen würde, würden die Abfrageergebnisse eine gewisse Latenz aufweisen. Je nachdem, wie viel Latenz akzeptabel war, können Sie mit dieser Methode Ihre Lesevorgänge optimieren.

OK, also müssen Ihre Punkte im Laufe der Zeit gemittelt werden. Bei dieser Berechnung gehen Ihre tatsächlichen Abfragen vermutlich von 22 Billionen Elementen ziemlich weit zurück, da die Rasterwerte für die Abfrage vorberechnet werden können.

Es klingt so, als gäbe es zwei Abfrageklassen: eine, um zu verstehen, welche Positionen im aktuellen Ansichtsfenster liegen, und eine, um die gewünschte Statistik für diese Punkte zu liefern. Mein Vorschlag ist, für jedes einzelne Werkzeug ein eigenes Spezialwerkzeug zu verwenden.

Ich gehe davon aus, dass sich alle Messungen auf den gleichen Satz von 75 Mrd. Punkten beziehen. Diese Lat / Longs sind daher statisch, sobald sie hergestellt sind. Sie können zu einmaligen Kosten gruppiert, aggregiert und indiziert werden. Daher würde ich vorschlagen, nach Region und Zoomstufe zu splittern. Die Größe jedes Shards hängt von der Leistung ab, die mit jeder GIS-Instanz erzielt werden kann.

Das GIS gibt eine Reihe von Punkten zurück, die an eine Zeitreihendatenbank übergeben werden. Dieser hält die Messwerte und führt Aggregate durch. KDB ist eine, die ich kenne. Es zielt auf den Wertpapierhandel ab, der weniger Schlüssel, aber mehr Datenpunkte pro Schlüssel enthält als Ihr Szenario.

Die Übertragung der Schlüsselwerte vom GIS-Server in die timeseries DB ist kostenpflichtig. Meine Hypothese ist, dass diese Kosten durch die schnellere Verarbeitung in der aufgabenspezifischen Zeitreihen-DB erstattet werden. Aus dem Wortlaut der Frage geht hervor, dass eine einzelne Instanz nicht in der Lage sein wird, alle Daten zu speichern, sodass ein gewisser serverübergreifender Datenverkehr unvermeidlich erscheint. Angesichts der relativen Geschwindigkeit der Komponenten ist es wahrscheinlich, dass das Senden eines Keysets an einen Remote-Server, auf dem die Daten zwischengespeichert sind, schneller ist als das Lesen der Daten von der lokalen Festplatte.

Wenn der Punktfindungs- und der Wertberechnungsteil lokal zueinander sein können, würde ich natürlich eine schnellere Reaktion erwarten. Mein (begrenztes) Verständnis ist, dass das Finden der N nächsten Nachbarn zu einem bestimmten Punkt eine nicht triviale Aufgabe ist. Aus diesem Grund habe ich vorgeschlagen, für die Ausführung eine bestimmte Software zu verwenden. Wenn die Punktfindung auf reduziert werden kann

where latitude between x1 and x2
and logitude between y1 and y2

dann könnte dieser Teil von der wertspeichernden Software verarbeitet und das GIS aus der Architektur entfernt werden.

Ich habe ein solches System nicht implementiert. Ich denke hier wirklich nur laut nach. Im Petabyte-Bereich gibt es keine Standardlösungen. Es gibt jedoch viele Anbieter von Satellitendaten, sodass Ihr Problem behoben werden kann. Viel Glück.