Die Anwendung sammelt kontinuierlich (ungefähr jede Sekunde) den Standort der Benutzer und speichert sie.

Diese Daten sind strukturiert. In einer relationalen Datenbank würde es gespeichert als: | user | timestamp | latitude | longitude |

Es gibt jedoch zu viele Daten. Täglich werden 60 × 60 × 24 = 86.400 Datensätze pro Benutzer erstellt. Selbst bei 1000 Benutzern bedeutet dies 86.400.000 Datensätze täglich.

Und es sind nicht nur 86.400.000 Datensätze täglich. Weil diese Datensätze verarbeitet werden und die verarbeiteten Versionen davon ebenfalls gespeichert werden. Multiplizieren Sie diese Zahl also mit ungefähr 2.

Wie ich die Daten verwenden möchte

Im Wesentlichen plane ich, gröbere Versionen von Standortdaten zu erstellen, um den Verbrauch zu vereinfachen. Das ist:

1. Sortieren Sie die empfangenen Daten nach Zeitstempeln.
2. Stellen Sie anhand dieser Liste der Reihe nach fest, ob sich der Standort erheblich geändert hat (indem Sie überprüfen, um wie viel sich der Breiten- und Längengrad geändert hat).
3. Stellen Sie die nicht signifikanten Standortänderungen als einen einzelnen Eintrag in der Ausgabe dar (daher ist die Ausgabe eine gröbere Version der Standortdaten).
4. Iterieren Sie diesen Prozess auf der Ausgabe, indem Sie eine noch größere Änderung des Breiten- und Längengrads für eine signifikante Änderung erfordern. Daher ist die Ausgabe, die aus der vorherigen Ausgabe erzeugt werden soll, noch grobkörniger.
5. Iterieren Sie den gesamten Prozess so oft wie nötig.
6. Sammeln Sie eine Reihe von Auflösungen und senden Sie sie an Benutzer. Speichern Sie außerdem alle Auflösungen der Daten für den späteren Verbrauch.

Womit soll ich diese Daten speichern? Sollte ich eine relationale Datenbank oder eine NoSQL-Lösung verwenden? Welche anderen Dinge sollte ich beim Entwerfen dieser Anwendung beachten?

Einige Alternativen zum Speichern dieser Daten:

1. Nachrichtenwarteschlange (möglicherweise verteilt), wie Apache Kafka

Dies wird für das Schreiben und Lesen eines Datenstroms optimiert. Es ist ideal zum Sammeln von Datenströmen in einem einfach zu verarbeitenden Format, kann jedoch normalerweise nur durch Auslesen des gesamten Streams abgefragt werden. Dies wäre also entweder zu Archivierungszwecken oder ein Zwischenschritt auf dem Weg zu einer Verarbeitungsschicht.

2. Relationale Datenbanken)

Sie können es einfach in die Datenbank schreiben. Wenn das Volume die Kapazität der zu verarbeitenden Datenbank überschreitet, können Sie die Datenbank sharden (= mehrere Teilmengen der Daten befinden sich auf verschiedenen Datenbankservern). Vorteil: Sie können eine relationale Datenbank verwenden und müssen nichts Neues lernen. Nachteil: Jeder Code, der sich mit der Datenbank befasst, muss wissen, auf welchem ​​Shard welche Daten leben. Aggregierte Abfragen müssen in der Anwendungssoftware durchgeführt werden.

3. Verteilte NoSQL-Datenbank wie Cassandra.

Sie schreiben Ihre Daten in eine verteilte NoSQL-Datenbank, die die Daten automatisch für Sie zersplittert. Mit Cassandra können Sie Abfragen im gesamten Cluster ausführen, wobei weniger Anwendungscode erforderlich ist, um wieder auf die Daten zurückzugreifen. Vorteil: natürlicher geeignet für große Datenmengen, Nachteil: Erfordert spezifisches Fachwissen und ein tiefes Verständnis der Funktionsweise dieser Systeme, um eine gute Leistung zu erzielen und die Daten gemäß Ihren Anforderungen abfragbar zu machen. NoSQL ist kein magischer Performance-Fix, sondern eine Reihe von Kompromissen, die verstanden werden müssen, um navigiert zu werden.

4. Hadoop / Datei

Die Daten werden an Dateien angehängt, die von der Hadoop-Plattform automatisch auf die Server verteilt, auf diesen Servern mit Tools wie M / R oder Apache Spark verarbeitet und schließlich (als Datei) mit einer Hadoop SQL-Engine wie Hive oder Impala abgefragt werden.

Welche soll ich wählen?

Die Kompromisse zwischen diesen Alternativen sind komplex und hängen sehr stark von Ihren Schreib- und Lesemustern ab. Die einzige Person, die über diese Kompromisse entscheiden kann, sind Sie. Wenn Sie nicht die Zeit haben, ein tiefes Verständnis für diese Alternativen aufzubauen, verwenden Sie einfach eine relationale Datenbank und finden Sie im Laufe der Zeit eine Sharding-Lösung heraus. Höchstwahrscheinlich YAGNI .

Schauen Sie sich Ihre Anforderungen etwas genauer an. Es gibt eine Möglichkeit, jede Sekunde die Illusion einer Verfolgungsposition zu erzeugen.

Wenn Sie eine App haben, die Ihren aktuellen GPS-Standort kennt und in eine Datenbank schreibt, warum sollten Sie den Standort dann weiter schreiben, wenn er sich nicht ändert? Selbst wenn Sie die Daten benötigen und der Benutzer 7 Stunden lang geschlafen hat, können Sie die fehlenden Zeitfenster programmgesteuert mit einem doppelten Speicherort ausfüllen, um Ihre Berechnungen oder Zuordnungen durchzuführen, oder was auch immer Sie sonst noch tun müssen.

Wenn Sie den Standort jede Sekunde verfolgen, müssen Sie diese Daten für immer speichern? Sie können die Datensätze in einer anderen Datenbank archivieren, um zu verhindern, dass die aktuelle Tabelle zu groß wird. Oder Sie können einfach die Aufzeichnungen aufbewahren, in denen sich die Position ändert. Dies ist in Data Warehouses üblich.

Ihre Daten sind eine Reihe von Zeitreihen. Sie haben Sätze von Zahlen angegeben (zwei pro Benutzer), die sich mit der Zeit entwickeln. Normalerweise suchen Sie KEINEN relationalen Speicher, sondern einen RRD-Speicher. Dieser Speicher konzentriert sich stark auf die Reduzierung der E / A-Arbeit zahlreicher kleiner Schreibvorgänge durch Pufferung.

Relationale Speicherung ist eine Häresie für dieses Volumen von Zeitreihen. Seien Sie jedoch gewarnt, dass die Entwicklung von RRD in Bezug auf programmierbare Exploits nicht so gut unterstützt wird wie SQL. Sie möchten wahrscheinlich ernsthafte Integrationsarbeiten durchführen, die jedoch angesichts Ihrer Anforderungen kaum zu vermeiden sind.