On Tue, Sep 25, 2007 at 11:28:30AM +0200, Frederik Ramm wrote:
Das Planet-File ist derzeit 16 GB gross (unkomprimiert als XML, aber die MySQL-interne Darstellung wird sicherlich auch ihre 2 GB brauchen) und es wird, wenn der TIGER- Import amgeschlossen ist, um die 200 GB haben.OK, also sollte kurz- bis mittelfristig ne Lösung her. Bereits mit dem aktuellen Dump komme ich auf meinem Server so langsam in Platznot. Könnte zwar noch was basteln, daß aus der vollen Datei nur DE importiert wird, aber ne Aufteilung in 10°-Häppchen (=> ~650 Dateien) fände ich beim Datenbank-Dump (Planet-File) sinnvoll.
Zur Aktualisierung finde ich Deine Idee sehr gut. Ich stelle mir da vor, daß der API-Server von jeder Transaktion (0.5 kann doch Transaktionen/Changesets, oder?) ein Diff (ähnlich den Diffs zum Planet-File) erstellt, signiert und zum Verteilen weiterreicht. Das Diff wird entsprechend der enthaltenen Änderungen (Bereich) an verschiedene (meist nur einer) "Kanäle" geschickt. Diese werden dann unverändert an alle, die den entsprechenden Kanal "bestellt" haben, weitergereicht. So ähnlich (allerdings ohne Sigs) haben wir das damals im Fido mit der NodeList (Liste aller direkt per Modem erreichbaren Teilnehmer) auch gemacht. Man hat sich einmal die volle NodeList (hier: Planet-File, ggf. nur ein Auszug daraus) geholt und dann wöchentlich das NodeDiff darauf angewendet, um die aktuelle Version zu bekommen. Die NodeDiffs wurden per FileTicker an alle Nodes verteilt. Üblicherweise wurden mehrere Diffs vorgehalten (die man dann per File-Request explizit runterladen konnte), man konnte also auch mit einer etwas älteren NodeList auf den aktuellen Stand kommen.
Für OSM würde ich der Einfachheit halber das erstmal grob so implementieren (Verbesserungen kann man später einführen, wenn man sieht, wo genau es Probleme gibt): - signieren mit PGP (bei kleinem Keyring geht das ausreichend schnell), detached signature - API reicht Änderungen in Rohform an einen Daemon, der daraus ein Diff erstellt und signiert per Mail verschickt - Diff und Sig als Mail-Attachment an eine Mailingliste verschicken (1 Liste pro 10°-Block) - jedes Diff enthält die ID (Timestamp?) des alten und des neuen Zustands - Verteilung an alle "betroffenen" Kanäle, erst der Empfänger verwirft die für ihn uninteressanten Änderungen - Dumps (Planet-File) enthalten ebenfalls die ID des Zustandes, den sie enthalten - Anbieten von bis zu 2 Wochen alten Diffs zum Download per HTTP (um mit letztem Dump bis zum aktuellen Zustand zu kommen)
Die Verteilstruktur selbst braucht damit nur die Diffs weiterreichen und nicht den Datenbankinhalt selbst speichern. Basierend darauf können dann verschiedene Datenbankserver für die unterschiedlichsten Zwecke und ggf. mit nur einem Subset der Daten aufgesetzt werden. Durch die PGP-Signatur des API-Servers erhält jeder Datenbankserver garantiert die Originaldaten. Der zentrale API-Server bräuchte dann nur noch Änderungen entgegennehmen, alle ReadOnly-Zugriffe gehen auf die anderen Server. Die API ist ja sinnvollerweise zustandslos, d.h. Lese- und Schreibzugriff können auf verschiedenen Servern (mit ggf. leicht veralteten Daten) erfolgen.
EMails haben hier den Vorteil, daß wir eine vorhandene und i.d.R. zuverlässige (Achtung: SPAM-Filter!) Store&Forward-Infrastruktur (genau das brauchen wir hier) nutzen können. Auch die Verteilfunktion an verschiedene "Kanäle" ist - Stichwort: Mailinglisten - erprobt und erfolgt (bei Einsatz passendere Software) vollautomatisch, incl. Runterschmeissen bei Unzustellbarkeit. Das hält den Wartungsaufwand in Grenzen.
Damit würde sich die Aufgabe in 6 Stücke teilen lassen:1. Änderung der API, so daß die Änderungen an den Diff-Daemon weitergereicht werden 2. Schreiben eines Daemons, der die Änderungen im Rohformat entgegennimmt und daraus eine PGP/MIME-Mail erzeugt und (per /usr/lib/sendmail) an den lokalen MTA weiterreicht. Empfängeradresse ist <prefix>-<tileID>@<domain> (z.B. [EMAIL PROTECTED]) 3. Aufsetzen der entsprechenden Mailinglisten (auf einem anderen Server als dem API-Server) 4. Schreiben eines Tools, das die per EMail gelieferten Diffs auf Gültigkeit prüft (PGP-Sig, ID), ggf. zwischenspeichert (Reihenfolge-Änderungen sind bei EMail möglich) und auf die Datenbank anwendet. 5. Finden (oder notfalls Schreiben) eines Tools, das Diffs in ein Verzeichnis zum Download stellt. Löschen täglich per cron-Job (find -mtime|xargs rm). 6. Ändern (oder Neuschreiben) des Tools, das die Planet-Files erstellt (Aufteilen in 10°-Blöcke).
Sobald man sich auf ein Format für die Diffs geeinigt hat, können diese Aufgaben von unterschiedlichen Personen erledigt werden.
Feinere Aufteilungen (1° => ~64k Tiles) können später bei Bedarf relativ einfach eingeführt werden (Diff-Format muss natürlich Versionsangabe enthalten). Änderungen, die große Bereiche (hier > 1°) betreffen, dürften so selten sein, daß die mehrfache Verteilung dieser Diffs keine Rolle spielt (die IDs verhindern die mehrfache Anwendung des Diffs, durch die Seltenheit ist der erhöhte Traffic egal).
CU Sascha -- http://sascha.silbe.org/
pgpt8Ula0i9LO.pgp
Description: PGP signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
