projekte:datenreise

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
projekte:datenreise [2012/04/18 18:44] macgoeverprojekte:datenreise [2017/03/01 19:19] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 14: Zeile 14:
   * Dateinamen : Dateinamen sind immer eine Fehlerquelle bei Falschbenennung oder auch bei bereits vorhandenen Dateinamen. Dadurch kann es zu zahlreichen unvorhergesehenen Fehlern kommen und das Interface sollte ja einfach sein, gell?   * Dateinamen : Dateinamen sind immer eine Fehlerquelle bei Falschbenennung oder auch bei bereits vorhandenen Dateinamen. Dadurch kann es zu zahlreichen unvorhergesehenen Fehlern kommen und das Interface sollte ja einfach sein, gell?
   * Timestamps: Für unsere statistische Auswertung müssen wir wissen, welche Station wie lange gebraucht hat. Einfach nur eine Datei hochladen, die dann von einem Prozess eingesammelt wird, der nur alle 15 Minuten läuft ist etwas ungenau. Dann könnte der Dateiname der Uploaddatei einen Timestamp enthalten. Der müsste aber korrekt im Layout und synchron zur zentralen Uhr sein. Zudem hat nicht jede Station überhaupt eine Uhrzeit da.   * Timestamps: Für unsere statistische Auswertung müssen wir wissen, welche Station wie lange gebraucht hat. Einfach nur eine Datei hochladen, die dann von einem Prozess eingesammelt wird, der nur alle 15 Minuten läuft ist etwas ungenau. Dann könnte der Dateiname der Uploaddatei einen Timestamp enthalten. Der müsste aber korrekt im Layout und synchron zur zentralen Uhr sein. Zudem hat nicht jede Station überhaupt eine Uhrzeit da.
-  * Threadsicherheit: Die Threadsicherheit ist notwendig, da immer 2 Prozesse auf die Daten zugreifen. Erstens der Upload/Download der Station und zweitens Auswertungsprozesse auf der zentralen Einheit. Wenn beide Prozesse gleichzeitig auf eine Datei zugreifen, bekommt der eine nur die Hälfte der Daten und die andere Hälfte landet im Nirvana. Konstrukte mit .lock Dateien oder ähnlichem sind für dieses Szenario ungeeignet bzw. zu komplex umzusetzen. Beim Schreiben in eine Datenbank achtet die Datenbank drauf, das nix passiert.+  * Threadsicherheit: Die Threadsicherheit ist notwendig, da immer 2 Prozesse auf die Daten zugreifen. Erstens der Upload/Download der Station und zweitens Auswertungsprozesse auf der zentralen Einheit. Wenn beide Prozesse gleichzeitig auf eine Datei zugreifen, bekommt der eine nur die Hälfte der Daten und die andere Hälfte landet im Nirvana. Konstrukte mit .lock Dateien oder ähnlichem sind für dieses Szenario ungeeignet bzw. zu komplex umzusetzen. Beim Schreiben in eine Datenbank achtet die Datenbank drauf, dass sich 2 verschiedene Prozesse ins Gehege kommen.
   * Authentifizierung: Für einen Dienst, der im Internet hängt und dessen öffentlich Schnittstellen dokumentiert sind, braucht man eine Authentifizierung. Sie muss nicht besonders komplex sein, aber man soll es ja auch nicht zu einfach machen.   * Authentifizierung: Für einen Dienst, der im Internet hängt und dessen öffentlich Schnittstellen dokumentiert sind, braucht man eine Authentifizierung. Sie muss nicht besonders komplex sein, aber man soll es ja auch nicht zu einfach machen.
-  * Datenintegrität: Damit uns nicht irgendwelche Skriptkiddies Pornobilder in die Daten schieben, sollten wir eine minimale Überprüfung der Daten vornehmen. Die Größe der Daten sollte zumindest ungefähr passen (vielleicht +/-10%). Wenn ein gewisser Prozentsatz (70%) falsch ist, ist vielleicht auch eine Schluderei oder eine defekte Station im Spiel. Hier sollte man überlegen, ob man der Station nochmal dieselben Daten schickt, oder die Daten einfach benutzt? Wenn eine Station offensichtlich defekt ist, weil sie nur noch quatsch schickt, könnte man sie auch aus dem Prozess rausnehmen und dem Admin Bescheid geben.Damit die Stationen nicht nur als Datensenke fungieren, sollte es neue Daten immer erst geben, wenn die letzten bereits wieder hochgeladen wurden.+  * Datenintegrität: Damit uns nicht irgendwelche Skriptkiddies Pornobilder in die Daten schieben, sollten wir eine Überprüfung der Daten vornehmen. Z.b. mit der [[http://de.wikipedia.org/wiki/Levenshtein-Distanz|Levenshtein-Distanz]]. Wenn diese Distanz zu groß ist, ist vielleicht Schluderei oder eine defekte Station im Spiel. Hier sollte man überlegen, ob man der Station nochmal dieselben Daten schickt, oder die Daten einfach benutzt? Wenn eine Station offensichtlich defekt ist, weil sie nur noch Quatsch schickt, könnte man sie auch aus dem Prozess rausnehmen und dem Admin Bescheid geben. Damit die Stationen nicht nur als Datensenke fungieren, sollte es neue Daten immer erst geben, wenn die letzten bereits wieder hochgeladen wurden.
  
 Habe mal ein Datenbankschema gefummelt: Habe mal ein Datenbankschema gefummelt:
  • projekte/datenreise.1334774686.txt.gz
  • Zuletzt geändert: 2017/03/01 19:04
  • (Externe Bearbeitung)