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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ## N49°00.09' E008°23.33' _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
