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

[Sascha Silbe]

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. diff-0815 at diffs.openstreetmap.org)
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/

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 198 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20070925/0cc9514a/attachment.sig>