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

Mar 12 Aou 19:17:44 UTC 2014

Le 12 août 2014 18:38, Philippe Verdy <verdy_p at wanadoo.fr> a écrit :

> En terme d'I/O cela ne changera pas grand chose.
>
> Même faire un UPDATE à la place d'un DELETE/INSERT n'aura pas grande
> incidence tout bonnement car le premier DELETE aura déjà chargé les pages
> qui seront les mêmes que celles affectées par l'INSERT qui suit pour mettre
> à jour les index: elles sont encore en cache meˆme s'il y a un petit délai
> entre les deux opérations et s'il y a beaucoup d'opérations concurrentes.
>
>
D'accord là dessus. L'UPDATE a besoin de retrouve les données existantes
pour les mettre à jour tout ça doit se valoir en terme d'IO à ce moment là.

> Même un UPDATE pourrait avoir poru effet de réorganiser des pages pour
> maintenir le fill factor, car l'UPDATE peut changer la taille d'une ligne
> de table (en plus ou en moins).
>
>
Tout dépend comment le fillfactor est utilisé justement. Sur la partie
données (et je n'ai parlé que de ça), j'imagine que c'est un peu d'espace
libre conservé lors des INSERT, mais justement pour être disponible lors
des UPDATE... sinon quel peut bien être son intérêt ? Si on réserve
toujours un ratio fixe d'espace vide ça revient à ne jamais l'utiliser...
et ça n'a aucun intérêt.

> Si on veut être optimal toutefois, un simple SELECT n'a pour effet QUE de
> charger les pages nécessaires dans le cache, ce qui rend ensuite l''INSERT
> ou l'UPDATE qui suit quasi instantané (au moins pour les pages des index
> qui sont utilisés pour faire le SELECT initial). Cependant le SELECT
> initial peut se contenter souvent de ne lire qu'un seul index sans avoir à
> mettre à jour toutes les tables et index liés, c'est donc plus rapide
> puisque le volume de pages concerné est plus faible au cas où la clé n'est
> pas trouvée et qu'on va finalement faire un INSERT. En revanche si le
> SELECT initial trouve la clé, il est fort probable alors que toutes les
> pages de toutes les tables et index liés seront affectées (mais là comme on
> a trouvé la clé, et qu'on va faire un UPDATE en utilisant cette clé, les
> pages de l'index utilisé pour fait le SELECT initial sont déjà en mémoire
> et resteront lues uniquement, alors que les autres tables/index seront mis
> à jour pendant l'UPDATE de la ligne trouvée).
>
>
J'imagine plus le SELECT chargeant uniquement ce dont il a besoin. Quelques
pages de l'index qui permet de trouver les données, puis les données... et
aucune page d'autre index éventuel pointant sur le données.

Les requêtes dont on parle là sont très basiques, pas relationnelles.

> Mais le problème de la méthode SELECT suivi de INSERT ou UDATE c'est la
> concurrence d'accès: on doit utiliser le mode transactionnel et donc
> "locker" les pages de l'index utilisé pour le SELECT initial. Et là ce sont
> ces locks qui risquent d'entraver les performances.
>
>
Pas de problème dans notre cas non plus, il n'y a qu'osm2pgsql qui fait des
mises à jour dans la base et il n'y aura pas de mise à jour concurrente sur
le même enregistrement.

> Tout dépend donc de la granularité des transactions: qu'est-ce qui est
> atomique dans l'opération INSERT ou UPDATE poru que cela ne provoque pas de
> requêtes incohérentes dans les accès concurrents? Pour certaines opérations
> de mises à jour comme celles-là où les accès concurrents sont majoritaires
> on pourrait croire que DELETE+INSERT inconditionnel serait toujours
> préférable, surtout s'il n'y a qu'un seul accès effectuant des mises à jour
> des tables (et que tous les autres accès concurrents sont en lecture
> seule). On ne peut pas réellement le garantir.
>
> L'atomicité (transactionnelle) de l'opération DELETE+INSERT sera donc la
> même que pour l'opération SELECT+(INSERT ou UPDATE) si on veut éviter des
> requêtes incohérentes (et donc se retrouver plus tard avec des données
> manquantes ou en trop qui restent oubliées dans la base ou éviter de se
> retrouver avec des clés doubles (qui provoquent des erreurs
> transactionnelels lors de l'INSERT dans une table à index unique).
>
> Les bases utilisées ont de très nombreux accès concurrents; on ne peut pas
> se passer réellement du mode transactionnel. De fait on a intérêt donc à
> faire un "lock" tout au début des transactions avant de commencer les
> modifs de la transaction, et donc cela milite effectivement pour des mises
> à jour utilisant un SELECT initial pour ensuite faire selon qu'on a trouvé
> on on la clé, un INSERT ou un UPDATE dans la même transaction (l'intérêt du
> lock initial étant que l'opération de "rollback" ne fait que libérer les
> "locks" et n'aura rien à modifier, il n'y aura eu donc en cas de conflit
> nécessitant un rollback, aucun autre accès que des accès en lecture seule.
>
> De plus les locks peuvent être obtenus tous ensembles de façon atomique,
> et on eput utiliser alors le mode transactionnel "optimiste" (où les
> "rollbacks" sont très peu probables, il n'y a qu'à libérer les locks en
> cours pour éviter les deadlocks des accès concurrents, et le moteur peut
> reprogrammer la transaction sans même avoir besoin de l'annuler ou la
> signaler en erreur d'accès concurrent).
>
> Dans tous les cas, le fill factor n'entre pas en jeu pour déterminer le
> mode transactionnel. Ce qui compte ce sont uniquement les ratios entre I/O
> en lecture seule et I/O en écriture pour les réorganisations de pages
> d'index.
>
>
Je ne pense pas que ceci nous concerne dans le cas présent. Je parle bien
d'un cas particulier (une base osm2pgsql) et pas "en général".

> En revanche, le modèle de stockage des tables (le type de B-arbre utilisé)
> joue un plus grand rôle: dans un B-arbre simple, on stocke les lignes de
> table directement dans les pages de n'importe quel niveau (y compris poru
> la page racine).
>
> Cependant des modèles de stockage plus performants peuvent utiliser un
> stockage différent pour les pages feuilles de l'arbre (stockant toutes les
> colonnes de toutes les lignes) et pour les pages de branche ou de la racine
> (ne stockant que les clés, lesquelles peuvent aussi être compressées en
> utilisant le fait que leur tri cohérent induit une forte redondance entre
> les clés voisines dans l'ordre de tri de l'index). Avec un tel modèle de
> table, on peut stocker beaucoup de clés dans la même page, les
> réorganisations sont très peu fréquentes par rapport aux pages feuilles
> plus volumineuses.
>
> Dans un tel modèle d'arbre ayant deux types de pages distincts, il est
> possible de pousser un fill factor élevé pour les pages de branche ou
> racines, tout en gardant un fill factor plus faible pour les pages
> feuilles. Par exemple, un fill factor à 97% (où une mise à jour pourrait
> nécessiter lors des réorganisations d'arbre, de traiter jusqu'à une
> soixantaine de pages au pire, ou une trentaine en moyenne) pour les
> branches ou la racine, et 85% (6 ou 7 pages au pire par réorganisation, ou
> 3 en moyenne) pour les pages feuilles contenant les colonnes clés et toutes
> les autres colonnes de données. Ce modèle est d'autant plus intéressant que
> la longueur moyenne des clés par ligne est beaucoup plus faible que la
> longueur moyenne des lignes (incluant toutes les colonnes): quand la clé
> est un simple entier 32 bits ou 64 bits (par exemple un ID d'objet OSM), il
> sera à privilégier.
>
> Choisir donc un modèle de table adapté optimisant la compression des clés
> des pages branches/racine. Le modèle de B-arbre simple n'est pas optimal.
> Là cela dépend du moteur SQL et des types de stockage de table/index qu'il
> peut gérer (et de sa façon à compresser ou pas les clés).
>
>
Dans le cas présent le moteur c'est postgres... Il serait peut être bon
avant de nous sortir toute la littérature sur les SGBD d'indiquer ce qui
est en rapport avec le sujet initial.
Donc retour à postgresql et osm2pgsql... ou ouverture d'un autre sujet
éventuellement sur une autre liste de diffusion plus généraliste.

-- 
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/19d7829e/attachment-0001.html>