{"id":79039,"date":"2020-04-23T19:43:26","date_gmt":"2020-04-23T17:43:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql"},"modified":"2020-04-23T19:43:26","modified_gmt":"2020-04-23T17:43:26","slug":"ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ekonomim-kopeechku-na-bolshih-obemah-v-postgresql","title":{"rendered":"\u00c9conomisons quelques centimes sur de gros volumes dans PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En poursuivant le sujet de l'enregistrement de grands flux de donn\u00e9es, soulev\u00e9 dans l'article pr\u00e9c\u00e9dent sur la partition<\/a><\/noindex>, examinons les moyens de r\u00e9duire la taille \u00ab physique \u00bb des donn\u00e9es stock\u00e9es<\/b> dans PostgreSQL, et leur impact sur les performances du serveur.<\/p>\n

Il sera question de r\u00e9glages TOAST et d'alignement des donn\u00e9es<\/b>. En moyenne, ces m\u00e9thodes permettront d'\u00e9conomiser relativement peu de ressources, mais \u2014 sans aucune modification du code de l'application.<\/p>\n

\"\u00c9conomisons
\nCependant, notre exp\u00e9rience s'est r\u00e9v\u00e9l\u00e9e assez productive \u00e0 cet \u00e9gard, car le stockage de pratiquement toute surveillance est par nature principalement en mode ajout<\/b> en ce qui concerne les donn\u00e9es enregistr\u00e9es. Et si vous vous demandez comment enseigner \u00e0 la base \u00e0 \u00e9crire sur le disque \u00e0 la place de 200MB\/s<\/b> deux fois moins \u2014 je vous invite \u00e0 lire la suite.
\n<\/a><\/noindex><\/p>\n

Petits secrets des grandes donn\u00e9es<\/h2>\n

\nEn raison du profil de travail de notre service<\/a><\/noindex>, il re\u00e7oit r\u00e9guli\u00e8rement des paquets de texte en provenance des journaux des paquets de texte<\/b>.<\/p>\n

Et comme le complexe SBIS<\/a><\/noindex>, dont nous surveillons les bases de donn\u00e9es, est un produit multifonctionnel avec des structures de donn\u00e9es complexes, les requ\u00eates visent \u00e0 obtenir des performances maximales<\/b> sont donc tout \u00e0 fait des \u00ab volumineux \u00bb avec une logique algorithmique complexe.<\/a><\/noindex>Ainsi, le volume de chaque requ\u00eate distincte ou du plan d'ex\u00e9cution r\u00e9sultant dans le journal que nous recevons se r\u00e9v\u00e8le \u00ab en moyenne \u00bb assez important.<\/p>\n

Voyons la structure d'une des tables dans lesquelles nous \u00e9crivons des donn\u00e9es \u00ab brutes \u00bb \u2014 c'est-\u00e0-dire le texte original des entr\u00e9es du journal :<\/p>\n

CREATE TABLE rawdata_orig(\n  pack -- PK\n    uuid NOT NULL\n, recno -- PK\n    smallint NOT NULL\n, dt -- cl\u00e9 de section\n    date\n, data -- le plus important\n    text\n, PRIMARY KEY(pack, recno)\n);<\/code><\/pre>\n
\nC'est un tableau typique (d\u00e9j\u00e0 partitionn\u00e9, bien s\u00fbr, c'est donc un mod\u00e8le de section), o\u00f9 le plus important est le texte. Parfois, il est assez volumineux.<\/p>\n
Rappelons que la taille \u00ab physique \u00bb d'un enregistrement dans PG ne peut pas d\u00e9passer une page de donn\u00e9es, mais la taille \u00ab logique \u00bb est une affaire totalement diff\u00e9rente. Pour enregistrer une valeur volumineuse (varchar\/text\/bytea) dans un champ, on utilise la technologie TOAST<\/a><\/noindex>:<\/p>\n
PostgreSQL utilise une taille de page fixe (g\u00e9n\u00e9ralement 8 Ko) et ne permet pas aux tuples d'occuper plusieurs pages. Il est donc impossible de stocker directement de tr\u00e8s grandes valeurs de champs. Pour contourner cette limitation, les grandes valeurs de champs sont compress\u00e9es et\/ou divis\u00e9es en plusieurs lignes physiques. Cela se produit de mani\u00e8re transparente pour l'utilisateur et a peu d'impact sur la plupart du code du serveur. Cette m\u00e9thode est connue sous le nom de TOAST \u2026<\/p><\/blockquote>\n
\nEn r\u00e9alit\u00e9, pour chaque table avec des champs \u00ab potentiellement grands \u00bb, une table associ\u00e9e est automatiquement<\/a><\/noindex> cr\u00e9\u00e9e pour \u00ab d\u00e9couper \u00bb<\/p>\n
chaque enregistrement \u00ab important \u00bb en segments de 2 Ko :<\/code><\/pre>\n
\nTOAST(\n  chunk_id\n    integer\n, chunk_seq\n    integer\n, chunk_data\n    bytea\n, PRIMARY KEY(chunk_id, chunk_seq)\n); data<\/code>Autrement dit, si nous devons enregistrer une ligne avec une valeur \u00ab importante \u00bb , alors l'enregistrement r\u00e9el se fera<\/b>.<\/p>\n
non seulement dans la table principale et son PK, mais aussi dans TOAST et son PK<\/h4>\n
\nR\u00e9duire l'impact de TOAST Mais la plupart des enregistrements ne sont pas si grands,<\/b> ils devraient tenir dans 8 Ko.<\/p>\n
\u2014 comment \u00e9conomiser l\u00e0-dessus ? Ici, l'attribut<\/code><\/a><\/noindex> STORAGE<\/p>\n
\n