[Talk-de] ?Unterstützung für die(?) Server

[AK-Palme]

Hi Frederick,

> Willkommen bei OSM ,-)
>   
Danke :)
>> Wenn ich mich für ein Szenario entscheiden müsste, würde ich, ohne die 
>> finanzielle Lage zu kennen, ein 5-Server-Cluster empfehlen. Dabei gibt 
>> es 2 Frontend-Server, auf denen der Webserver läuft, und 2 
>> Backend-Server die die Datenbank beherbergen.
>>     
>
> Fileserver und NFS brauchen wir vermutlich (an dieser Stelle) nicht;
> es gibt naemlich praktisch keinen statischen Content, der ausgeliefert
> wird. 
Wie schon gesagt, ich kenne mich mit der aktuellen Infrastruktur nicht 
aus, aber ich dachte bei der rsync-Syncronisation an die Scripte die die 
Tiles, etc. generieren. Klar, Fileserver ist oversized für 20 
PHP-Dateien aber ich habe ihn der Anschaulichkeit angeführt.

> Bevor man anfaengt, sich irgendwelche Replikations-Szenarien
> auszudenken, muss man erstmal schauen, was wir eigentlich haben, was
> wir wollen, und wo das Problem ist.
>   
ACK
> Klar, das Problem ist, dass derzeit alles (alle Datenbank-Lese- und
> Schreib-Requests) ueber einen Server laufen. Das macht nicht nur
> unnoetig viel Last, sondern das gibt auch zuweilen im MySQL-Server
> einfach Haenger wegen des Locking (ein Prozess macht einen dicken
> SELECT, der 2 Minuten dauert, macht derweil ein Write-Lock, so dass
> andere zwar lesen, aber nicht schreiben duerfen; ein zweiter Prozess
> kommt und will schreiben, darf nicht, haengt in der Warteschlange; ein
> dritter Prozess kommt und will eigentlich nur lesen, darf aber nun
> auch nicht, weil der zweite Prozess erster war und schon einen
> Lock-Request eingequeuet hat).
>   
Wäre es nicht möglich den Write-Lock zu umgehen, indem man die 
Write-Requests in einem temporärem Table erledigt? Nagut, ich kenne das 
System nicht -> gefährliches Halbwissen :)
Sehe ich richtig, dass es das Ziel sein sollte, die Write-Querys zu 
verkürzen/teiles um das Locking effektiver zu machen? Man könnte, wenn 
man einen MySQL-Cluster nutzt das Ziel mit LOW_PRIORITY-Updates machen. 
Wenn man dann noch wenige und effektive B-Trees in der Indexierung nutzt 
würde das sicher viel Wirkung zeigen. Oder wird das schon gemacht?
> Ein sehr grosser Teil unserer Anfragen sind Lese-Requests. Die haben
> wir im Moment schon stark eingeschraenkt - man kann nicht mal mehr
> eine ganze deutsche Grossstadt auf einmal abrufen, weil so grosse
> Requests nicht erlaubt sind. Das ist nur ein Notanker - eigentlich
> waere es schoen, wenn jeder alles requesten darf, was ihn interessiert. 
>
> Wir haben, damit sich keiner zu arg aergern muss, das "planet file",
> einen Komplett-Dump aller Daten, der woechtenlich rauskommt. Jeder,
> der mit eine Woche alten Daten zufrieden ist, kann damit arbeiten
> (obwohl das auch zunehmend unhandlicher wird - eine Datenbank ist
> schon komfortabler als ein Riesenfile).
>   
Statt planet-File könnte man im Grunde doch durch ein Planet-Table 
ersetzen? Das würde das Caching und die Performace der Datenbank nutzen. 
Oder sehe ich das falsch, dass das Planet-File eine Art "SELECT * FROM 
alle_tabellen" ist?!
> Das "planet file" wird demnaechst vermutlich auch haeufiger kommen,
> oder es wird zumindest taegliche Updates dafuer geben, so dass es
> leichter ist, einigermassen aktuell zu blieben. Aber es ist und bleibt
> (finde ich) eine Kruecke.
>
> Ich skizziere mal eine Idee, die ich schon ewig mit mir rumtrage und
> bei jeder Gelegenheit wieder mal auf den Tisch bringe:
>
> Ich finde einen zentralen Server fuer alle Schreibrequests, einen
> zentralen "Master", ok. (Man *koennte* durchaus auch partitionieren -
> der Master fuer Deutschland koennte in Deutschland stehen, und
> grenzueberschreitende Requests waeren dann durch geeignete Metaserver
> zusammenzusammeln. Hat auch viele Vorteile. Aber nehmen wir erstmal
> an, wir haben einen zentralen Server.)
>
> Dieser zentrale Master hat einen Slave, auf den er alle Aenderungen
> in Quasi-Echtzeit kopiert. Alle Lese-Requests sind von diesem Slave zu
> machen. Der Slave wiederum akzeptiert eine begrenzte Anzahl von
> "Feeds". Ein Feed ist eine weitere Datenbank am Ende irgendeiner
> Leitung, die alle Updates oder nur bestimmte Updates geliefert
> bekommt. Ein Feed, der alle Updates bekommt, ist ein "full feed"; ein
> Feed koennte aber auch sagen: "Ich will nur alles, was in dieser und
> jener Bounding box liegt" (ein regionaler Feed), oder thematisch "ich
> will nur alles, was railway=irgendwas ist". 
>
> Diese Feeds koennen wiederum kaskadiert werden - wer in vor-IP-Zeiten
> Usenet gemacht hat, kann sich das vielleicht besser vorstellen: Nicht
> jeder kann einen Full-Feed von der Zentrale bekommen, aber es koennte
> einen Full-Feed irgendwo in Deutschland geben, an dem wiederum 10
> unter-Feeds dranhaengen, und so weiter. Durch die entstehende
> Baumstruktur "troepfeln" dann Aenderungen mehr oder weniger schnell
> nach unten durch; letzten Endes kann jeder, ueberall auf der Welt,
> einen stets aktuellen OSM-Bestand von allem haben, was ihn
> interessiert.
>
> Wenn man nun mit JOSM oder so etwas aendert, kann man sich problemlos
> die Daten von einem halbwegs aktuellen Feed laden: Wir unterstuetzen
> ja eh keine transaktionalen Updates, d.h. selbst wenn ich mit JOSM
> direkt vom zentralen Server etwas lade und daran Aenderungen vornehme,
> kann es immer sein, dass mir jemand anders in die Quere kommt. Ob ich
> nun 10 Minuten alte Daten lade und daran eine halbe Stunde
> herumbastele oder ob meine Daten 10 Millisekunden alt sind, macht
> keinen Unterschied.
>
> Eine solche Architektur waere extrem leistungsfaehig und beliebig
> skalierbar. Superflexibel obendrein - denn Feeds muessten ja nicht
> alle die OSM-Software fahren, jemand kann durchaus auch direkt in eine
> Postgres-Datenbank hineinfeeden oder irgendwas anderes. 
>
> Eine solche Architektur koennte allerdings nicht auf MySQL-Replikation
> aufgesetzt werden, sondern muesste eine Abstraktionsstufe weiter oben
> stattfinden, im API: In dem Moment, in dem die Aenderung geschrieben
> wird, muss praktisch eine Aenderungs-Message generiert werden, die
> dann ueber die Architektur verteilt werden kann. (Notfalls ginge das
> mit Triggern, aber da alle Aenderungen eh ueber die API geschehen,
> waere die API der bessere Punkt.)
>
> Die Feeds koennten entweder ueber offene Verbindungen direkt vom
> Server benachrichtigt werden, wenn sich was aendert, oder, was weniger
> effizient, aber auch weniger fehleranfaellig waere, einfach
> regelmaessig pollen: "Gib mir alle Changes der letzten Minute fuer die
> Bounding Box ...".
>   
Die Idee finde ich gut, aber sie ist doch extrem hoch skaliert. Als 
Unterscheidungsmerkmal könnte man den Baum sowie den DNS-Baum aufbauen. 
Wobei dann jeder Server für einen bestimmten Koordinatenbereich 
zuständig ist. Das würde auch das Problem lösen wie die Daten aktuell 
bleiben.

Zur Verdeutlichung:
Hamburg:    53° 34' N, 10° 1' O
                     053034N 010001O
Server-Anfrage geht an z.b. 053034.nodes.osm.com, der dann für den 
gesamten Breitengrad verantwortlich ist.
Zukunfsmusik :)

> Soviel mal dazu. Aber bis wir sowas kriegen, wird noch viel Wasser die
> Themse runterfliessen ;-)
>
> Bye
> Frederik
>
>   
Gute Nacht,
Christian