Le 12 août 2014 19:06, Christophe Merlet <[email protected]> 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.
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
