{"id":74953,"date":"2020-03-22T08:42:22","date_gmt":"2020-03-22T05:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy"},"modified":"2020-03-22T08:42:22","modified_gmt":"2020-03-22T05:42:22","slug":"dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/dba-gramotno-organizovyvaem-sinhronizaczii-i-importy","title":{"rendered":"DBA : nous organisons efficacement les synchronisations et les importations.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Lors du traitement complexe de grands ensembles de donn\u00e9es (divers processus ETL<\/a><\/noindex>: importations, conversions et synchronisations avec une source externe), il est souvent n\u00e9cessaire de \u00ab m\u00e9moriser \u00bb temporairement et de traiter rapidement<\/b> quelque chose de volumineux.<\/p>\n

Une t\u00e2che typique de ce type est g\u00e9n\u00e9ralement formul\u00e9e comme suit : \u00ab Voici ce que la comptabilit\u00e9 a extrait de la banque client<\/a><\/noindex> des derniers paiements re\u00e7us, il faut les t\u00e9l\u00e9charger rapidement sur le site et les lier aux comptes \u00bb<\/i><\/p>\n

Mais lorsque le volume de cette \u00ab chose \u00bb commence \u00e0 \u00eatre mesur\u00e9 en centaines de m\u00e9gaoctets, et que le service doit continuer \u00e0 fonctionner avec une base en mode 24\/7, de nombreux effets secondaires apparaissent qui vont vous compliquer la vie.
\n\"DBA
\nPour y faire face dans PostgreSQL (et pas seulement dans ce syst\u00e8me), il est possible d'utiliser certaines capacit\u00e9s d'optimisation qui permettront de traiter le tout plus rapidement et avec moins de ressources.
\n<\/a><\/noindex><\/p>\n

1. O\u00f9 charger ?<\/h2>\n

\nCommen\u00e7ons par d\u00e9terminer o\u00f9 nous pouvons charger les donn\u00e9es que nous souhaitons \u00ab traiter \u00bb.<\/p>\n

1.1. Tables temporaires (TEMPORARY TABLE)<\/h3>\n

\nEn principe, pour PostgreSQL, les tables temporaires sont comme toutes les autres tables. Par cons\u00e9quent, les superstitions du type \u00ab l\u00e0, tout est stock\u00e9 uniquement en m\u00e9moire, et elle peut se remplir \u00bb<\/b><\/i>sont incorrectes. Mais il existe \u00e9galement quelques diff\u00e9rences essentielles.<\/p>\n

Un \u00ab espace de noms \u00bb pour chaque connexion \u00e0 la BDD<\/h4>\n

\nSi deux connexions tentent d'ex\u00e9cuter simultan\u00e9ment CREATE TABLE x<\/code>, alors quelqu'un recevra certainement une erreur d'unicit\u00e9<\/b> des objets de la BDD.<\/p>\n

En revanche, si les deux tentent d'ex\u00e9cuter CREATE TEMPORAIRE<\/b> TABLE x<\/code>, alors les deux le feront normalement, et chacun recevra sa propre instance<\/b> de la table. Et il n'y aura rien en commun entre elles.<\/p>\n

\u00ab Auto-destruction \u00bb lors de la d\u00e9connexion<\/h4>\n

\nLors de la fermeture de la connexion, toutes les tables temporaires sont automatiquement supprim\u00e9es, donc il n'y a aucun sens \u00e0 ex\u00e9cuter DROP TABLE x<\/code> , \u00e0 part\u2026<\/p>\n

Si vous travaillez via pgbouncer en mode transactionnel<\/b>, alors la base continue de penser que cette connexion est toujours active, et cette table temporaire existe toujours dans celle-ci.<\/p>\n

Donc, essayer de la cr\u00e9er \u00e0 nouveau, d\u00e9j\u00e0 \u00e0 partir d'une autre connexion \u00e0 pgbouncer, entra\u00eenera une erreur. Mais cela peut \u00eatre contourn\u00e9 en utilisant CR\u00c9ER UNE TABLE TEMPORAIRE SI NON EXISSE<\/b> x<\/code>.<\/p>\n

Il est vrai que mieux vaut ne pas faire cela, car vous pourriez alors \u00ab d\u00e9couvrir par surprise \u00bb des donn\u00e9es laiss\u00e9es par le \u00ab pr\u00e9c\u00e9dent propri\u00e9taire \u00bb. Il est bien mieux de lire le manuel et de voir qu'il est possible d'ajouter des options lors de la cr\u00e9ation de la table. EN REMPLACEMENT DROP<\/b><\/code> \u2014 c'est-\u00e0-dire qu'\u00e0 la fin de la transaction, la table sera automatiquement supprim\u00e9e.<\/p>\n

Non-r\u00e9plication<\/h4>\n

\nEn raison de son appartenance \u00e0 une seule connexion, les tables temporaires ne sont pas r\u00e9pliqu\u00e9es. Mais cela \u00e9limine le besoin d'\u00e9crire les donn\u00e9es deux fois<\/b> dans le heap + WAL, rendant ainsi les INSERT\/UPDATE\/DELETE beaucoup plus rapides.<\/p>\n

Mais puisque la temporaire est tout de m\u00eame une \u00ab presque ordinaire \u00bb table, il n\u2019est pas possible de la cr\u00e9er sur la r\u00e9plique non plus. Du moins, pas pour le moment, bien qu'un patch correspondant circule depuis longtemps.<\/p>\n

1.2. Tables non journalis\u00e9es (UNLOGGED TABLE)<\/h3>\n

\nMais que faire, par exemple, si vous avez un processus ETL lourd, qui ne peut pas \u00eatre r\u00e9alis\u00e9 dans le cadre d'une seule transaction, et que vous avez quand m\u00eame pgbouncer en mode transactionnel<\/b>?..<\/p>\n

Ou si le flux de donn\u00e9es est si important que la bande passante d'une seule connexion<\/b> avec la base de donn\u00e9es (lire, un processus sur le CPU) n'est pas suffisante ?..<\/p>\n

Ou certaines op\u00e9rations se d\u00e9roulent de mani\u00e8re asynchrone<\/b> dans diff\u00e9rentes connexions ?..<\/p>\n

Il n'y a qu'une seule option ici \u2014 cr\u00e9er temporairement une table non temporaire<\/b>. Un jeu de mots, n'est-ce pas. En d'autres termes :<\/p>\n