| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| projekte:datenreise [2012/05/22 12:01] – [Infrastruktur] macgoever | projekte:datenreise [2017/03/01 19:19] (aktuell) – Externe Bearbeitung 127.0.0.1 |
|---|
| * 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. | * 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: |