[OSM-Devserver] Partitionierung

[Kai Krueger]

On 12/04/10 12:30, Frederik Ramm wrote:
> Hallo,
>
> Kai Krueger wrote:
>> Ohne index benoetigt der querry ca 960ms,
>> Fuer "where highway is not null" is es dann ca. 930ms
>> und bei dem vollen "where highway in
>> ('motorway','motorway_link','trunk','trunk_link','primary','primary_link','secondary','secondary_link','tertiary','tertiary_link','residential','unclassified','minor','road','service','pedestrian','raceway','living_street')"
>> sind es immer noch 850ms.
>
> Wenn Du das Test-Setup noch da hast, gib uns mal die Vergleichszahl fuer
> ohne "order by z_order". Ich glaub naemlich, das ist der Boesewicht.

Ich habe die Zahlen jetzt nicht direkt parat, kann sie aber spaeter noch mal 
anschauen. Der sort auf z_order war aber definitive einer der grossen Teile. Die 
verteilung war wenn ich mich richtig erinnere sehr grob ca 30 ms fuer den bitmap 
Index scan, dann noch mal 300 - 400 ms fuer den Bitmap heap lookup der treffer 
des index scans und die restilichen 300 - 400 ms waren der sort. Das ganze war 
nach mehr maliger ausfuehrung, also als alles bereits in den Caches war. Mit 
kalten caches, (z.B. weil der ganze planet nicht ins Ram passt) sieht die Sache 
moeglicherweise wieder ganz anders aus.

Der highway is not null index hilft aber warscheinlich nicht sonderlich, da der 
die ueberwiegende Anzahl der rows in der Tabelle planet_osm_line anscheinend 
einen highway Eintrag haben, das heist der partielle index fast so gross ist wie 
der volle index. Bei anderen nicht so haeufig verwendeten tags sieht es also 
moeglicherweise recht anders aus, siehe eben den waterway query.

>
>> Und das waren schon die recht einfachen queries. Viele der queries die
>> mapnik macht haben wesentlich mehr "or" Verknuepfungen, so dass man im
>> Prinzip fuer jeden querry (und davon gibt es viele) einen separaten
>> index benoetigt.
>
> Ich dachte, dass wir nicht primaer ueber eine Optimierung fuers
> Rendering reden, sondern allgemein? Was Mapnik betrifft hast Du zwar
> recht, andrerseits sind es auf jedem Zoomlevel doch einige wenige
> Queries, die den Loewenanteil der Zeit verbrauchen, und da lohnt es sich
> schon, ein bisschen zu feilen.

Das war aus deiner email nicht so ganz klar was wir genau optimieren wollen. Ich 
hatte zwar angenommen das du es allgemeiner meinst, aber es ist halt sehr schwer 
optimierungen zu diskutieren, wenn man nicht weis was man eigentlich optimieren 
will. Deshalb habe ich das Beispiel des mapnik renderers verwendet.

Es sind zwar in der Tat nicht so viele, aber immernoch eine nenneswerte Anzahl, 
und wie zumindestens dieses eine Beispiel zeigt, sind bei manchen von denen auch 
wenn man fuer bestimmte querries optimiert nicht so viel extra performance 
herauszuholen, da die querries einfach zu komplex sind bzw zuviele daten laden 
und desshalb mehr zeit in sachen wie den sorts verbringen als was man mit 
indexen erreichen kann. (das Beispiel war ein recht weit heraus gezoomte 
metatile von London, also von hoher Datenkomplexitaet, laendlich highzoom tiles 
sehen also auch wieder ganz anders aus)

Aber das ganze haengt halt wirklich extrem davon ab genau welche querries man 
macht, sodas es extrem schwierig sein duerfte "generelle" optimierungen zu 
finden ohne eben genau im Auge zu haben was man damit vor hat. Fuer weltweite 
POI abfragen z.B. ist das jetztige schema natuerlich recht ungeeignet und extra 
indexe wuerden viel helfen.

Desshalb muss man halt schauen wo die praktischen bottlenecks sind, getreu des 
Mottos "premature optimization is the root of all evil...".

>
>> Nicht nur verliert man dann also bei den Updates, da man wesentlich
>> mehr indexe pflegen muss,
>
> Probiere das aber mal aus. Der create index fuer so einen partial index
> dauert auf dem ganzen Planeten (!) in der Regel nur wenige Sekunden. Ist
> das nicht Anlass zur Annahme, dass auch die Aktualisierung solcher
> Indexe nicht allzu teuer sein kann?

Ein minutely diff kann locker mal ein paar tausend eintraege haben. Da der index 
bei jedem update einzeln veraendert werden muss, kann auch sehr kleine zeiten 
sich schnell aufsummieren. Ob das in diesem Fall eine Rolle spielt? Keine 
Ahnung, muesste man ausprobieren. Allerdings aus einem anderen Beispiel weis ich 
das es durchaus das potential hat etwas auszumachen. Ein Import von z.B. einem 
UK extract mit Osmosis in ein api-06 schema hat jedenfalls wenn ich mich richtig 
errinnere weniger als die haelfte der Zeit benoetigt, nachdem man alle Indexe 
zuvor gedropt hatte. (Und die zeit war sogar inclusive neu Erzeugung des Index 
am Ende).

>
>> Bevor man irgendwelche indexe hinzufuegt sollte man also recht genau
>> eine statistische Analyse machen, welche Abfragen im Durchschnitt ab
>> meisten Zeit benoetigen ( also die Kombination aus wie haeufig werden
>> die Abfragen verwendet und wie lange braucht jede davon) und ob das
>> insgesamt prozentual ein nennenswerter Anteil des Gesamten ist.
>
> Wobei, wenn ich es richtig verstanden habe, hier das Ziel ja nicht so
> spezifisch war.

Wie gesagt, dann duerfte es halt recht schwer werden dafuer sinnvolle 
Optimierungen zu finden.

Im uebrigen zum urspruenglichen Thema partitionierung. Das Osm2Pgsql schema ist 
bereits in 4 teile partitioniert, naemlich in planet_osm_points, 
planet_osm_polygon, planet_osm_line und planet_osm_roads. Der code muesste also 
eigentlich schon vorhanden sein, denn zumindestens die partitionierung in 
planet_osm_line und planet_osm_roads muesste eigentlich die von dir erwaehnten 
Probleme auch loesen. Man koennte also testweise mal einen highway=footway in 
einen highway=motorway umtaggen und sehen ob das korrekt funktioniert.

>
> Bye
> Frederik


Kai