{"id":81936,"date":"2020-05-18T01:42:37","date_gmt":"2020-05-17T23:42:37","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera"},"modified":"2020-05-18T01:42:37","modified_gmt":"2020-05-17T23:42:37","slug":"szhatie-dannyh-v-apache-ignite-opyt-sbera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","title":{"rendered":"Compression des donn\u00e9es dans Apache Ignite. Exp\u00e9rience de Sber","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Compression des donn\u00e9es dans Apache Ignite. Exp\u00e9rience de Sber\" src=\"\/wp-content\/uploads\/2020\/05\/0e26c686b1f29e88e6be4b8df81ab668.jpg\" style=\"display:block;margin: 0 auto;\" \/>Lorsque vous travaillez avec de grands volumes de donn\u00e9es, le probl\u00e8me du manque d'espace sur les disques peut parfois devenir aigu. L'une des solutions \u00e0 ce probl\u00e8me est la compression, qui permet d'augmenter la capacit\u00e9 de stockage sur le m\u00eame \u00e9quipement. Dans cet article, nous allons examiner comment fonctionne la compression des donn\u00e9es dans Apache Ignite. Nous aborderons uniquement les m\u00e9thodes de compression mises en \u0153uvre dans le produit. D'autres m\u00e9thodes de compression des donn\u00e9es (sur le r\u00e9seau, en m\u00e9moire), qu'elles soient r\u00e9alis\u00e9es ou non, resteront en dehors du cadre de cet article.<\/p>\n<p>Ainsi, en mode persistance activ\u00e9, lorsqu'il y a des modifications des donn\u00e9es dans les caches, Ignite commence \u00e0 \u00e9crire sur disque :<\/p>\n<ol>\n<li>Le contenu des caches<\/li>\n<li>Le Journal d'\u00e9criture anticip\u00e9e (Write Ahead Log, ci-apr\u00e8s WAL)<\/li>\n<\/ol>\n<p>\nUn m\u00e9canisme existe depuis assez longtemps pour compresser le WAL, appel\u00e9 WAL compaction. Dans la r\u00e9cente version d'Apache Ignite 2.8, deux nouveaux m\u00e9canismes ont \u00e9t\u00e9 ajout\u00e9s pour permettre la compression des donn\u00e9es sur le disque : la compression des pages disque pour compresser le contenu des caches et la compression des instantan\u00e9s de pages WAL pour compresser certaines entr\u00e9es du WAL. Plus de d\u00e9tails sur ces trois m\u00e9canismes ci-dessous.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Compression des pages disque<\/h3>\n<p><\/p>\n<h4>Comment cela fonctionne<\/h4>\n<p>\nPour commencer, faisons un bref rappel sur la mani\u00e8re dont Ignite stocke les donn\u00e9es. La m\u00e9moire est utilis\u00e9e sous forme de pages. La taille de la page est d\u00e9finie au d\u00e9marrage du n\u0153ud et ne peut pas \u00eatre modifi\u00e9e ult\u00e9rieurement, de plus, la taille de la page doit \u00eatre une puissance de deux et multiple de la taille du bloc du syst\u00e8me de fichiers. Les pages sont charg\u00e9es dans la RAM \u00e0 partir du disque au besoin, la taille des donn\u00e9es sur le disque peut d\u00e9passer la quantit\u00e9 de RAM allou\u00e9e. En cas de manque d'espace dans la RAM pour charger une page \u00e0 partir du disque, de vieilles pages d\u00e9j\u00e0 inutilis\u00e9es seront \u00e9vinc\u00e9es de la RAM.<\/p>\n<p>Sur le disque, les donn\u00e9es sont stock\u00e9es de la mani\u00e8re suivante : pour chaque partition de chaque groupe de caches, un fichier distinct est cr\u00e9\u00e9 ; dans ce fichier, les pages suivent l'ordre croissant des indices. L'identifiant complet d'une page contient l'identifiant du groupe de caches, le num\u00e9ro de la partition et l'indice de la page dans le fichier. Ainsi, gr\u00e2ce \u00e0 cet identifiant complet, nous pouvons pr\u00e9cis\u00e9ment identifier le fichier et l'offset du fichier pour chaque page. Vous pouvez lire davantage sur l'architecture de la m\u00e9moire pagin\u00e9e dans l'article sur le Wiki d'Apache Ignite : <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store \u2014 sous le capot<\/a><\/noindex>.<\/p>\n<p>Le m\u00e9canisme de compression des pages disque, comme on peut le deviner par son nom, fonctionne \u00e0 un niveau de page. Lors de l'activation de ce m\u00e9canisme, les op\u00e9rations sur les donn\u00e9es en RAM se font telles quelles, sans aucune compression, mais au moment de la sauvegarde des pages de la RAM sur le disque, leur compression est effectu\u00e9e.<\/p>\n<p>Cependant, compresser chaque page individuellement n'est pas encore une solution au probl\u00e8me, il faut de quelque mani\u00e8re r\u00e9duire la taille des fichiers de donn\u00e9es finaux. Si la taille de la page cesse d'\u00eatre fixe, nous ne pouvons plus \u00e9crire les pages dans le fichier les unes apr\u00e8s les autres, car cela peut engendrer toute une s\u00e9rie de probl\u00e8mes :<\/p>\n<ul>\n<li>Nous ne serons pas en mesure de calculer l'offset de la page dans le fichier \u00e0 l'aide de l'index de la page.<\/li>\n<li>Il n'est pas clair comment g\u00e9rer les pages qui ne se trouvent pas \u00e0 la fin du fichier et dont la taille change. Si la taille de la page diminue, l'espace qu'elle a lib\u00e9r\u00e9 est perdu. Si la taille de la page augmente, il faut d\u00e9j\u00e0 chercher un nouvel emplacement pour elle dans le fichier.<\/li>\n<li>Si la page se d\u00e9place d'un nombre de bytes non multiple de la taille du bloc du syst\u00e8me de fichiers, alors pour sa lecture ou son \u00e9criture, il faudra toucher \u00e0 un bloc de syst\u00e8me de fichiers de plus, ce qui peut entra\u00eener une d\u00e9gradation des performances.<\/li>\n<\/ul>\n<p>\nPour \u00e9viter de r\u00e9soudre ces probl\u00e8mes \u00e0 son propre niveau, la compression des pages disque dans Apache Ignite utilise un m\u00e9canisme de syst\u00e8me de fichiers appel\u00e9 fichiers sparse. Un fichier sparse est un fichier dans lequel certaines r\u00e9gions remplies de z\u00e9ros peuvent \u00eatre marqu\u00e9es comme \u00ab trous \u00bb. Dans ce cas, aucun bloc de syst\u00e8me de fichiers ne sera allou\u00e9 pour stocker ces trous, ce qui permet d'\u00e9conomiser de l'espace sur le disque.<\/p>\n<p>Il est logique que pour lib\u00e9rer un bloc de syst\u00e8me de fichiers, la taille du trou doit \u00eatre sup\u00e9rieure ou \u00e9gale \u00e0 celle du bloc de syst\u00e8me de fichiers, ce qui impose une limitation suppl\u00e9mentaire sur la taille de la page dans Apache Ignite : pour que la compression ait un effet, il est n\u00e9cessaire que la taille de la page soit strictement sup\u00e9rieure \u00e0 la taille du bloc de syst\u00e8me de fichiers. Si la taille de la page est \u00e9gale \u00e0 celle du bloc, nous ne pourrons jamais lib\u00e9rer aucun bloc, car pour lib\u00e9rer un unique bloc, il faudrait que la page compress\u00e9e occupe 0 byte. Si la taille de la page est \u00e9gale \u00e0 celle de 2 ou 4 blocs, nous pourrons d\u00e9j\u00e0 lib\u00e9rer au moins un bloc si notre page se compresse d'au moins 50 % ou 75 % respectivement.<\/p>\n<p>Ainsi, la description finale du fonctionnement du m\u00e9canisme est la suivante : lors de l'enregistrement d'une page sur le disque, une tentative de compression de la page est effectu\u00e9e. Si la taille de la page compress\u00e9e permet de lib\u00e9rer un ou plusieurs blocs du syst\u00e8me de fichiers, la page est enregistr\u00e9e sous forme compress\u00e9e, et un \u00ab trou \u00bb est cr\u00e9\u00e9 \u00e0 la place des blocs lib\u00e9r\u00e9s (un appel syst\u00e8me est effectu\u00e9 avec le drapeau \u00ab punch hole \u00bb). <code>fallocate()<\/code> Si la taille de la page compress\u00e9e ne permet pas de lib\u00e9rer des blocs, la page est conserv\u00e9e telle quelle, sous forme non compress\u00e9e. Tous les offsets des pages sont calcul\u00e9s de la m\u00eame mani\u00e8re que sans compression, en multipliant l'index de la page par la taille de celle-ci. Aucun d\u00e9placement des pages par ses propres moyens n'est n\u00e9cessaire. Les offsets des pages, comme sans compression, tombent sur les fronti\u00e8res des blocs du syst\u00e8me de fichiers.<\/p>\n<p><img decoding=\"async\" alt=\"Compression des donn\u00e9es dans Apache Ignite. Exp\u00e9rience de Sber\" src=\"\/wp-content\/uploads\/2020\/05\/6a6c6ad83d3b8591f76b9343ff067746.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <br \/>\nDans l'impl\u00e9mentation actuelle, Ignite peut travailler avec des fichiers sparse uniquement sous OS Linux, par cons\u00e9quent, la compression des pages disque ne peut \u00eatre activ\u00e9e que lors de l'utilisation d'Ignite sur ce syst\u00e8me d'exploitation.<\/p>\n<p>Les algorithmes de compression qui peuvent \u00eatre utilis\u00e9s pour la compression des pages disque sont : ZSTD, LZ4, Snappy. De plus, il existe un mode de fonctionnement (SKIP_GARBAGE), dans lequel seule la m\u00e9moire inutilis\u00e9e de la page est supprim\u00e9e sans appliquer de compression sur les donn\u00e9es restantes, ce qui permet de r\u00e9duire la charge sur le CPU par rapport aux algorithmes mentionn\u00e9s pr\u00e9c\u00e9demment.<\/p>\n<h4>Impact sur la performance <\/h4>\n<p>\nMalheureusement, je n'ai pas effectu\u00e9 de mesure de performance sur des environnements r\u00e9els, car nous ne pr\u00e9voyons pas d'utiliser ce m\u00e9canisme en production, mais nous pouvons th\u00e9oriquement discuter des pertes et des gains potentiels.<\/p>\n<p>Pour cela, rappelons comment la lecture et l'\u00e9criture des pages sont effectu\u00e9es lors de leurs acc\u00e8s :<\/p>\n<ul>\n<li>Lors de l'op\u00e9ration de lecture, la recherche est d'abord effectu\u00e9e dans la RAM, et si la recherche \u00e9choue, la page est charg\u00e9e dans la RAM depuis le disque par le m\u00eame thread qui effectue la lecture.<\/li>\n<li>Lors de l'op\u00e9ration d'\u00e9criture, la page dans la RAM est marqu\u00e9e comme sale, et l'enregistrement physique de la page sur le disque n'est pas imm\u00e9diatement effectu\u00e9 dans le thread qui effectue l'\u00e9criture. Toutes les pages sales sont enregistr\u00e9es sur le disque plus tard dans le processus de checkpoint par des threads s\u00e9par\u00e9s.<\/li>\n<\/ul>\n<p>\nAinsi, l'impact sur les op\u00e9rations de lecture est :<\/p>\n<ul>\n<li>Positif (IO disque), gr\u00e2ce \u00e0 la r\u00e9duction du nombre de blocs du syst\u00e8me de fichiers lus.<\/li>\n<li>N\u00e9gatif (CPU) en raison de la charge suppl\u00e9mentaire n\u00e9cessaire au syst\u00e8me d'exploitation pour travailler avec des fichiers sparse. Il se peut \u00e9galement qu'il y ait des op\u00e9rations d'E\/S suppl\u00e9mentaires pour sauvegarder une structure de fichier sparse plus complexe (malheureusement, je ne connais pas tous les d\u00e9tails concernant le fonctionnement des fichiers sparse).<\/li>\n<li>N\u00e9gatif (CPU) en raison de la n\u00e9cessit\u00e9 de d\u00e9compresser les pages.<\/li>\n<li>Aucun impact sur les op\u00e9rations d'\u00e9criture.<\/li>\n<li>Impact sur le processus de checkpoint (similaire aux op\u00e9rations de lecture) :<\/li>\n<li>Positif (disk IO) gr\u00e2ce \u00e0 la r\u00e9duction du nombre de blocs \u00e9crits dans le syst\u00e8me de fichiers.<\/li>\n<li>N\u00e9gatif (CPU, peut-\u00eatre disk IO) \u00e0 cause du travail avec des fichiers sparse.<\/li>\n<li>N\u00e9gatif (CPU) en raison de la n\u00e9cessit\u00e9 de compresser les pages.<\/li>\n<\/ul>\n<p>\nQuelle balance l'emportera ? Tout cela d\u00e9pend beaucoup de l'environnement, mais je penche plut\u00f4t vers le fait que la compression des pages disque entra\u00eenera plut\u00f4t une d\u00e9gradation des performances dans la plupart des syst\u00e8mes. D'autant plus que les tests effectu\u00e9s sur d'autres SGBD utilisant cette approche avec des fichiers sparse montrent une baisse des performances lorsque la compression est activ\u00e9e.<\/p>\n<h4>Comment activer et configurer<\/h4>\n<p>\nComme d\u00e9j\u00e0 mentionn\u00e9 ci-dessus, la version minimale d'Apache Ignite supportant la compression des pages disque est 2.8 et elle est uniquement support\u00e9e par le syst\u00e8me d'exploitation Linux. L'activation et la configuration se font comme suit :<\/p>\n<ul>\n<li>Le class-path doit inclure le module ignite-compression. Par d\u00e9faut, il se trouve dans la distribution d'Apache Ignite dans le r\u00e9pertoire libs\/optional et n'est pas inclus dans le class-path. Vous pouvez simplement d\u00e9placer le r\u00e9pertoire d'un niveau vers le haut dans libs, et alors lors du lancement via ignite.sh, il sera automatiquement inclus.<\/li>\n<li>La persistance doit \u00eatre activ\u00e9e (S'active via <code>DataRegionConfiguration.setPersistenceEnabled(true))<\/code>.<\/li>\n<li>La taille de la page doit \u00eatre sup\u00e9rieure \u00e0 la taille du bloc du syst\u00e8me de fichiers (peut \u00eatre d\u00e9finie avec <code>DataStorageConfiguration.setPageSize()<\/code> ).<\/li>\n<li>Pour chaque cache dont les donn\u00e9es doivent \u00eatre compress\u00e9es, il est n\u00e9cessaire de configurer la m\u00e9thode de compression et (facultativement) le niveau de compression dans la configuration (m\u00e9thodes <code>CacheConfiguration.setDiskPageCompression(), CacheConfiguration.setDiskPageCompressionLevel()<\/code>).<\/li>\n<\/ul>\n<p><\/p>\n<h3>Compactage WAL<\/h3>\n<p><\/p>\n<h4>Comment cela fonctionne<\/h4>\n<p>\nQu'est-ce que le WAL et \u00e0 quoi sert-il ? En r\u00e9sum\u00e9 : c'est un journal o\u00f9 se trouvent tous les \u00e9v\u00e9nements modifiant finalement le stockage page. Il est n\u00e9cessaire principalement pour permettre la r\u00e9cup\u00e9ration en cas de panne. Toute op\u00e9ration, avant de restituer le contr\u00f4le \u00e0 l'utilisateur, doit d'abord enregistrer un \u00e9v\u00e9nement dans le WAL pour, en cas de panne, pouvoir rejouer les journaux et r\u00e9cup\u00e9rer toutes les op\u00e9rations pour lesquelles l'utilisateur a re\u00e7u une r\u00e9ponse r\u00e9ussie, m\u00eame si ces op\u00e9rations n'ont pas eu le temps de se refl\u00e9ter dans le stockage page sur le disque (comme d\u00e9j\u00e0 mentionn\u00e9, l'enregistrement effectif dans le stockage page se fait dans un processus appel\u00e9 \u00ab point de contr\u00f4le \u00bb avec un certain retard par des threads distincts).<\/p>\n<p>Les enregistrements dans le WAL se divisent en enregistrements logiques et physiques. Les logiques sont les cl\u00e9s et les valeurs elles-m\u00eames. Les physiques refl\u00e8tent les changements des pages dans le stockage page. Alors que les enregistrements logiques peuvent \u00e9galement \u00eatre utiles dans d'autres cas, les enregistrements physiques sont n\u00e9cessaires uniquement pour la r\u00e9cup\u00e9ration en cas de panne et ne concernent que les enregistrements depuis le dernier point de contr\u00f4le r\u00e9ussi. Nous n'allons pas entrer ici dans les d\u00e9tails et expliquer pourquoi cela fonctionne de cette mani\u00e8re, mais ceux qui sont int\u00e9ress\u00e9s peuvent se r\u00e9f\u00e9rer \u00e0 l'article d\u00e9j\u00e0 mentionn\u00e9 sur le Wiki d'Apache Ignite : <noindex><a rel=\"nofollow\" href=\"https:\/\/cwiki.apache.org\/confluence\/display\/IGNITE\/Ignite+Persistent+Store+-+under+the+hood\">Ignite Persistent Store \u2014 sous le capot<\/a><\/noindex>.<\/p>\n<p>Souvent, une seule entr\u00e9e logique correspond \u00e0 plusieurs enregistrements physiques. Par exemple, une op\u00e9ration de mise \u00e0 jour (put) dans le cache affecte plusieurs pages dans la m\u00e9moire pagin\u00e9e (la page contenant les donn\u00e9es, les pages avec des index et les pages avec des listes de pages libres). Dans certains tests synth\u00e9tiques, j'ai observ\u00e9 que les enregistrements physiques pouvaient repr\u00e9senter jusqu'\u00e0 90 % du volume du fichier WAL. Pourtant, ils ne sont n\u00e9cessaires que tr\u00e8s bri\u00e8vement (par d\u00e9faut, l'intervalle entre les points de contr\u00f4le est de 3 minutes). Il serait logique de se d\u00e9barrasser de ces donn\u00e9es apr\u00e8s qu'elles aient perdu leur pertinence. C'est pr\u00e9cis\u00e9ment ce que fait le m\u00e9canisme de compaction WAL, en se d\u00e9barrassant des enregistrements physiques et en compressant avec zip les enregistrements logiques restants, ce qui r\u00e9duit consid\u00e9rablement la taille du fichier (parfois jusqu'\u00e0 plusieurs dizaines de fois).<\/p>\n<p>Le WAL physique est compos\u00e9 de plusieurs segments (par d\u00e9faut 10) de taille fixe (par d\u00e9faut 64 Mo) qui sont \u00e9cras\u00e9s en boucle. Une fois que le segment actuel est rempli, le segment suivant lui est attribu\u00e9, et le segment rempli est copi\u00e9 dans l'archive par un flux s\u00e9par\u00e9. La compaction du WAL fonctionne d\u00e9j\u00e0 avec les segments archiv\u00e9. De plus, par un flux distinct, elle suit l'ex\u00e9cution des points de contr\u00f4le et commence la compression des segments archiv\u00e9s, les enregistrements physiques pour lesquels ne sont plus n\u00e9cessaires.<\/p>\n<p><img decoding=\"async\" alt=\"Compression des donn\u00e9es dans Apache Ignite. Exp\u00e9rience de Sber\" src=\"\/wp-content\/uploads\/2020\/05\/ca8690ba7a350df9530f2ccf01c90975.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Impact sur la performance<\/h4>\n<p>\n\u00c9tant donn\u00e9 que la compaction du WAL fonctionne par un flux s\u00e9par\u00e9, il ne devrait pas y avoir d'impact direct sur les op\u00e9rations en cours. Cependant, cela engendre une charge suppl\u00e9mentaire en arri\u00e8re-plan sur le CPU (compression) et sur le disque (lecture de chaque segment de WAL depuis l'archive et \u00e9criture des segments compress\u00e9s). Par cons\u00e9quent, si le syst\u00e8me fonctionne \u00e0 pleine capacit\u00e9, cela entra\u00eenera \u00e9galement une d\u00e9gradation des performances.<\/p>\n<h4>Comment activer et configurer<\/h4>\n<p>\nLa compaction du WAL peut \u00eatre activ\u00e9e avec la propri\u00e9t\u00e9 <code>WalCompactionEnabled<\/code> dans <code>DataStorageConfiguration (DataStorageConfiguration.setWalCompactionEnabled(true)<\/code>). De plus, avec la m\u00e9thode DataStorageConfiguration.setWalCompactionLevel(), vous pouvez d\u00e9finir le niveau de compression si la valeur par d\u00e9faut (BEST_SPEED) ne vous convient pas.<\/p>\n<h3>Compression des instantan\u00e9s de page WAL<\/h3>\n<p><\/p>\n<h4>Comment cela fonctionne<\/h4>\n<p>\nNous avons d\u00e9j\u00e0 \u00e9tabli que les enregistrements WAL se divisent en enregistrements logiques et physiques. Pour chaque modification d'une page dans la m\u00e9moire des pages, un enregistrement physique WAL est cr\u00e9\u00e9. Les enregistrements physiques, \u00e0 leur tour, se divisent en deux sous-types : l'enregistrement de snapshot de page et l'enregistrement delta. Chaque fois que nous modifions quelque chose sur la page et que nous la transformons d'un \u00e9tat propre \u00e0 un \u00e9tat sale, une copie compl\u00e8te de cette page est conserv\u00e9e dans le WAL (l'enregistrement de snapshot de page \u2014 le snapshot de la page). M\u00eame si nous ne changeons qu'un seul octet, le WAL sauvegardera un enregistrement l\u00e9g\u00e8rement sup\u00e9rieur \u00e0 la taille de la page. Si nous modifions quelque chose sur une page d\u00e9j\u00e0 sale, un enregistrement delta est cr\u00e9\u00e9 dans le WAL, o\u00f9 seules les modifications par rapport \u00e0 l'\u00e9tat pr\u00e9c\u00e9dent de la page sont refl\u00e9t\u00e9es, mais pas la page enti\u00e8re. \u00c9tant donn\u00e9 que le r\u00e9tablissement des pages de l'\u00e9tat sale \u00e0 l'\u00e9tat propre se produit lors du processus de checkpoint, presque tous les enregistrements physiques consisteront uniquement en snapshots de pages imm\u00e9diatement apr\u00e8s le d\u00e9but du checkpoint (puisque toutes les pages sont imm\u00e9diatement propres apr\u00e8s le d\u00e9but du checkpoint). Ensuite, \u00e0 mesure que nous nous rapprochons du prochain checkpoint, la proportion d'enregistrements delta commence \u00e0 augmenter et revient \u00e0 z\u00e9ro au d\u00e9but du prochain checkpoint. Des mesures sur certains tests synth\u00e9tiques ont montr\u00e9 que la proportion de snapshots de pages dans le volume total des enregistrements physiques atteint 90%.<\/p>\n<p>L'id\u00e9e de la compression des snapshots de page WAL consiste \u00e0 compresser les snapshots de pages en utilisant un outil de compression de pages d\u00e9j\u00e0 disponible (voir compression des pages disque). Dans ce cas, les enregistrements WAL sont conserv\u00e9s de mani\u00e8re s\u00e9quentielle en mode append-only et il n'y a pas besoin d'ancrer les enregistrements aux limites des blocs du syst\u00e8me de fichiers. Ainsi, contrairement au m\u00e9canisme de compression des pages disque, nous n'avons pas besoin de fichiers \u00e9pars, ce qui signifie que ce m\u00e9canisme fonctionnera non seulement sur les syst\u00e8mes d'exploitation Linux. De plus, il n'est plus important de savoir dans quelle mesure nous avons pu compresser une page. M\u00eame si nous avons lib\u00e9r\u00e9 1 octet, c'est d\u00e9j\u00e0 un r\u00e9sultat positif et nous pouvons sauvegarder des donn\u00e9es compress\u00e9es dans le WAL, contrairement \u00e0 la compression des pages disque, o\u00f9 nous ne sauvegardons une page compress\u00e9e que si nous avons lib\u00e9r\u00e9 plus d'un bloc du syst\u00e8me de fichiers.<\/p>\n<p>Les pages sont des donn\u00e9es hautement compressibles, et leur part dans le volume total du WAL est tr\u00e8s \u00e9lev\u00e9e. En ne modifiant pas le format du fichier WAL, nous pouvons obtenir une r\u00e9duction significative de sa taille. La compression des enregistrements logiques n\u00e9cessiterait un changement de format et entra\u00eenerait une perte de compatibilit\u00e9, notamment pour les consommateurs externes qui pourraient \u00eatre int\u00e9ress\u00e9s par les enregistrements logiques, sans apporter de r\u00e9duction importante de la taille du fichier.<\/p>\n<p>Comme pour la compression des pages disque, des algorithmes de compression tels que ZSTD, LZ4, Snappy, ainsi que le mode SKIP_GARBAGE, peuvent \u00eatre utilis\u00e9s pour la compression des instantan\u00e9s de page WAL.<\/p>\n<h4>Impact sur la performance<\/h4>\n<p>\nIl est facile de remarquer que l'activation directe de la compression des instantan\u00e9s de page WAL n'affecte que les flux qui \u00e9crivent des donn\u00e9es en m\u00e9moire page, c'est-\u00e0-dire les flux qui modifient des donn\u00e9es dans les caches. La lecture des enregistrements physiques du WAL se fait uniquement une fois, lors du red\u00e9marrage du n\u0153ud apr\u00e8s un crash (et uniquement en cas de crash pendant le processus de checkpoint).<\/p>\n<p>L'impact sur les flux qui modifient les donn\u00e9es est le suivant : nous avons un effet n\u00e9gatif (CPU) en raison de la n\u00e9cessit\u00e9 de compresser chaque page avant de l'\u00e9crire sur le disque, et un effet positif (disque IO) gr\u00e2ce \u00e0 la r\u00e9duction de la quantit\u00e9 de donn\u00e9es \u00e9crites. Par cons\u00e9quent, ici c'est simple : si les performances du syst\u00e8me sont limit\u00e9es par le CPU, nous avons une l\u00e9g\u00e8re d\u00e9gradation, si elles sont limit\u00e9es par l'IO disque, nous avons un gain.<\/p>\n<p>Indirectement, la r\u00e9duction de la taille du WAL affecte \u00e9galement (positivement) les flux qui archivent les segments WAL et ceux de la compactage du WAL.<\/p>\n<p>Des tests de performance r\u00e9els dans notre environnement avec des donn\u00e9es synth\u00e9tiques ont montr\u00e9 un l\u00e9ger gain (le d\u00e9bit a augment\u00e9 de 10 \u00e0 15 %, la latence a diminu\u00e9 de 10 \u00e0 15 %).<\/p>\n<h4>Comment activer et configurer<\/h4>\n<p>\nVersion minimale d'Apache Ignite : 2.8. L'activation et la configuration se font de la mani\u00e8re suivante :<\/p>\n<ul>\n<li>Le class-path doit inclure le module ignite-compression. Par d\u00e9faut, il se trouve dans la distribution d'Apache Ignite dans le r\u00e9pertoire libs\/optional et n'est pas inclus dans le class-path. Vous pouvez simplement d\u00e9placer le r\u00e9pertoire d'un niveau vers le haut dans libs, et alors lors du lancement via ignite.sh, il sera automatiquement inclus.<\/li>\n<li>La persistance doit \u00eatre activ\u00e9e (S'active via <code>DataRegionConfiguration.setPersistenceEnabled(true)<\/code>).<\/li>\n<li>Le mode de compression doit \u00eatre d\u00e9fini \u00e0 l'aide de la m\u00e9thode <code>DataStorageConfiguration.setWalPageCompression()<\/code>, par d\u00e9faut, la compression est d\u00e9sactiv\u00e9e (mode DISABLED).<\/li>\n<li>Il est \u00e9galement possible de d\u00e9finir le degr\u00e9 de compression \u00e0 l'aide de la m\u00e9thode <code>DataStorageConfiguration.setWalPageCompression()<\/code>, les valeurs autoris\u00e9es pour chacun des modes sont \u00e0 consulter dans la javadoc de la m\u00e9thode.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Conclusion<\/h3>\n<p>\nLes m\u00e9canismes de compression de donn\u00e9es examin\u00e9s dans Apache Ignite peuvent \u00eatre utilis\u00e9s ind\u00e9pendamment les uns des autres, mais toutes leurs combinaisons sont \u00e9galement acceptables. Comprendre les principes de leur fonctionnement permettra de d\u00e9terminer \u00e0 quel point ils conviennent \u00e0 vos t\u00e2ches dans votre environnement et ce avec quoi il faudra faire des sacrifices lors de leur utilisation. La compression des pages disque est destin\u00e9e \u00e0 compresser le stockage principal et peut offrir un taux de compression moyen. La compression des instantan\u00e9s des pages WAL offrira un taux de compression moyen des fichiers WAL, tout en augmentant probablement les performances. La compaction WAL n'aura pas d'effet positif sur les performances, mais r\u00e9duira au maximum la taille des fichiers WAL en supprimant les enregistrements physiques.<br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/sberbank\/blog\/502136\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438 \u0440\u0430\u0431\u043e\u0442\u0435 \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c\u0438 \u043e\u0431\u044a\u0435\u043c\u0430\u043c\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u0438\u043d\u043e\u0433\u0434\u0430 \u043c\u043e\u0436\u0435\u0442 \u043e\u0441\u0442\u0440\u043e \u0432\u0441\u0442\u0430\u0442\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u043d\u0435\u0445\u0432\u0430\u0442\u043a\u0438 \u043c\u0435\u0441\u0442\u0430 \u043d\u0430 \u0434\u0438\u0441\u043a\u0430\u0445. \u041e\u0434\u043d\u0438\u043c \u0438\u0437 \u0441\u043f\u043e\u0441\u043e\u0431\u043e\u0432 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u0430\u043d\u043d\u043e\u0439 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u0436\u0430\u0442\u0438\u0435, \u0431\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u043a\u043e\u0442\u043e\u0440\u043e\u043c\u0443, \u043d\u0430 \u0442\u043e\u043c \u0436\u0435 \u043e\u0431\u043e\u0440\u0443\u0434\u043e\u0432\u0430\u043d\u0438\u0438, \u043c\u043e\u0436\u043d\u043e \u0441\u0435\u0431\u0435 \u043f\u043e\u0437\u0432\u043e\u043b\u0438\u0442\u044c \u0443\u0432\u0435\u043b\u0438\u0447\u0438\u0442\u044c \u043e\u0431\u044a\u0435\u043c\u044b \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f. \u0412 \u0434\u0430\u043d\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u0441\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u0431\u0443\u0434\u0443\u0442 \u043e\u043f\u0438\u0441\u0430\u043d\u044b \u0442\u043e\u043b\u044c\u043a\u043e \u0440\u0435\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0432\u043d\u0443\u0442\u0440\u0438 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":81937,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-81936","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u041e\u043f\u044b\u0442 \u0421\u0431\u0435\u0440\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-05-17T23:42:37+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-05-17T23:42:37+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Compression de donn\u00e9es dans Apache Ignite. Exp\u00e9rience de Sber | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u0436\u0430\u0442\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 \u0432 Apache Ignite. \u041e\u043f\u044b\u0442 \u0421\u0431\u0435\u0440\u0430 | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/szhatie-dannyh-v-apache-ignite-opyt-sbera","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-05-17T23:42:37+00:00","article:modified_time":"2020-05-17T23:42:37+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"81936","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:47:30","updated":"2022-10-02 17:21:32","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/81936","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=81936"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/81936\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/81937"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=81936"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=81936"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=81936"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}