Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am Montag 06 September 2010, 22:27:51 glaubte Josias Polchau zu wissen: gerade webspace ist extrem begrenzt. kann also nur wen überhaupt ein land abdecken. Ich glaub nicht, daß es bei dem üblicherweise erhältlichen Webspace gelingen wird eine XAPI aufzusetzen. Spätestens die oft vorhandene Laufzeitbegrenzung von Scripten dürfte eine Abfrage mittendrin wegschießen. Von wenig Platz und begrenztem Traffic brauchen wir eigentlich gar nicht mehr reden. Ich hab z.B. Webspace mit 150GB Traffic im Monat, für eine private Seite wahnsinnig viel, für Openstreetmap ist das *sehr* wenig. Selbst ein V- Server dürfte eher eine schlechte Idee für sowas sein. Es wird auf einen echten (Root-, Managed- oder Colo-) Server hinauslaufen, aber selbst da kann der Traffic eng werden. Meine Idee wäre, eine Handvoll (oder zwei oder auch noch mehr) Root- Server zu haben, zwischen denen die Anfragen aufgeteilt werden, von denen jeder die komplette Datenbank hat. Die sollten dann doch auch deutlich schwächer ausfallen dürfen als einer oder zwei Server die alles abbekommen. Ich liebäugle gerade mit einem Root- Server[1], den ich zu großen Teilen nicht ausnutzen werde, da hätt ich kein Problem damit, da den Rest für eine XAPI zur Verfügung zu stellen. Im Auge hätt ich grad eine Maschine mit einem Athlon 64 X2, 2GB RAM, 2*400GB RAID1 und 2TB Traffic im Monat. Für nen 10er mehr könnt ich die selbe Austattung mit 4GB RAM haben, das wärs mir wert. Mit einer Handvoll von solchen Servern dürfte man doch einiges reißen können, oder? Die Anfragen müßten halt über einen Verteiler laufen, der u.a. dafür sorgt, daß da nicht zu viel Traffic bei einem Server anfällt, aber das sollte sch IMO in den Griff bekommen lassen. Any Komments? [1] mein Webspace bietet mir ausreichend Platz für meine Zwecke, Traffic würde auch ewig reichen, aber ich brauch langsam mehr Zugriff auf Ebenen, auf die ich bei Webspace nicht zugreifen kann/darf flo -- Klaus, Du erkennst Ironie selbst dann nicht, wenn sie Dich wuergt. [Frank Toennes in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am 7. September 2010 15:23 schrieb Florian Lohoff f...@zz.de: Auf vernuenftiger hardware (16GB Ram, 8 Cores, 500GB Platte in 14 Spindles) brauche fuer einen osmosis/postgis import 3 Tage ... hast Du mal versucht, den RAM zu erhöhen, z.B. auf 64GB? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
On 2010-09-07 15:50, M∡rtin Koppenhoefer wrote: Am 7. September 2010 15:23 schrieb Florian Lohofff...@zz.de: Auf vernuenftiger hardware (16GB Ram, 8 Cores, 500GB Platte in 14 Spindles) brauche fuer einen osmosis/postgis import3 Tage ... hast Du mal versucht, den RAM zu erhöhen, z.B. auf 64GB? Warum braucht das überhaupt so viel Arbeitsspeicher beim befüllen? Wird der Index wärend dem Einspielen gleich erzeugt? Das XML parsen braucht praktisch keinen Arbeitsspeicher und SQL hat es auf dem 386 mit 2 MByte Speicher auch schon gegeben. lg,Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am 05.09.2010 22:29, schrieb Stephan Knauss: 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? Die benötigte Festplattenkapazität ligt jenseits der 500GB und schnelle Platten sind ein Muss. Damit fallen die meisten Web-Hosts weg. Anforderungen wären: - läuft out of the box auf möglichst vielen Hosting-Angeboten. Also wohl PHP+MySQL Mit MySQL wirst du bei OSM-Daten nicht weit kommen, nicht umsonst hat osm.org mit der API 0.6 von MySQL auf Postgres gewechselt. Ich würde mich allein wegen der nötigen Festplattenkapazität von der Möglichkeit verabschieden, günstige Webhoster für Anwendungen rund um OSM zu verwenden. Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
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 Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Als witeres KO kriterium sehe ich die Aktualität. eine XAPI sollte offt geupdated werden, aber chronejobs sind nur selten bei webhostern dabei. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
On 06.09.2010 21:16, Josias Polchau wrote: Als witeres KO kriterium sehe ich die Aktualität. eine XAPI sollte offt geupdated werden, aber chronejobs sind nur selten bei webhostern dabei. Da könnte man aber tricksen, indem die Clients sich gegenseitig anpingen und Updates anstoßen lassen. :D Müsste man mal genauer durchrechnen, halte ich aber für möglich, um zumindestens einige dieser KO-Spaces wieder ins Boot zu kriegen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am 06.09.2010 11:26, schrieb Peter Wendorff: 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. das ist sehr viel verwalltungsaufwand. die Übergeordnete einheit müsste wissen, wer welche BBox abdeckt. gerade webspace ist extrem begrenzt. kann also nur wen überhaupt ein land abdecken. Man kann sehr viel verteilt implementieren. doch braucht es dafür ein gutes protokoll. ich bin für eine Lösung ähnlich der jetzigen XAPI: es gibt mehrere Server und der Verteiler verteilt die Anfragen je nach Last ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am 03.09.2010 18:06, schrieb Sven Geggus: Wenn ich das richtig verstanden habe ist dei XAPI in einer Programmiersprache geschrieben, die außer dem Author der XAPI niemand spricht. Genau das ist das Problem. Wie wäre es die XAPI in einer modernen, für Webanwendungen geeigneten Programmiersprache neu zuschreiben. Ich hatte mir dazu noch einige Gedanken gemacht, habe aber nicht genug Zeit so etwas allein zu entwickeln. Deshalb hab ich mal ein Projekt auf Sourceforge erstellt, dem jeder gerne beitreten kann. https://sourceforge.net/projects/xapi/ Hier ein paar Sachen die geklärt werden müssen. Datenbank: Ich bin aus eigener Erfahrung für Postgres/Postgis. es ist sehr schnell auch mit großen Datenmengen Für MySQL würde sprechen, dass es von vielen Webhostern unterstützt wird. Auf normalem Webspace kann man es derzeit sowieso nicht aufbauen. man brauch mehr als 5 GB Speicherplatz. eine Boundingbox ohne spezielle Funktion dauert auf diesen Datengrößen einfach zu lange Programmiersprache: Java: für Java würde Sprechen, dass so ziemlich jeder der programmieren kann auch Java kann bzw es leicht zu erlernen und die Entwicklungsumgebungen ausgereift sind. Python für Python würde sprechen dass es von Vielen Webhostern unterstützt wird. Aber wie oben schon oben gesagt braucht man so wieso einen guten Server dafür. Hat jemand andere Vorschläge oder Argumente? immer her damit. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
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. Einen Grund, den großen Speicherbedarf, hast Du bereits genannt, Zugriffszahlen und Traffic dürften im späteren Betrieb bei vernünftiger Performance ebenfalls nicht ohne sein. Damit ist auch das MySQL-Argument (Unterstützung von Webhostern) raus. Außerdem ist AFAIK postgres/postgis sonst weit verbreitet in der toolchain der OSM, und wird, wenn auch nicht als optimal, doch als das beste aller verfügbaren Systeme gesehen. Gruß Peter On 05.09.2010 18:38, Josias Polchau wrote: Am 03.09.2010 18:06, schrieb Sven Geggus: Wenn ich das richtig verstanden habe ist dei XAPI in einer Programmiersprache geschrieben, die außer dem Author der XAPI niemand spricht. Genau das ist das Problem. Wie wäre es die XAPI in einer modernen, für Webanwendungen geeigneten Programmiersprache neu zuschreiben. Ich hatte mir dazu noch einige Gedanken gemacht, habe aber nicht genug Zeit so etwas allein zu entwickeln. Deshalb hab ich mal ein Projekt auf Sourceforge erstellt, dem jeder gerne beitreten kann. https://sourceforge.net/projects/xapi/ Hier ein paar Sachen die geklärt werden müssen. Datenbank: Ich bin aus eigener Erfahrung für Postgres/Postgis. es ist sehr schnell auch mit großen Datenmengen Für MySQL würde sprechen, dass es von vielen Webhostern unterstützt wird. Auf normalem Webspace kann man es derzeit sowieso nicht aufbauen. man brauch mehr als 5 GB Speicherplatz. eine Boundingbox ohne spezielle Funktion dauert auf diesen Datengrößen einfach zu lange Programmiersprache: Java: für Java würde Sprechen, dass so ziemlich jeder der programmieren kann auch Java kann bzw es leicht zu erlernen und die Entwicklungsumgebungen ausgereift sind. Python für Python würde sprechen dass es von Vielen Webhostern unterstützt wird. Aber wie oben schon oben gesagt braucht man so wieso einen guten Server dafür. Hat jemand andere Vorschläge oder Argumente? immer her damit. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
hi Datenbank: Ich bin aus eigener Erfahrung für Postgres/Postgis. es ist sehr schnell auch mit großen Datenmengen Für MySQL würde sprechen, dass es von vielen Webhostern unterstützt wird. Auf normalem Webspace kann man es derzeit sowieso nicht aufbauen. man brauch mehr als 5 GB Speicherplatz. eine Boundingbox ohne spezielle Funktion dauert auf diesen Datengrößen einfach zu lange Meine Wünsche wären: XAPI soll auf allen Plattformen funktionieren: High End Server, Laptop, Handy Wenn mehr Ram vorhanden ist, dann rennt es natürlich schneller als mit wenig Arbeitsspeicher. Die XAPI wird immer ein bischen hinterherhinken und nie auf die Sekunde aktuell sein. Mir wäre es wichtig, dass dieses System gleich nach dem download einsatzbereit ist und nicht mehrere Tage braucht um in die DB gespielt zu werden. Wenn das Update nur einmal am Tag oder einmal pro Monat auf meine eigene XAPI kommt ist das ok. Das ganze läuft darauf hinaus, dass keine DB verwendet wird sondern ein eigenes Fileformat entwickelt wird. Soweit ich das abschätzen kann, wäre so etwas möglich. Programmiersprache: Java: für Java würde Sprechen, dass so ziemlich jeder der programmieren kann auch Java kann bzw es leicht zu erlernen und die Entwicklungsumgebungen ausgereift sind. Python für Python würde sprechen dass es von Vielen Webhostern unterstützt wird. Aber wie oben schon oben gesagt braucht man so wieso einen guten Server dafür. Hat jemand andere Vorschläge oder Argumente? immer her damit. MySQL und Java finde ich im Moment nicht so toll weil mir Oracle nicht ganz geheuer ist. lg, Bernhrd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
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. 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. Vielleicht wäre auch eine Unterteilung in Art der TRAPI eine gute Idee. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
