[Talk-de] XAPI Neubauen WAS:Re: XAPI ständig tot

[Peter Wendorff]

  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 at H hatten einige mitgemacht, was spricht gegen xapi at 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