Laden...

Suche Architektur um versch. Datenquellen zu lesen, Daten verarbeiten, exportieren & zu speichern

Erstellt von Unfug vor 3 Jahren Letzter Beitrag vor 3 Jahren 657 Views
U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 3 Jahren
Suche Architektur um versch. Datenquellen zu lesen, Daten verarbeiten, exportieren & zu speichern

TLDR: Unterschiedliche Datenquellen mit Millionen Datensätze in einem ViewModel, verschiedene Verarbeitungsklassen, verschiedene Exportformate. Parsen, Rohdatenspeicherung, Vorgehensweise gesucht.

Hallo zusammen,

ich habe heute folgendes Problem, worüber ich mir seit ein paar Tagen den Kopf zerbreche.

Das Problem ist wie folgt:
Ich erhalte aus verschiedenen Datenquelle komplexe Datenstrukturen ca. 10 Millionen pro Monat.

Mit Komplex ist insbesondere gemeint, dass diese Datenstrukturen aus unterschiedlichen Datenbanken abgeleitet wurden und eine Vielzahl unterschiedliche Datentypen beinhalten, die wiederum Propertys bis in die 5 Ebene haben. Doch diese unterschiedlichen Datentypen hängen auch wieder zusammen. Zu identifzieren an Property Werten.
Manchmal ändert sich nach einigen Tagen ein Property was bedeutet, dass ein Merge gemacht werden muss (kein ersetzen. Es muss klar sein, dass sich etwas verrändert hat).

Am Ende des Tages bilden alle jedoch das Selbe ab.

Man stelle sich exemplarisch (hat überhaupt nichts damit zu in Wirklichkeit zu tun) vor es gehe um Rechnungen.
Jede Quelle definiert eigene Typen für die Rechnung, eigene Enums, eigener Text, eigene Währungen ... trotzdem ist es am Ende ...eine Rechnung.

Nun geht die Geschichte auch weiter

Obwohl die Quellen unterschiedlich sind, die Datentypen komplett anders, gibt es Überschneidungen. Ich muss also aus den unterschiedlichen Quellen und Daten in der UI eine Ansicht machen.
Die dargestellten Daten müssen dann in fachlichen Methoden verarbeitet und ausgewertet werden.
Zum Schluss: Export. In verschiedene Datenformate. Auch in Formate, die ich aktuell noch nicht kenne.

Worauf ich also hinaus möchte : Wie wäre hier eine gute Strategie? Meine Überlegungen:

  1. Die Rohdaten speichern und dann nur im Speicher die benötigen Klassen berechnen für die Anzeige?
    pro: Schnell zu entwickeln. Rohdaten zu haben ist immer gut. Jede Änderung in den Rohdaten würde als neuer Rohdatensatz gespeichert.
    cons: Die Berechnung wird mehrere Minuten dauern, da jeden Monat mind. 10 Millionen Datensätze hinzukommen.

  2. Ein gemeinsames Datenformat definieren. Rohdaten beim Abrufen in dieses parsen und speichern.
    pro: Angepasst auf die derzeitigen Anforderungen
    cons: Nicht alle Felder werden übernommen und könnten für immer verloren gehen. Spätere Exportformate könnten ggfs. nicht umgesetzt werden

  3. Rohdaten speichern und ein gemeinsames Datenformat
    pro: Je nach Anwendungsfall liegen konkrete Daten in der Datenbank vor
    cons: Datenbank wächst enorm. (Manche würden sagen Redundanz wäre ein Cons)

Die Datenbankgröße macht mir eigentlich keine Sorgen, jedoch die Performance an sich aber auch die Klassenstruktur, dass man den Überblick verliert.
Vielleicht sehe ich den Wald vor lauter Bäumen nicht. Aber wie würdet ihr hierbei vorgehen? Wie verliere ich jetzt nicht den Überblick und behalte aber die Möglichkeit zukünftige Anforderungen sauber abzudecken, welche sich auf die Rohdatenstrukturen beziehen?

Danke

16.806 Beiträge seit 2008
vor 3 Jahren

Das ist so ein Thema, auf das Du i.d.R. keine pauschale Antwort bekommen wirst.

Deine Strategien haben ja völlig verschiedene Ansätze und Nachteile, die Du selbst abwägen musst.

  1. skaliert nicht ordentlich. Wichtig für Dich? Für andere evlt nicht.
  2. verliert Daten? NoGo für Dich? Für andere evtl. nicht.
  3. Speicherplatz ist für viele kein Problem. Aber für Dich?

Wenn wir mit unterschiedlichen Datenquelle arbeiten, dann speichern wir die Daten bei Ankunft im Originalformat ab (meist auf Blob Storage, weil billig).
Wir ziehen uns dann nur die Infos raus, die wir brauchen.

Wir speichern uns jedoch auch den Parser und die Version, die wir zum ordentlichen Lesen brauchen; so kann man im Nachhinein noch nicht gelesen Werte aus den Originalen holen.

Das gilt als Best Practise zB. bei Telemetrie-Informationen im Rahmen von IoT.

Auch in Formate, die ich aktuell noch nicht kenne.

Ja, so ne Glaskugel-Anforderung an Software gibt es ja immer.
Kann man ignorieren, weil natürlich totaler Quatsch.

Entweder es gibt konkrete Anforderungen - oder nicht.

T
2.219 Beiträge seit 2008
vor 3 Jahren

Ich würde auch die Rohdaten 1:1 speichern, damit man diese auch immer in reiner Form vorliegen hat.

1.Die Daten insgesamt würde ich aber nicht in den Speicher schaufeln, wenn es nicht nötig ist.
Die Daten solltest du für die Anzeige in einer eigenen Tabelle vorverdichten lassen.
Die Rohdaten jedesmal einladen und berechnen zu lassen, dauert scheinbar schon zu lange und wenn du größere Zeiträume durchlaufen musst, würdest du viel zu viele Daten einladen müssen.

2.Wenn du die Rohdaten gesondert speicherst, kannst du immer noch ein gemeinsames Format umsetzen.
Wenn du die Daten später noch brauchst, hast du diese ja uns kann diese ggf. nachtragen lassen.
Kostet dich nur Speicherplatz und später ggf. beim nachparsen Rechenzeit.

3.Rohdaten solltest du für diesen Fall speichern.
Wenn du später merkst, dass du diese nicht brauchst, kannst du diese immer noch löschen.
Am Speicherplatz sollte es nicht mangeln.
Redundanz solltest es hier in den Tabellen nicht geben, da dein eigenes Format eine Untermenge von den Rohdaten darstellen.
Also im Endeffekt aus den Rohdaten rutnergerechnet sind.
Redundanz im Sinne der DB wäre es, wenn mehrere Datensätze doppelte Datenliefern.
Dies kann aber gerade bei Rechnungen auch gewollt sein.
Ein Verwais auf Kundendaten über eine Kundennummer wäre bei Rechnungen fatal.
Wenn sich die Adresse des Kunden ändert, darf sich dies nicht auf Rechnungen auswirken, da sonst die Daten verfälscht würden!

Aus meiner Sicht sind 10 Mio. Datensätze erst einmal nicht viel pro Monat.
Wir sammeln in einem Projekt solche Datenmengen in Form von GPS Daten, CAN Bus Daten etc.
Wenn du aber 10-20 Formate hast und jedes solche Datenmengen produzieren, solltest du ggf. schauen ob ein NoSQL Ansatz wie CouchDB/MongoDB ggf. was für dich ist.
Dort kannst du die Daten als Json speichern und per Map/Reduce dann auswerten und ggf. gleich in dein Format umwandeln lassen.
Ebenfalls kann sich auch eine Struktur im Dateisystem ablegen, wenn die Daten es zu lassen.
Hängt halt alles von den jeweiligen Daten und Anforderungen ab.

Wären alles Möglichkeiten, hier müsstest du aber selbst evaluieren was du davon brauchst.
Wenn die Anforderungen ein gemeinsames Format vorschreiben, würde ich die Daten Roh speichern und in das Format umwandeln und liefern.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

U
Unfug Themenstarter:in
133 Beiträge seit 2006
vor 3 Jahren

Vielen Dank.

Das hat mir schon viele neue/alte Denkanstöße gegeben.

Werde schauen, dass ich es dann mal mit der Variante austeste, dass ich die Rohdaten und zusätzliche die weiteren Formate speichere.

Danke