FW: Hood-Bildung - Gemeindegrenzen

Fr Sep 21 14:17:23 CEST 2018

Moin,

zu Deadlocks kann es eigentlich nur kommen, wenn innerhalb einer Transaction gelesen und geschrieben wird. Wenn die einzelnen Queries unabhängig sind darf es zu keinen Deadlocks kommen. Eventuell fasst der PDO Treiber alle Queries eines php-scriptes zu einer Transaktion zusammen? Da könnte Autocommit helfen (oder wie das  bei PDO auch immer heißt) - dann wird nach jedem Query automatisch commitet (bzw. jedes Query als eigene Transaktion betrachtet). Subqueries und sowas sollten vom db-scheduler auch ohne deadlocks abgearbeitet werden können.

Zu den Floats: DIe Ungenauigkeiten kommen nur beim Rechnen, bzw. dem genauen Vergleich zw. errechneten und Konstanten. Da wir aber entweder größer/kleiner Operationen haben ("Ist er in der Hood?") oder konstanten vergleichen (im cache, "hab ich das. was von einem Router  bekommen habe. schonmal von einem Router gesehen") sehe ich da keine Probleme. Und im cache ist das schlimmste, was passieren kann, dass da 2 eigentlich gleiche Koords drinne sind - verschmerzbar.

Zu Dezimal: Das ist ein int, nur dass da noch eine feste Kommaverschiebung mit drin ist. Damit ist also weiterhin genaues Rechnen möglich. ERspart einem das *100000 bzw. /100000 Gerechne, wenn man es als int speichert ;)

Archive ist eigentlich nur bei Updates bäh. Wie gesagt, ich weiß nur nicht, was die Indexes können.
Ja, memory sollte nur für den Cache verwendet werden ;)

Viele Grüße,
Michael Fritscher

Am 21. September 2018 12:38:28 MESZ schrieb Adrian Schmutzler <mail at adrianschmutzler.de>:
>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
>> >> >>>