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

[Frederik Ramm]

Hallo,

> ich möchte mich kurz vorstellen: Ich heisse Christian und bin der, auf 
> den fuesika vor einigen Tagen angespielt hat, also der, der den Server 
> administriert.

Willkommen bei OSM ,-)

> 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. 

Den gibt es an anderer Stelle - bei den Tile-Webservern (der
dev-Server fuer tiles at home und der "tile"-Server fuer Mapnik), aber
das laeuft ganz separat von der Datenbank.

Bevor man anfaengt, sich irgendwelche Replikations-Szenarien
auszudenken, muss man erstmal schauen, was wir eigentlich haben, was
wir wollen, und wo das Problem ist.

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).

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).

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 ...".

Soviel mal dazu. Aber bis wir sowas kriegen, wird noch viel Wasser die
Themse runterfliessen ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'