Hood-Bildung - Gemeindegrenzen

[Steffen Winkler]

Hallo Christian,

das kann ich Dir genau sagen. Wenn es um Automatisierung geht, will man 
doch das Problem lösen und kein neues schaffen. Das Problem ist, dass 
die Berechnung zu viel Rechenzeit beansprucht. Das wird durch den Cache 
gelöst. Das neue Problem wäre, dass man manuell eingreifen muss. Wenn 
man die Zeit im Cache optimiert, muss man überhaupt nichts machen und 
gleichzeitig veraltet auch nichts oder die Datenbank wird immer voller. 
Man braucht für so einen Cache auch nicht unbedingt eine Datenbank, geht 
im Filesystem oder Speicher genau so einfach zu implementieren.

Grüße von Steffen.


Am 20.09.2018 um 08:34 schrieb Christian Dresel:
> hi
>
> On 20.09.2018 07:59, Steffen Winkler wrote:
>> Ja Christian,
>>
>> Genau so habe ich es gemeint. Der Cache ist dazu da, um die
>> Berechnungszeit zu verkürzen, um die Last zu reduzieren, für sonst
>> nichts. Die Berechnung ist ein Service. In der DB Tabelle steht lat,
>> lon, das Ergebnis Hood und ein timestamp für created. Ein Job, z.b alle
>> 4 Stunden schaut nach, was älter ist und wirft die weg, damit sich die
> warum willst du alte Daten nach Zeit X wieder weg werfen? Solange sich
> am Hoodsystem gar nichts ändert, sind die Daten im Cache immer und für
> ewig gültig.
> Erst wenn man eine Hood verschiebt/neu anlegt/löscht etc. dann muss man
> den Cache komplett neu aufbauen (einfach die Cache Tabelle leeren und
> mit meinen Prinzip baut er sich dann von selbst wieder auf).
>
> Zur Sicherheit könnte man natürlich 1x pro Woche oder so den Cache
> nochmal automatisiert löschen falls doch was schief läuft das es sich
> wieder aufräumt, halte ich aber eigentlich für unnötig.
>
> mfg
>
> Christian
>
>> Tabelle wieder aufräumt. Dann musst du nur die neue Berechnung machen
>> und dann ziehen die Router systematisch in die neue Hood um oder lösen
>> sich von der alten.
>>
>> Grüße von Steffen
>>
>> Am 20. September 2018 07:28:52 MESZ schrieb Christian Dresel
>> <fff at chrisi01.de>:
>>
>>      Hi Adrian
>>
>>      On 20.09.2018 00:24, mail at adrianschmutzler.de wrote:
>>
>>          Genau das möchte ich vermeiden, dann haben wir durch das Caching
>>          noch eine zusätzliche Schicht, die alles komplizierter macht.
>>
>>          Da muss man dann wieder prüfen, ob und welche Einträge man in
>>          der Datenbank aktualisieren muss und welche zu dem Geo-System
>>          gehören und welche zu den normalen Hoods. Das muss man dann
>>          umbuchen usw., und irgendwann blickt keiner mehr durch, was an
>>          welcher Stelle passiert.
>>
>>
>>
>>      ich hätte das ganze etwa so umgesetzt:
>>
>>      Wir legen im keyxchange eine weitere Tabelle an, wo wir die GeoDaten zu
>>      jeder Polygon-Hood abspeichern. Jeder GeoDatensatz verweist dann zu
>>      einer HoodID die wir ganz normal in die bereits vorhandene Hood Tabelle
>>      speichern.
>>      Die Hoodtabelle braucht dann noch ein Flag PolygonHood oder voronoiHood
>>      so das bei der voronoi Berechnung die PolygonHood nicht getestet wird.
>>
>>      Das hat auch den Vorteil, das mehrere Polygone auf eine Hood verweisen
>>      können (Schnaittach, Simmelsdorf und noch irgendwas verweist alles auf
>>      die Hood Schnaittach)
>>
>>      Im Cache würde ich dann "nur" noch lat, lon und HoodID abspeichern, der
>>      Cache muss gar nicht wissen ob es eine voronoi oder PolygonHood ist, die
>>      HoodID reicht.
>>
>>      Sobald man 1x irgendwas an irgendeiner Hood ändern, muss der Cache
>>      natürlich komplett geleert werden und wieder frisch aufgebaut werden.
>>      Das kann man wunderbar vor, bzw nach den ganzen Berechnung machen. Bevor
>>      man mit den Berechnen anfängt, fragt man die lat/lon die der Router
>>      gesendet hat im Cache ab, gibt es die hat man direkt die HoodID und kann
>>      die Hood den Router geben. Gibt es die nicht, führt man die komplette
>>      Berechnung durch und speichert am Ende in den Cache lat, lon und HoodID
>>      ab damit sie für den nächsten durchlauf zur Verfügung stehen.
>>
>>      Ja es ist ein zusätzlicher Fehler aber ich seh das nicht als kritisch
>>      an, wenn man den Cache leert falls man eine Hood anlegt oder ändert
>>      sollte eigentlich nichts passieren. Aktualisieren oder so muss man nie
>>      was, auch ist es egal zu welchen System der Cache gehört, nur eben den
>>      Cache komplett leeren (man könnte natürlich auch nur den Bereich leeren
>>      um den es sich handelt aber da wäre mir das Fehlerrisiko zu hoch, 1x den
>>      Cache komplett neu aufbauen geht schon) wenn man was an den Hoods ändert.
>>
>>      mfg
>>
>>      Christian
>>
>>
>>          Ich habe im Monitoring ein paar solche Stellen, weil ich durch
>>          die Rückwärtskompatibilität in bestimmten Situationen viele
>>          verschiedene "Systeme" parallel abdecken muss. Das ist der Tod!
>>
>>          Ich bin daher grundsätzlich gegen ein System am KeyXchange, bei
>>          dem man Daten der Router cachen muss. Beim Cachen von Hood-Daten
>>          bin ich noch am überlegen, aber auch da gibt es dann ähnliche
>>          Probleme bei Hoodwechsel etc., wo immer der Cache ein
>>          zusätzliches Problem darstellt.
>>
>>          Wenn das so kompliziert ist, dass es ohne Caching nicht geht,
>>          und wir jetzt ein System haben, dass wunderbar blitzschnell
>>          problemlos funktioniert, dann spricht das nicht für das System.
>>
>>          Grüße
>>
>>          Adrian
>>
>>              -----Original Message-----
>>              From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of
>>              fff at mm.franken.de
>>              Sent: Mittwoch, 19. September 2018 23:45
>>              To: franken at freifunk.net
>>              Subject: Re: Hood-Bildung - Gemeindegrenzen
>>
>>              Hallo Fabian,
>>
>>                  Zwar sendet jeder Router nur einen Koordinatensatz, im
>>                  worst-case
>>                  müssen aber alle n Polygon-Hoods geprüft werden, bevor
>>                  ein match
>>                  gefunden wird
>>
>>
>>              Wenn man das nicht in "Echtzeit" prüfen will (z.B. mit
>>              PostGIS), könnte man
>>              einfach mal von allen Routern die Koordinate auslesen, für
>>              jede Koordinate
>>              prüfen, in welcher Hood der Router liegt, und die Zuordnung
>>              in eine Tabelle
>>              schreiben.
>>
>>              Dann bräuchte man bei Anfragen nur in der Tabelle nachschauen.
>>
>>              Das bedeutet, dass man bei jedem neuen Router (bzw. bei jeder
>>              Koordinaten-Änderung) auch die Hood neu bestimmen und in der
>>              Tabelle
>>              ergänzen müsste. Dann wäre die Tabelle immer bis auf wenige
>>              Minuten
>>              aktuell.
>>
>>              Mit herzlichem Gruss,
>>              Markus
>>
>>