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.
Sollte der Index zu groß sein, dann muss da ein zweistufiger Index
gemacht werden.
Der erste Index zeigt also auf einen Index der dann wiederum auf den
256kByte Block
zeigt.
Das wären 3 Zugriffe auf die Festplatte um die Daten zu bekommen. Auf
meinem Laptop dauert ein Zugriff ca. 11ms.
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.
lg, Bernhard
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.
Yep - wenn der index nicht mehr in den speicher passt dann macht das Thema SQL
nicht mehr sooo viel spass. Und wer hat schon>32GB Speicher.
Es lassen sich massgeschneidert viel effizentere index bauen weil wir erstmal
davon ausgehen das wir immer eine bounding box setzen. Lieder einfach bounding
boxen bauen und dann immer wennns z.b.>1Mbyte/s wird splitten in 2 sub bounding
boxes die jeweils ~256Kbyte sind ....
Siehe einfach mal TRAPI ...
Man muss auch aufpassen das man das feature der platten eher mal nutzt 1MByte in
den speicher zu schaufeln als an 20 stellen jeweils nur ein kbyte zu lesen.
Flo
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
