On 05.09.2010 22:29, Stephan Knauss wrote:
Peter Wendorff wrote:
Das Argument der Webhost-Unterstützung würde ich ablehnen, das ist
vermutlich sowieso keine vernünftige Alternative - es sei denn, man
möchte direkt eine verteilte Lösung angehen.
Mal ein paar Idden dazu.
Verteilte Lösung klingt doch gut. Für Abfragen die eine bbox haben
lässt sich das wohl recht einfach realisieren.
t...@h hatten einige mitgemacht, was spricht gegen x...@home? Muss ja
nicht unbedingt am DSL-Anschluss sein, aber wenn es einige Dutzend
Webhosts gibt?
Anforderungen wären:
- läuft "out of the box" auf möglichst vielen Hosting-Angeboten. Also
wohl PHP+MySQL
- Man kann einstellen wie viel Storage und Traffic der Host bereitstellt
- Anwendung meldet regelmäßig an zentralen Dispatcher den Status (DB
Aktualisierungsdatum, Last, Traffic)
- aktualisiert die Daten seiner Boundig-boxen automatisch. Eventuell
kann das ja von einem zentralen Server weggespielgelt werden, so dass
nur die Abfragelast auf die verteilten Rechner trifft, nicht das
direkte aktualisieren.
Zwei Gedanken dazu:
1) es wäre gut, wenn man eine "bevorzugte Boundingbox" angeben kann für
den eigenen XAPI-Node. Als Hintergrund sehe ich dabei Die Server, die
XAPI-ähnliche Abfragen regelmäßig selbst auf einer begrenzten BBox
anfordern. Also z.B. ein lokaler Stadtplan: XAPI als Komponente
einbinden, die Aktualisierung selbstständig vornimmt, nebenbei anderen
die Schnittstelle bereitstellen, und bei lokalen Abfragen für die eigene
Anwendung Traffic sparen.
2) Die Aufteilung nach BBox ist die eine, andere Anfragen wären aber
auch denkbar, und sollten vielleicht ebenfalls berücksichtigt werden.
Ich denke da vor allem an BBox-Unabhängige Tag-Abfragen: alle
Kondomautomaten weltweit, alle Bäume oder sowas. Hier ist die Aufteilung
in BBoxen möglicherweise nicht so ideal; vielleicht sollte deshalb ein
zusätzliches Index-System implementiert werden, so dass es Nodes gibt,
die für bestimmte Tags Abfragen cachen oder berechnen.
Zentraler Dispatcher teilt den Hosts bounding-boxen zu die in etwa dem
konfigurierten Storage entsprechen.
Eingehende Anfragen werden an einen passenden Host weitergeleitet
Hosts die veraltete Daten haben, zu hohe Last oder zu viel Traffic
bekommen keine Anfragen mehr.
Wenn die XAPI-Komponente selbst für das Update sorgt, wäre es quasi
unmöglich, veraltete Daten zu besitzen.
Man könnte auch über eine P2P-Lösung nachdenken, die den zentralen
Dispatcher nur noch als Schnittstelle für die Anfragevermittlung braucht.
Dispatcher: Eingangs-URL für XAPI-Anfragen, leitet weiter an zufälligen
oder möglichst passenden Peer.
Peers: Arbeiten die XAPI-Anfrage ab, oder leiten an vermutlich
passenderen Peer weiter. Auch die Anforderung von Teilergebnissen von
anderen Peers ist möglich. Peers können sich wegen Traffic-Auslastung
stufenweise abmelden: keine Query-Anfragen mehr, weder Queries noch
Updates, nichtmal mehr P2P-Netzstatus-Informationen
Der Dispatcher wäre dabei im Grunde genommen lediglich ein Peer, der
möglicherweise keinen eigenen Speicherplatz bereitstellt; insbesondere
wären aber auch Clients als Dispatcher denkbar. Wenn ich also lokal bei
mir im Server einen Peer laufen lasse, kann ich den mit der deshalb
bekannten URL als Dispatcher nutzen, was hoffentlich Traffic und
Geschwindigkeit optimiert.
Gruß
Peter
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
