FW: Hood-Bildung - Gemeindegrenzen

Adrian Schmutzler mail at adrianschmutzler.de
Fr Sep 21 12:38:28 CEST 2018


Reply All ist schwierig

-----Original Message-----
From: Adrian Schmutzler [mailto:mail at adrianschmutzler.de] 
Sent: Freitag, 21. September 2018 12:38
To: 'Michael Fritscher' <michael at fritscher.net>
Subject: RE: Hood-Bildung - Gemeindegrenzen

Hallo,

> -----Original Message-----
> From: Michael Fritscher [mailto:michael at fritscher.net]
> Sent: Freitag, 21. September 2018 12:20
> To: Freifunk Franken <franken at freifunk.net>; Adrian Schmutzler
> <mail at adrianschmutzler.de>; 'Freifunk Franken' <franken at freifunk.net>
> Subject: RE: Hood-Bildung - Gemeindegrenzen
> 
> Moin.
> 
> nerven Float-indexis wirklich so arg? bzw. schlimmer als strings? Und notfalls
> gibts ja auch noch den decimal-zahlentyp...

Naja, ein Index soll ja eigentlich was präzises sein. Wenn du jetzt an die ganzen Rundungsprobleme usw. denkst, die man mit float hat, dann wird irgendwie automatisch klar, dass das als Index schwierig ist. Ich hab das aber auch mal im Internet gelesen.
Keine Ahnung, was decimal da helfen soll.

> 
> @write+readproblem: da könnte man sich ne memory-DB anschauen - mysql
> hat da ja 1-2 Typen. Ich glaub es gibt auch einen DB-typ, wo man nur selecten
> und inserten kann (archive?). Weiß nur nicht ob letztere Indexe kann. Da
> müsste das locken unproblematisch sein.

Nur für den Cache könnte man memory überlegen. Das letzte Mal, als ich mich mit dem Zeug beschäftigt habe, war aber die Essenz, das InnoDB eigtl. das Optimum ist.
Archive ist halt für Archiv-Daten. Die Prämisse ist da, dass man sehr selten liest (und daher ist Lesen teuer). Wir wollen aber viel Lesen und viel Schreiben, und dafür ist Archive nicht gedacht.

> 
> Wieso gibt das eigentlich ein Deadlock? ich würde erwarten, dass im notfall
> einfach bissle gewartet wird? Zumal wir da ja auch keine Transaktionen haben,
> sondern einfache Queries...

Jede Query lockt einen bestimmten Teil der Tabelle. Das kann eine Zeile sein, teilweise ist es aber auch ein bestimmter Bereich eines Index.
Normalerweise wird das hintereinander abgearbeitet und ist kein Problem.
Es kann nun passieren, dass zwei Anfragen ihre Locks so setzen, dass es sich gegenseitig ausschließt, diese nacheinander zu bearbeiten. Dann nützt Warten auch nichts. Das ist ein deadlock. MySQL erkennt eine solche Situation automatisch (ohne warten). Die Situation wird dann gelöst, indem eine Anfrage per Error gekillt wird.

Das kann durchaus auch passieren, wenn man einmal schreibt und einmal liest. Ich kann dir jetzt leider aus Zeitgründen nicht noch mehr raussuchen, die Situationen, unter denen das auftritt, sind im Monitoring sicher auch viel komplexer. Vll. kommen wir im KeyXchange auch ohne solche Probleme raus. Ich weiß es aber nicht.

Google einfach mal nach "mysql deadlock".

Man müsste das aber halt mal nen Tag lang mit vielen gleichzeitigen Anfragen testen. Und wir merken beim KeyXchange halt auch nicht, wenn er nicht mehr funktioniert.

Grüße

Adrian

> 
> Viele Grüße,
> Michael Fritscher
> 
> Am 21. September 2018 11:48:17 MESZ schrieb Adrian Schmutzler
> <mail at adrianschmutzler.de>:
> >Hallo Christian,
> >
> >ich habe gestern noch über den Cache nachgedacht.
> >
> >Zunächst ein Detail:
> >Es ist problematisch, Indizes auf Float-Werte zu legen. D.h. im Cache
> >müssen die Koordinaten immer als string (z.B. CHAR(16) oder so was)
> >abgelegt werden, sonst wird die Performance grottig. Ich glaube, das
> >ist im Skript ohnehin so, da du ja direkt die GET-Werte nimmst. (Oder
> >man rechnet auf int um oder so Firlefanz, ist bei der kleinen Tabelle
> >aber nicht nötig)
> >
> >Dann ein Problem:
> >Das große Problem beim KeyXchange ist, dass alle 1000-2000 Anfragen
> >gleichzeitig (in der selben Sekunde) ankommen. Die wollen dann alle in
> >dieser selben Sekunde am Cache rumschreiben und rumlesen. Das reine
> >Lesen wäre jetzt überhaupt kein Problem, aber sobald du was schreiben
> >willst, werden bestimmte Bereiche der Tabelle gelockt. Will jetzt ein
> >zweiter Router im selben gelockten Bereich schreiben (oder lesen),
> >macht es bumm, und es gibt ein Deadlock (d.h. der Code macht nen Error
> >und bricht ab). Das wars dann für den Router, er kriegt keine Antwort.
> >Sind wir in der Phase des Cache-Aufbaus, wird das am Anfang sehr oft
> >hintereinander der Fall sein, und ein Teil der Router kriegt dann z.B.
> >eine halbe Stunde keine korrekten Daten o.ä.
> >Ich habe vergleichbare Probleme beim Monitoring durchaus gelegentlich,
> >obwohl hier die Gleichzeitigkeit von Aufrufen sehr selten ist.
> >InnoDB ist hier zwar recht gut, aber gerade in Tabellen mit mehr als
> >einer Index/Unique-Spalte (i.e. lat/lng) wird das richtig schlimm.
> >
> >Ich gehe davon aus, dass du in deinem Test die Anfragen alle
> >hintereinander gemacht hast?
> >
> >Müsste man mal was mit Multi-Threading nehmen und 256 Anfragen oder so
> >gleichzeitig reinbrüllen und dann messen, wieviel 500er zurückkommen.
> >Ich habe leider keine Zeit, sonst würde ich schnell was mit C# bauen.
> >
> >Mir fällt nichts ein, wie man das generelle Problem wirklich beheben
> >kann. Man könnte es aber auf verschiedene Arten lindern:
> >- Man baut am Anfang des Skriptes ein kleines random ein (0-10 sec).
> >Das ist zwar Mist, aber wird die Rate der locks senken (ich werde
> >demnächst sowas für die Firmware rumschicken)
> >- Man gibt die Antwort an den Router schon raus und schreibt DANACH in
> >den Cache (dann geht es nur kaputt, wenn das deadlock beim Lesen
> >entsteht, aber nicht, wenn es beim Schreiben entsteht. Ich glaube aber,
> >die entstehen immer beim Lesen...).
> >- Man setzt das Schreiben im Cache in einen try/catch Block (wie zuvor
> >nützt das nur was, wenn das Schreiben kaputt geht, beim Lesen trotzdem
> >kaputt)
> >- Man schreibt die Strings für lat und lng hintereinander in einen
> >String und macht daraus einen Single-Index (höhere Such/Lese-Zeit, aber
> >weniger Locks, da kein Clustered-Index (glaube ich zumindest))
> >- Man lässt den Cache weg (dann haben wir sicher keine Locks, dafür
> >dauert es halt u.U. ewig bis ne Antwort kommt, dafür kommt sich sicher
> >(irgendwann...))
> >
> >Anmerkung zum Schluss:
> >
> >$sql = "INSERT INTO cache(lat,lon,hoodid) VALUES
> >('$lat','$lon','$hoodid')";
> >
> >Das geht kaputt, wenn zweimal gleichzeitig die gleichen Koordinaten
> >kommen (beide finden sie nicht im Cache (gleichzeitig) und dann wollen
> >beide sie später deswegen reinschreiben). Was man hier macht:
> >
> >$sql = "INSERT INTO cache(lat,lon,hoodid)
> >VALUES ('$lat','$lon','$hoodid')
> >ON DUPLICATE KEY UPDATE
> >	hoodid=VALUES(hoodid)
> >";
> >
> >(Unter der Annahme, dass lat und lon zusammen den PRIMARY KEY bilden.)
> >
> >Abgesehen davon ist das ein Königreich für SQL-Injection.
> >
> >So, fertig mit mosern.
> >
> >Grüße
> >
> >Adrian
> >
> >
> >> -----Original Message-----
> >> From: franken [mailto:franken-bounces at freifunk.net] On Behalf Of
> >Christian
> >> Dresel
> >> Sent: Freitag, 21. September 2018 10:07
> >> To: michael at fritscher.net; Freifunk Franken <franken at freifunk.net>
> >> Subject: Re: Hood-Bildung - Gemeindegrenzen
> >>
> >> hi
> >>
> >> On 19.09.2018 12:14, michael at fritscher.net wrote:
> >> > Moin,
> >> >
> >> > kurz: klingt lecker :-) Danke fürs Ausprobieren!
> >> >
> >> > 2 Anmerkungen:
> >> >
> >> > 1. Die Umrüstung von mysql auf pqsql dürfte eigentlich recht
> >einfach
> >> > machbar sein, gerade beim v2 Keyxchange. Ist mir aber egal, wenn
> >die php
> >> > Variante auch gut funktioniert (scheint sie ja bisher).
> >> > 2. Was sagt die Performance? Du könntest ja mal Schaittach 100x auf
> >die
> >> > Karte klatschen, immer bissle verschoben, und gucken was passiert,
> >wenn
> >> > alle durchgeschaut werden. Wenn das max. 2-3 Sekunden dauert könnte
> >man
> >> > das durch einen Cache ablindern. Wir haben ja nur Größenordnung 5k
> >> > Router, also 5k unterschiedliche Koords, da könnte man die
> >> > Koord->Hoodzuordnung speichern. Der Cache würde dann halt bei
> >> > Hoodänderungen geleert werden.
> >> >
> >> > Grundsätzlich wäre ich klar für weiter ausprobieren :-)
> >>
> >> dein Wunsch war mir Befehl. Ich hab den keyxchange mal bei mir
> >> aufgesetzt und sowohl Cache nach diesem Beispiel:
> >> https://wiki.freifunk-
> >> franken.de/w/Hood_als_Polygon#Idee_mit_Cache_.28Christian.29
> >>  sowie die komplette Polygon Hood nach diesem Beispiel
> >> https://wiki.freifunk-
> >> franken.de/w/Hood_als_Polygon#Idee_mit_PHP_.28Christian.29
> >> integriert.
> >> Dazu ist aktuell der Debugmodus an, so das man auch "sieht" was
> >aktuell
> >> gerade passiert. Ausprobieren könnt ihr die Abfragen hier:
> >>
> >> http://fff-
> >>
> >jupiter.fff.community/keyxchange/VPNkeyXchange/index.php?lat=49.618443
> &
> >> long=11.327268
> >> (ohr könnt gerne mal verschiedene Koordinaten dagegen werfen)
> >>
> >> Als PolyHood hab ich mal eine Fakehood Schnaittach angelegt. Ich
> >glaube
> >> das ist der Bereich um Simmelsdorf der da abgebildet wird (NICHT
> >> Schnaittach selbst, aber ist ja jetzt eh nur zum probieren)
> >>
> >> Meinen Umbau hab ich mal bei mir ins git geworfen:
> >>
> >> https://github.com/ChristianDresel/VPNkeyXchange (Branch
> >keyxchangev2)
> >> die letzten 2 Patches (ich merk gerade wo ich mit der Mail fertig
> >bin,
> >> das die Datenbankstruktur noch fehlt, wer sie unbedingt sehen will
> >> einfach mal rufen, dann lad ich das irgendwo mit hoch)
> >>
> >> Eine Funktion fehlt noch, aktuell wird nur gegen eine PolyHood und
> >nicht
> >> gegen alle die es in der DB gibt geprüft (index.php Zeile 264 WHERE
> >> id='1' müsste man noch austauschen und durch alle IDs die es in der
> >db
> >> gibt prüfen), das muss noch eingebaut werden. Ansonsten ist es voll
> >> funktionsfähig.
> >>
> >> Aber so ganz grundsätzlich kann man sich jetzt mal überlegen ob man
> >das
> >> haben will oder nicht und man hat jetzt auch bisschen Code vor Augen.
> >>
> >> mfg
> >>
> >> Christian
> >>
> >> >
> >> > Viele Grüße und Danke,
> >> > Michael Fritscher
> >> >
> >> >
> >> >
> >> > Am 2018-09-19 11:52, schrieb Christian Dresel:
> >> >> hi
> >> >>
> >> >> um gegen ein System zu sein, sollte man ein System erstmal
> >verstehen.
> >> >> Bisher war ich dagegen, weil ich dachte es ist zu aufwendig. Aber
> >hey
> >> >> ich spiel doch gerne mit Technik und so hab ich mal bisschen
> >> >> herumprobiert.
> >> >> Mein Ergebniss möchte ich nun mal der Community vorstellen und
> >würde
> >> >> mich über bisschen Feedback (sowohl technisch als auch nicht
> >technisch)
> >> >> freuen.
> >> >>
> >> >> Ich hab Markus seine Anleitung erstmal soweit abgearbeitet das ich
> >eine
> >> >> GeoJson File von Schnaittach (und Simmelsdorf und noch irgendein
> >> >> Nachbarort den Markus genannt hat) lokal hatte, das sieht dann so
> >aus:
> >> >>
> >> >> http://fff-jupiter.fff.community/schnaittach.GeoJson
> >> >>
> >> >> Hier drinnen ist bereits für jeden Ort ein MultiPolygon (keine
> >Ahnung ob
> >> >> das der richtige Begriff ist, aber so wird es hier genannt)
> >enthalten.
> >> >>
> >> >> Nun ist der Punkt von Markus "Ist-in-Abfrage" allerdings nicht
> >ganz
> >> >> leicht umzusetzen, der keyxchange hat keine PostgreSQL und das
> >> >> nachzurüsten uff... Will ich mir eigentlich ersparen. Also hab ich
> >mal
> >> >> geguckt wie ich das in PHP (damit ist der keyxchange geschrieben)
> >> >> einfacher lösen kann. Ich bin dabei auf diese Funktion gestolpert:
> >> >>
> >> >> http://assemblysys.com/php-point-in-polygon-algorithm/
> >> >>
> >> >> Man muss jetzt aus der GeoJson natürlich ein Array erstellen, dies
> >hab
> >> >> ich erstmal händisch gemacht (das in ne Schönform zu bringen
> >sollte
> >> >> technisch kein Problem sein) mit dem Bereich Simmelsdorf, sieht
> >dann
> >> >> so aus:
> >> >>
> >> >> http://fff-jupiter.fff.community/poly/array.txt
> >> >>
> >> >> Danach hab ich noch 3 Koordinaten reingeklopft gegen die ich
> >testen will
> >> >> (später würde der Router hier seine Koordinaten hinschicken und
> >der
> >> >> keyxchange schaut in welchen MultiPolygon das liegt):
> >> >> 11.339509 49.559324
> >> >> 11 49
> >> >> 11.327267 49.618443
> >> >>
> >> >> Im moment sich lat/lon noch verdreht, da die MultiPolygon so
> >aufgebaut
> >> >> ist, hab ich erstmal damit gearbeitet. Das Ergebnis sieht dann so
> >aus:
> >> >>
> >> >> http://fff-jupiter.fff.community/poly/index.php
> >> >> (Sourcecode kann hier angeguckt werden:
> >> >> http://fff-jupiter.fff.community/poly/index.txt )
> >> >>
> >> >> Man sieht, die Funktion arbeitet auch mit Koordinanten korrekt,
> >die
> >> >> ersten 2 Koordinaten liegen eindeutig nicht im Bereich
> >Simmelsdorf, die
> >> >> 3. aber schon.
> >> >>
> >> >> So wie könnte man dies nun technisch in den keyxchange klopfen:
> >> >>
> >> >> Schritt 1) Der Knoten schickt seine Koordinaten an den keyxchange.
> >> >> Schritt 2) wir prüfen die Koordinaten gegen alle (ich nenn dieses
> >> >> Hoodsysten jetzt mal frech so) GeoJson-Hood. Passen die
> >Koordinaten des
> >> >> Knoten in eine dieser vorhandenen GeoJson-Hoods, wird diese Hood
> >an den
> >> >> Knoten zurückgegeben und er konfiguriert sich auf diese Hood falls
> >sie
> >> >> in keine GeoJson-Hood passen, machen wir mir Schritt 3 weiter
> >ansonsten
> >> >> endet hier der Ablauf bereits
> >> >> Schritt 3) wir prüfen wie jetzt auch schon, zu welcher voronoi
> >Hood der
> >> >> Knoten gehört und geben ihn diese Hood zurück.
> >> >>
> >> >> Bisher arbeitet der Keyxchange nur mit Schritt 1 und 3, man würde
> >also
> >> >> einen Schritt 2 "dazwischen" schieben.
> >> >>
> >> >> Vorteile:
> >> >> - Wer GeoJson verwenden will, kann dies tun. Wer es nicht tun will
> >> >> bleibt einfach bei den alten voronoi System, es ist die freie
> >> >> Entscheidung jedermann (und das ist mir persönlich sehr wichtig)
> >> >> - Das GeoJson System liegt "über" den voronoi System. Somit werden
> >Hoods
> >> >> die aktuell nach voronoi arbeiten absolut nicht beeinflusst sofern
> >"da
> >> >> drinnen" niemand eine Geo-Json Hood anlegt. Die Systeme können
> >also
> >> >> wunderbar pararell agieren
> >> >>
> >> >> Nachteil:
> >> >> - Das Zeug muss man erstmal umsetzen
> >> >> - Der Wartungsaufwand vom keychange steigt etwas an, man muss auf
> >noch
> >> >> mehr Sachen acht geben
> >> >>
> >> >> So Meinungen? Was meint ihr? Umsetzbar? Sollen wir es probieren?
> >Hab ich
> >> >> Dinge übersehen?
> >> >>
> >> >> mfg
> >> >>
> >> >> Christian
> >> >>
> >> >> On 06.09.2018 09:46, fff at mm.franken.de wrote:
> >> >>> Moin Michael,
> >> >>>
> >> >>>>> Markus, wir können uns da gerne mal (virtuell oder
> >physikalisch)
> >> >>>>> zamhocken und da was zusammenbrauen ;-)
> >> >>>
> >> >>> Habe mal etwas Doku zusammengetragen:
> >> >>> https://wiki.freifunk-franken.de/w/Hood_nach_Gemeinden
> >> >>>
> >> >>> Vielleicht hilft das Dir und anderen Hood-Profis ja ein bisschen?
> >> >>>
> >> >>> Rückfragen gern per Mail oder telefonisch.
> >> >>>
> >> >>> Mit herzlichem Gruss,
> >> >>> Markus
> >> >>>




Mehr Informationen über die Mailingliste franken