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

[Philippe Verdy]

Le 12 août 2014 19:06, Christophe Merlet <redfox at redfoxcenter.org> a écrit :

> Le 12/08/2014 18:47, Philippe Verdy a écrit :
> > DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
> > vient de créer un trou, mais au passage il peut aussi utiliser n'importe
> > quelle autre page déjà en mémoire si cette autre page permet un meilleur
> > équilbrage de l'arbre que de réutiliser l'ancienne page: le but est
> > d'équilibrer les trous dans les pages pour éviter de se retrouver dans
> > le cas au pire (le pire cas c'est une insertion au milieu d'une page
> > déjà pleine, quand toutes les pages racines sont déjà pleines, ce qui
> > arrive justement après une compression maximale de la table: c'est là
> > qu'on a le plus d'I/O puisqu'il faut non seulement scinder la page en
> > deux, lire les pages voisines avant et après, et restructurer aussi les
> > pages parentes dans l'arbre de la même façon).
> >
> > Je n'ai pas eu souvent à mettre dans une base SQL un fill factor
> > supérieur à 85% (au moins pour les pages feuilles). pour les tables de
> > données, ni supérieur à 95% pour les index secondaires à clé courte. 97%
> > est un taux exceptionnel et au delà ça rame dès qu'il y a plus de 3 ou 4
> > accès concurrents (même en lecture, à cause des nombreux locks de pages
> > causés sur une grande partie des pages y compris les pages mères, et à
> > cause des volumes d'I/O).
>
> Je te signale quand même que PostgreSQL a un fillfactor par defaut de
> 100 pour les data et de 90 pour les index B-tree. J'imagine que les dev
> auraient choisi d'autres valeurs si cela était si impactant sur les
> performances.


Ce n'est pas vrai cela dépend du type de table employé. un fill factor 100
pour les data n'a pas de sens. cela voudrait dire une table totalement sans
aucun index primaire, qui ne sert qu'à cumuler des données (tables de log)
sans aucun critère de tri ou d'unicité. Dès que tu as une clé primaire,
cela ne sert plus à rien.

Si le fill factor pour les B-tree par défaut est 90% c'est un peu trop
optimiste et suppose une base majoritairement utilisé en lecture seule avec
très peu de mises à jour concurrente.

Et MySQL (ou son fork plus récent), comme PostgreSQL, Oracle et d'autres
moteurs SQL proposent aussi différents modèles de tables indexées (et même
si globalement se sont des B-arbres, il y a de nombreuses options dans les
B-arbres, notamment en faisant la différence entre les pages feuille et les
pages racines, et dans la compression des clés, ou encore dans le maintien
(de façon synchrone ou non) de données statistiques de sélectivité.

Un modèle unique pour toutes les tables ou index n'est pas optimal, car
cela est largement dépendant du rapport entre taille moyenne des clés et
taille des pages: idéalement on a intérêt à maintenir un degré élevé des
arbres pour en réduire la profondeur et réduire le nombre de
réorganisations coûteuses en I/O.

Je ne suis pas un grand spécialiste de PostgreSQL, je connais mieux
d'autres moteurs, mais 90% me semble trop élevé (à voir selon justement le
rapport entre taille des clés et tailles des pages, et selon la structure
de B-arbre employé (si elle est différente entre les pages feuilles et les
branches; ou si la compression des clés s'applique aussi aux pages
feuilles) qui n'est peut-être alors pas optimale avec le modèle par défaut
(rappel: il y a au moins une bonne douzaine de B-arbres documentés dans la
littérature mais chaque moteur SQL a inventé les siens et parfois les a
révisé entre leurs versions; certains moteurs SQL disposent d'un optimiseur
dynamique capable de modifier le modèle d'une table au cours de sa vie; en
fournissant des analyses statistiques synchrones ou asynchrones : si les
analyses asynchrones ne sont pas lancées régulièrement sur les tables les
plus vivantes les performances se dégradent, c'est bien plus important de
les lancer que de tenter de recompacter les tables, ce qui ne sert à rien
sur une base très vivante!).

On peut donner des pistes mais sans analyser les statistiques et les
volumétries typiques des requêtes et leur sélectivité, il n'est pas
possible de donner une réponse unique (d'autant plus que la solution
optimale sera à adapter table par table, index par index).

Au début on peut même ne pas avoir de statistiques significatives pour
décider, mais maintenant on atteint un rythme de croisière avec des volumes
typiques importants et des requêtes récurrentes.

Mais il me semble même qu'une optimisation du stockage pour un moteur de
rendu type Mapnik (qui cherchent des cas les plus typiques) sera
nécessairement différent de celle d'une appli de QA, type Osmose (qui
cherche plutôt des cas atypiques par des requêtes que Mapnik ne fera
jamais).

De même les données mises à jour en continu par le rendu Mapnik sont très
peu nombreuses (uniquement indexer des tuiles et leur état) alors qu'il
effectue des recherhes sur des tables de "Features" prémachées par un
script "osm2gis" (dont le résultat est très différent de ce qui est
prémâché pour Osmose puisqu'il ne recherche pas les mêmes choses, et dont
les mises à jour seront essentiellement de gérer non pas des tuiles mais
des listes d'objets avec un numéro d'erreur et une suggestion et des états
de modifs en cours ou à faire ou retester). Il y a certainement quelques
tables communes mais ce n'est pas l'essentiel.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20140812/0cc8dd15/attachment-0001.html>