Ora2Pg: Migration à Grande Vitesse par Gilles Darold

L'outil ora2pg permet de jouer une migration d'Oracle à Postgresql. Malgré notre absence de besoin de ce type de migration, cette présentation fut l'occasion de parler d'optimisation diverses qui peuvent être appliqué à des imports massifs tel que nous pouvons en pratiquer à Logilab.

Par exemple :

  • utilisation prioritaire de COPY plutôt que INSERT,
  • supprimer les indexes/contraintes/triggers/sequences (les créer en fin d'import),
  • maintenir un _work_mem_ élevé (pour la création des index et contraintes),
  • augmenter les checkpoin_segments (>64/1Gb).

Quelques réglages systèmes peuvent être mis en place le temps du chargement (on les rebranche une fois que le serveur passe en "production") :

  • fsync=off
  • full_page_writes=off
  • synchronous_commit=off
  • WAL (Write Ahead Log) sur des disques SSD
  • kernel : vm.dirty_background_ratio = 1
  • kernel : vm.dirty_ratio = 2

Coté Postresql, les paramètres suivants sont probablement à modifier (les chiffres sont à titre d'exemple, la configuration matérielle est bien particulière, par exemple 64G de RAM, voir les diapos pour le détail):

  • shared_buffers = 10G
  • maintenacen_work_mem = 2G
  • checkpoint_segments = 61
  • checkpoint_completion_target = 0.9
  • wal_level = minimal
  • archive_mode = off
  • wal_buffer = 32 Mo
  • désactiver les logs
http://ora2pg.darold.net/ora2pg-logo.png

Pour aller plus loin voir le support de présentation (5).

Vers le Peta Byte avec PostgreSQL par Dimitri Fontaine

Dimitri Fontaine a admirablement bien traité cette question complexe qu'est la montée à l'échelle en terme de volume de données. Son approche fut très didactique, avec, à chaque concept, un rappel de ce dont il s'agisait. Par exemple, parlant du MVCC, il explique qu'il s'agit de plusieurs définitions en parallèle d'une même ligne. Ensuite on décide avec VACUUM quelle version doit être visible par tout le monde. Par défaut AUTOVACCUM se déclenche quand 20% des données ont changé.

Face aux difficultés et aux inconvénients de stocker la totalité d'une PetaByte sur un seul serveur, Dimitri Fontaine a évoqué les solutions possible en terme d'architecture distribuée pour permettre de stocker ce PetaByte sur plusieurs serveurs répartis. La "Bi-Directional Replication" (qui sera dispo dans le futur) permetterait d'avoir plusieurs bases SQL qui séparément stockent une partie des données (cf EVENT TRIGGERS). Un approche complémentaire serait d'utiliser plproxy qui par des procédures stockées permet de répartir les requêtes sur plusieurs serveurs.

http://www.logilab.org/file/150419/raw/Screenshot%20from%202013-07-01%2010%3A25%3A46.png

Finalement, un point qui nous a paru pertinent : il a parlé de haute disponibilité et des flous techniques qui entourent le sujet. Il faut bien faire la différence entre la disponibilité des données et du service. Par exemple, en WARM STANDBY les données sont disponibles mais il faut redémarrer Postgresql pour fournir le service alors que en HOT STANDBY les données sont disponibles et le serveur peut fournir les services.

Pour aller plus loin voir le support de présentation (6).

Comprendre EXPLAIN par Guillaume Lelarge

Utiliser EXPLAIN permet de débugger l’exécution d'une requête SQL ou de l'optimiser. On touche assez rapidement au fonctionnement interne de Postgresql qui est relativement bien documentés. Guillaume Lelarge a donc, à l'aide de nombreux exemples, présenté des mécanismes plutôt bas niveau de Postgresql.

Notons entre autres les différents types de scans dont les noms sont relativement explicites :

Dans la même veine, les types de tris :

  • external sort (sur disque),
  • quicksort (en mémoire).

Mais aussi, prenez le temps de lire les exemples sur son support de présentation (7)

Conclusion

https://www.pgday.fr/_media/pgfr2.png

PGDay.fr est une conférence que nous pouvons vivement vous recommander, proposant un savant mélange des différentes questions auxquelles nous sommes confrontées lorsque nous travaillons avec des bases de données. Aussi bien en tant qu'administrateur système, développeur, ou utilisateur de SQL. Il va sans dire que le niveau technique était très pointu. Les présentations restaient pourtant accessibles. Les orateurs et organisateurs étaient disponibles pour des interactions, permettant de prolonger la réflexion et les discussions au delà des présentations.

Nous envisageons d'ores et déjà d'aller à l'édition 2014! À l'année prochaine...

http://www.logilab.org/file/150100/raw/2e1ax_default_entry_postgresql.jpg
blog entry of