[OSM-dev-fr] "glonflement" des tables osm2pgsql...

[Christian Quest]

A voir pourquoi ça a été codé comme ça dans osm2pgsql... il y a peut être
une bonne raison.

Celle que je vois est liée à l'absence de commande REPLACE comme on la
trouve dans MySQL.
Du coup, il faudrait différencier les créations des mises à jour, ce qui
aurait un effet de bord important si on rejoue des diffs dans le désordre
ou alors compliquer sérieusement chaque UPDATE pour le doubler par un
INSERT en cas d'échec, mais ça peut valoir le coup.

Pour le fillfactor, Philippe a grosso-modo couvert le sujet.

Dans le cas des données OSM, on a une part de mise à jour somme toute
faible par rapport au volume global de la base et surtout pas mal d'ajouts.
On peut rester sur des fillfactor élevés pour données et index qui ont un
impact potentiellement négatif sur les mises à jour, mais très positif sur
les lectures. Pour une base osm2pgsql servant à générer beaucoup de tuiles,
les lectures sont très majoritaires.
L'autre aspect important est qu'en ayant des pages très remplies
(fillfactor élevé), on en a moins globalement et donc à quantité de RAM
égale on peut avoir une proportion plus importante de données en cache...
toujours plus rapide que des IO sur un SSD et à fortiori des IO sur HDD !



Le 12 août 2014 13:47, Francescu GAROBY <f.garoby at gmail.com> a écrit :

> Et ça ne vaudrait pas le coup de modifier la fonction "pgsql_modify_node"
> que tu pointes pour lui faire faire un UPDATE, plutôt qu'un INSERT/DELETE ?
> La modification ne me paraît pas compliquée et si ça peut faciliter votre
> histoire de fillfactor (j'avoue ne pas comprendre de quoi il s'agit)...
>
> Francescu
>
>
> Le 12 août 2014 12:47, Christian Quest <cquest at openstreetmap.fr> a écrit :
>
> Par défaut le fillfactor sur les data est de 100%, d'où l'idée de le
>> baisser un peu... mais l'efficacité dépendra aussi de comment osm2pgsql met
>> à jour les données et vu le code ça semble malheureusement se faire à coup
>> de DELETE/INSERT et pas d'UPDATE...
>> https://github.com/openstreetmap/osm2pgsql/blob/master/output-pgsql.c#L1432
>>
>> Je ne suis pas sûr dans ces conditions que ça serve à grand chose.
>>
>>
>> Le 12 août 2014 11:37, Christophe Merlet <redfox at redfoxcenter.org> a
>> écrit :
>>
>> Le 12/08/2014 10:10, Christian Quest a écrit :
>>> > Vu qu'on a 2 bases osm2pgsql monde à la structure identique sur les
>>> > serveurs tile et layers, j'ai comparé l'espace occupé par les tables
>>> car
>>> > celui-ci est compté actuellement sur nos SSD de 480 (tile) et 512Go
>>> > (layers).
>>> >
>>> > Il y a des différentes plus ou moins importantes. La plus étonnante
>>> > concerne planet_osm_line qui pour les seules data fait 55Go sur tile et
>>> > 39Go sur layers, soit une différence de 40%.
>>> >
>>> > Je m'explique difficilement ces différences.
>>> >
>>> > Je viens de recopier la table (CREATE TABLE line as SELECT * FROM
>>> > planet_osm_line) et j'ai une table de 35Go. Il y a donc des trous dans
>>> > les data ou alors c'est un auto-vacuum en cours qui provoque ce
>>> > gonflement alors que je pensais qu'il prenait des données en fin de
>>> > fichier pour les remettre dans les trous.
>>> >
>>> > Des idées de votre côté ?
>>>
>>>
>>> L'auto vacuum est extrêmement limité. Il ne fait qu'indiquer les espaces
>>> réutilisables sans forcer leur réutilisation. C'est le VACUUM FULL qui
>>> permet de regagné l'espace disque. Mais pour se faire il faut au moins
>>> avoir l'équivalent de la plus grosse table en espace disponible et
>>> verrouiller les  tables en cours de traitement.
>>>
>>> Par ailleurs regagner l'espace disque n'est pas forcément une bonne
>>> idée, car, si je ne m'abuse, pgsql essaye d'insérer les données "au bon
>>> endroit". S'il y a des trous dans la base au bon endroit à cause d'une
>>> suppression précédente, c'est gagné, sinon il met là ou il peut.
>>>
>>> Ce sont les stats qui indique la meilleur stratégie.
>>>
>>> D'ailleurs, suivant l'espace disque disponible, il peut être judicieux
>>> de diminuer le fillfactor. ça laisse volontairement des trous dans la
>>> base pour insérer les nouvelles données
>>>
>>>
>>>
>>>         Librement,
>>> --
>>> Christophe Merlet (RedFox)
>>>
>>> _______________________________________________
>>> dev-fr mailing list
>>> dev-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/dev-fr
>>>
>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> _______________________________________________
>> dev-fr mailing list
>> dev-fr at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>>
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>


-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140812/8cd8ec03/attachment-0001.html>