Hood-Bildung - Gemeindegrenzen

[Steffen Winkler]

Ääää, ich meine, nach jeder Berechnung löschst Du alle, die älter als 4 
stunden sind. brauchst dann nicht mal einen cronjob.

Steffen

Am 20.09.2018 um 07:59 schrieb Steffen Winkler:
> 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 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 
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20180920/80e4553c/attachment.html>