On Tue, Sep 07, 2010 at 12:07:21PM +0200, Bernhard Zwischenbrugger wrote: > hi > > Der TRAPI Ansatz klingt sehr gut. > > Die Welt wird also zerschnitten in Rechtecke die z.B. 256kByte haben und > nacheinandere > in ein File gespeichert. > Am Anfang des Files muss ein Index sein, der einen direkten Sprung auf > so einen > 256kByte Block ermöglicht.
Die bloecke sind in einzelnen files - D.h. kein index sondern nur durch arithmetik kann ich den dateinamen bzw pfad erzeugen. Das wird schwieriger wenn die bounding box halt mehrere bloecke beinhaltet - aber dennoch moeglich. Innerhalb der bloecke wird dann eine lineare suche angewendet was jetzt in anbetracht von 256kbyte bzw X Megabyte ja kein problem darstellt. Die TRAPI haelt die Daten sogar superklein d.h. 4KByte etc - Ist natuerlich reichlich suboptimal fuer die heutigen Festplatten aber in anbetracht der Programmiersprache perl muss halt die datenmenge die linear durchsucht wird klein gehalten werden. > Das wären 3 Zugriffe auf die Festplatte um die Daten zu bekommen. Auf > meinem Laptop dauert ein Zugriff ca. 11ms. 1 Zugriff - Weil ich den dateinamen berechnen kann. Stimmt natuerlich nicht denn man muss durchaus mal mehrere plattenzugriffe allein fuer ein "open" auf eine datei rechnen (dindex, directory entry, inode, indirect blocks etc) > 3 Zugriffe würden somit 33ms dauern und mit dem restlichen Programm > zusammen, sollten > Zugriffszeiten von 50ms möglich sein ohne irgendwas zu cachen. > Wenn der Index im Ram bleibt, verkürzt sich das ganze natürlich, wobei > hier eigentlich schon > ein Festplatten Cache reichen sollte. > > Damit wäre das schwierigste Problem - die bbox Suche erledigt > (theoretisch zumindest). > Die restlichen indexe auf id, tag, ... sind eigentlich einfacher - auch > wenn sie wohl mehr > Festplatten Speicher brauchen. Es ist hoellen komplex das zeugs - das ist oben nur ansatzweise das was man braucht. Wo legt man ways ab? Die koennen ja durch mehrere bboxen gehen? Was ist mir relations die ja von haus aus keine position haben? Was ist wenn der user einen node haben will fuer den nur die "id" bekannt ist aber nicht die position d.h. es muss auch einen globalen node index geben der dann jeweils den block adressiert. Und kommen wir dann zum thema inkrementelle updates die ja zeitgleich zu read accesses laufen muessten. Flo -- Florian Lohoff [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
