Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
Am 07.09.2010 12:03, schrieb Peter Wendorff: P2P-Tauschbörsen technisch anguckst, tauschen die vor allem auch Quellen miteinander aus - also: welche IPs sind sonst noch aktiv? Welche Daten sind auf diesen Rechnern vorhanden? Bei den meisten P"P Netzen hast du aber relativ statische Daten. Bei uns stellt sich nicht nur die Frage "Wer hat welche BBox" und die Herausforderung, die Antworten von mehreren Peers wieder zusammen zu einer großen BBox bauen. Zusätzlich muss nämlich auch noch geprüft werden, welcher Peer welchen Lag ggü. der Haupt-Datenbank hat. Stell dir vor, der dispatcher erhält eine Anfrage für eine Weltweite Suche nach Autobahnen. Er muss dann 20 Peers ansprechen, die gemeinsam eine komplette Planet-DB haben. Wenn jetzt einer aber 15 Minuten hinter den anderen Peers, liefert daher also zu den anderen Peers inkompatible Daten. Der Dispatcher muss also jederzeit wissen, welcher Peer welche Daten hält und wie alt diese sind. Ich denke auch nicht, dass das Unmöglich ist, halte nur den Aufwand ggü. dem Nutzen für zu groß. Konkret bedeutet das, dass die erwartete Anzahl an Peers aufgrund der Voraussetzungen die ein solcher Peer an die Maschine stellt so gering ist, dass der Dienst viele Anfragen a) gar nicht oder b) nur langsam beantworten kann, da Peers für bestimmte BBoxen ganz fehlen, zu alt oder zu ausgelastet sind. Ich könnte mit ein solches System gut für Regionale suchen vorstellen, ähnlich organisiert wie pool.ntp.org, nicht aber für eine XAPI, die ebenso lokale wie auch weltweite Anfragen bearbeiten können soll. Hier wäre meiner Meinung nach ein Rewrite sinnvoller. Aufgrund der Skalierbarkeit würde sich Erlang [1] anbieten und aufgrund der eignung für GIS-Themen PostGIS. Es kann aber sinnvoll sein, nicht Erlang zu verwenden, um eine größere Maintainer-Basis zu erlauben. In diesem Fall würde sich Ruby+Rails anbieten, da in diesem Fall eine Reihe von Erfahrungen und Manpower, die sich um den Rails-Port gebildet haben, mit nutzen lässt. Lg, Peter [1] http://chaosradio.ccc.de/cre082.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
Am Dienstag 07 September 2010, 12:03:22 glaubte Peter Wendorff zu wissen: > Genaueres müsste ich nachlesen - aber machbar ist da jedenfalls mehr und > schneller, als du das grade skizzierst. > > P.S.: Ich hab nicht gesagt, dass das einfach ist ;) Da ich mich mit sowas nicht wirklich auskenne werf ich halt mal meine Gedanken in den Raum und hoffe dabei was lernen zu können. :-) flo -- Wir Aliens wir müssen doch auf euch arme Menschlein aufpassen. Sonst macht Ich noch den grossen Blubb mit euerer Welt. [WoKo 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ändi g tot
On 07.09.2010 10:00, Florian Gross wrote: Un wie schon im Chat erwähnt, mir gefällt die Idee des verteilten Systems, aber was passiert, wenn einer eine Abfrage für etwas, das es nicht gibt? IMO würde es auf folgendes hinauslaufen: Abfrage an den Verteiler -> Rechner A|findet nix -> weiter zu Rehner B der auch nix findet (aber jedesmal einen hoffentlich vorhandenen Index absuchen muß), der gibt weiter an C... Fehlerhafte Anfragen dürften öfter mal vorkommen, ich denk mal daß damit in kurzer Zeit das komplette Netzwerk hauptsächlich damit beschäftigt ist einen Rechner zu finden, der evtl. die Antwort auf die Anfrage hat. Ich weiß, dass es im Bereich der Peer2Peer-Netzwerke einiges in der Richtung gibt, das die Hops (also Sprünge zwischen Rechnern) relativ problemlos reduzieren kann. Wenn Du Dir die relativ alten P2P-Tauschbörsen technisch anguckst, tauschen die vor allem auch Quellen miteinander aus - also: welche IPs sind sonst noch aktiv? Welche Daten sind auf diesen Rechnern vorhanden? Während diese P2P-Netzwerke das Problem haben, dass die Gesamtheit der Daten nicht global bekannt ist, haben wir den Vorteil, dass wir die OSM-Datenbank sogar mathematisch einfach berechenbar strukturieren können. Genaueres müsste ich nachlesen - aber machbar ist da jedenfalls mehr und schneller, als du das grade skizzierst. Gruß Peter P.S.: Ich hab nicht gesagt, dass das einfach ist ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
Am Montag 06 September 2010, 22:09:55 glaubte Peter Wendorff zu wissen: > On 06.09.2010 21:13, Josias Polchau wrote: > >> Wichtig ist auch das der import schnell geht, so das fritzchen mueller > >> das auch mal schnell auf seiner kiste machen kann. > > Das wird bei solchen datenmengen nicht passieren. das wird auch in > > zukunft die Webspaces sprengen. > Du hast aber schon mitgekriegt, dass die Idee in Richtung verteiltes > System ging? > Dass eben nicht jeder Peer alle Daten verwalten soll? Du wirst vollen Zugriff auf die Maschine brauchen um sowas hinzustellen. Un wie schon im Chat erwähnt, mir gefällt die Idee des verteilten Systems, aber was passiert, wenn einer eine Abfrage für etwas, das es nicht gibt? IMO würde es auf folgendes hinauslaufen: Abfrage an den Verteiler -> Rechner A|findet nix -> weiter zu Rehner B der auch nix findet (aber jedesmal einen hoffentlich vorhandenen Index absuchen muß), der gibt weiter an C... Fehlerhafte Anfragen dürften öfter mal vorkommen, ich denk mal daß damit in kurzer Zeit das komplette Netzwerk hauptsächlich damit beschäftigt ist einen Rechner zu finden, der evtl. die Antwort auf die Anfrage hat. flo -- >Aber wenn er sich auf Kleinbuchstaben und die wichtigsten Sonderzeichen >beschränkt, kann er den Text sogar 5bit codieren. Wenn er die Kleinbuchstaben und Sonderzeichen auch noch wegläßt, kann er das Nichts sogar 0bit codieren. [Frank Weinberg und Dieter Bruegmann 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ändi g tot
Am Dienstag 07 September 2010, 08:08:31 schrieb Josias Polchau: > Ich hatte immer gelernt: > Entweder Schnell oder Platzsparend. Das gilt da aber nicht. Im kleinen stimmt das meistens. Wenn aber, wie Flo hier eindrucksvoll gezeigt hat, der Such-Index einerseits größer ist als der zu erwartende Arbeitsspeicher und andererseits der Suchindex fast genau so groß ist wie die Daten selbst, dann gilt deine Regel eben nicht mehr. Dann lieber weniger Daten, die man komplett im Arbeitsspeicher halten kann, diese mit einem groben Index partitionieren und dann in einem Segment sequenzielle Suche. Das ist schneller als eine Index-basierte Suche auf der Platte. Gruß, Bernd -- Zwei Dinge sind unendlich: Das Universum und die menschliche Dummheit. Aber beim Universum bin ich mir noch nicht sicher. - Albert Einstein signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
Am 07.09.2010 06:16, schrieb Florian Lohoff: On Mon, Sep 06, 2010 at 09:13:24PM +0200, Josias Polchau wrote: Am 06.09.2010 09:37, schrieb Florian Lohoff: SQL DBs passen nicht wirklich schoen zu den OSM Daten. Das Problem mit der TRAPI sind die vielen kleinen files und perl als interpretersprache die nicht wirklich super fuer die bit ops ist (Ich bin sonst schon ein perl fan) Du kennst PostGis? die Geometrie-Daten werden in einem Binärformat abgespeichert. Ein eigenes DB-Schema kann man auch erstellen. Ähnlich dem von Mapnik. Ja - Kenn ich - beschaeftige mich seit mehreren Jahren damit. Aber mal drueber nachgedacht wie ineffizient es ist in der Postgres/Gis einen node abzulegen in einer tabelle die eine numerische id, lat, lon und sonst nix enthaelt? Die tabelle ist nicht besonders breit und der index in etwa genausogross wie die tabelle selbst. Das geht wenn man es massschneidert signifikant effizienter ... Nein die Suche ist bei Postgres effizient nicht der Speicherplatz. und genau das brauchen wir für die XAPI nicht um sonst hat die bisherige XAPI auch eine DB im hintergrund. Das problem an der alten ist, dass keiner mehr den code warten kann bzw eine weitere instanz aufsetzen kann. d.h. 60GB zu 6.2GB - da ist ohne index nen faktor 10 dazwischen. Postgres/Gis ist super als rapid prototyping und um schnell mal mit wenig daten was ans laufen zu bringen. Aber OSM bring das zeugs schnell an den rand des machbaren es sei denn man ist kroesus und kann mit Hardware danach werfen. Ich weiß nicht, ob du da nicht etwas vergessen hast. Ich hatte immer gelernt: Entweder Schnell oder Platzsparend. also, entweder man baut ein binärformat, das klein ist, das man aber sequentiell ohne index durchsuchen muss oder man benutzt ein Relationales Modell, das Sehr hohe Zugriffszeiten hat, dafür aber sehr groß ist. durchsuch mal volltext 6 GB ohne index. das dauert zu lange. zumindest für die XAPI Terrabyte Festplatten kosten nicht mehr die Welt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
On 06.09.2010 21:13, Josias Polchau wrote: Wichtig ist auch das der import schnell geht, so das fritzchen mueller das auch mal schnell auf seiner kiste machen kann. Das wird bei solchen datenmengen nicht passieren. das wird auch in zukunft die Webspaces sprengen. Du hast aber schon mitgekriegt, dass die Idee in Richtung verteiltes System ging? Dass eben nicht jeder Peer alle Daten verwalten soll? evtl auch einen Verteiler der je nach art die Anfrage an verschidene Syteme weitergibt. Ähm... genau das hab ich heute Nachmittag geschrieben (Mail von 11:26 - auf die bisher komischerweise niemand geantwortet hat...) 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ändi g tot
Am 06.09.2010 09:37, schrieb Florian Lohoff: SQL DBs passen nicht wirklich schoen zu den OSM Daten. Das Problem mit der TRAPI sind die vielen kleinen files und perl als interpretersprache die nicht wirklich super fuer die bit ops ist (Ich bin sonst schon ein perl fan) Du kennst PostGis? die Geometrie-Daten werden in einem Binärformat abgespeichert. Ein eigenes DB-Schema kann man auch erstellen. Ähnlich dem von Mapnik. Datenbanken sind genau für so etwas gemacht. sie müssen nicht erst eingelesen werden, sondern haben Indzes usw. ich hab sehr gute erfahrungen gemacht. sogar für routing gibt es eine Postgis erweiterung. Selbst komplizierte GeoOperationen auf Deutschland waren in meiner VM extrem schnell trotz 1 GB Ram Server haben meist ein vielfaches. In Zukunft wird es so kommen müssen, wenn man eine Funktionierende und nutzbare XAPI haben möchte. Man braucht einfach einen kompletten Server für sowas. ein kleiner webspace reicht für die Welt nicht aus. Ich finde das Thema OSM binary file format spannend. hm da bin ich nicht so ein großer fan von, da wird die selbe Situation Entstehen wie sie jetzt existiert. Keiner kann den Code warten, es seidenn du Kommentierst extrem gut. das ist aber meiner Erfahrung nach nur bei wenigen Entwicklern die solche Sachen machen der Fall. Wichtig ist auch das der import schnell geht, so das fritzchen mueller das auch mal schnell auf seiner kiste machen kann. Das wird bei solchen datenmengen nicht passieren. das wird auch in zukunft die Webspaces sprengen. Deshalb habe ich mal mit einem parallelisierten OSM XML file reading rumgespielt d.h. beliebig viele cores dafuer zu nutzen (Wenn das bunzip single threaded ist kann man durchauf 6-8 Cores beschaeftigen). Klappt soweit ganz gut. Die frage ist nur wie man jetzt das ganze XML in eine Datenbank verbuddelt - Da habe ich erste experimente mit integer compression und string deduplication gemacht - nen bischen wie die google protocol buffers (ohne die zu kennen) bis ich dann ueber die osm binary file implementierung gestolpert bin. Cool. leider kenne ich mich in dem Gebiet noch nicht aus, sodass ich dir da nicht helfen kann.. außerdem kann es ja auch verschiedene Ansätze geben. evtl auch einen Verteiler der je nach art die Anfrage an verschidene Syteme weitergibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
