ZStandard, la compression Facebook standard qui n'est pas si standard.

Il arrive très fréquemment lors de nos activités ponctuelles de support système dans des entreprises externes (entreprises qui ont déjà leurs ingénieurs système dans l'entreprise mais qui peuvent demander de l'aide sur quelque chose de spécifique) de tomber sur des scripts shell (généralement pour la version bash) qui utilisent la sauvegarde et procédures et routines de stockage.

En plus des diverses horreurs vues comme celles qui font des sauvegardes avec rsync ou rsnapshot au lieu d'utiliser le moderne Borg Archiver, ou ceux qui restaient encore en 1996 qui croient que pour faire une sauvegarde d'une base de données MySQL de 40 Go, il suffit d'utiliser mysqldump plutôt que l'excellent Percona XtraBackup dont nous avons parlé dans cet article : Sauvegarde MySQL lente et serveur en panne lorsque Google passe, une erreur STANDARD (nous utiliserons souvent ce mot dans cet article) que nous remarquons est celui de l'ingénieur système qui prétend faire du stockage d'archives en utilisant le classique et désormais obsolète et obsolète tar.gz selon le format nomearchivio.tar.gz

Le problème de la compression des données

La compression des données est un gros problème. C'est l'un des problèmes les plus anciens et les plus étudiés en informatique. Facebook a développé son propre algorithme de compression appelé ZStandard ou "zstd" qui peut être plus rapide et plus efficace que d'autres algorithmes de compression tels que gzip, tar et bzip2.

Ils ont tous tort.

Et par tous aujourd'hui, nous entendons vraiment tout le monde. Allez lire les scripts de votre ingénieur système dans l'entreprise ou interrogez-le sur l'histoire, et vous ne pourrez qu'être d'accord avec nous.

La raison est assez facile à expliquer, étant une combinaison de facteurs : l'ingénieur système n'écrit souvent pas ses propres scripts (et nous non plus) mais "se limite" à chercher quelque chose de prêt à personnaliser, sur un site comme StackOverflow par exemple. Ces exemples sont souvent générés par d'autres ingénieurs systèmes qui à leur tour sont partis d'une base commune qui très souvent sont des bases archaïques communes (1990 - 2000 environ), notamment pour ce qui concerne les systèmes Linux qui ont eux aussi hérité de scripts de gestion d'anciens" frères" tels que les systèmes UNIX.

Il en serait autrement pour ceux qui recherchent des démonstrations sur React, node js ou Angular js par exemple qu'étant - pour l'instant - de nouveaux langages, ils ne pourraient pas pour des raisons logiques évidentes avoir des exemples et de la documentation "obsolète" au sens le plus littéral du terme .

Une autre raison pratique pour laquelle vous continuez à utiliser le .tar.gz habituel est que cela fonctionne réellement, et ce n'est pas rien d'avoir quelque chose qui fonctionne de nos jours.

L'ingénieur système en tant que figure professionnelle peut s'ennuyer et être démotivé s'il n'est pas animé par une réelle passion et/ou un gros salaire, c'est pourquoi la plupart se limitent à faire leur travail d'une manière qui soit fonctionnelle aux objectifs commerciaux de l'entreprise, mais pas le plus fonctionnel.

En outre, il n'arrive pas souvent qu'un ingénieur système (sauf si vous travaillez pour un centre de données avec des milliers de machines) doive gérer la compression des données et en faire un problème. Une PME italienne normale compte de 3 à 10 employés, sans parler de la problématique de cette base de données de 1 Go de clients et de fournisseurs. Bref, nul besoin d'entrer dans une logique opérationnelle pour maximiser les profits tout en minimisant les coûts.

Sulle grandi realtà con centinaia o migliaia di dipendenti il tutto viene gestito in outsourcing o alla solita società di consulenza magari con 2 o 3 subappalti, o al grande gruppo multinazionale di consulenza che prende in mano la gestione senza spiegare ne troppo il perchè ne troppo il comme, comment. Le fait est que dans ces très nobles cabinets de conseil, on voit rarement des ingénieurs systèmes seniors dépasser les 2 mille euros/mois de salaire mensuel et cet aspect en dit aussi long sur la motivation qu'un être humain peut mettre dans quelque chose qui est consciemment vécu comme une exploitation . .

Enfin, avouons-le, même les ingénieurs système les plus courageux qui aiment l'expérimentation et s'aventurent comme un Indiana Jones expérimenté à la recherche du compresseur de données perdu, après quelques faux positifs, arrêtez tout et revenez au classique .tar.gz

Parce que même lorsque vous allez tester d'autres alternatives, vous arrivez presque toujours à évaluer et à tester les bzip, px, rar, zip habituels et à la fin des tests, vous arrivez toujours à quelques conclusions :

1. Le logiciel fait bien son boulot en compressant "assez" mais avec une compression et/ou un temps CPU très élevé.
2. Le logiciel est assez rapide mais il ne me sauve aucune donnée par rapport à mon .tar.gz

Raison pour laquelle à la fin des jeux il vous reste un .tar.gz et tous les scripts système calibrés sur cette technologie.

ZStandard, compression de données made in Facebook

C'est toujours un plaisir de pouvoir embrasser ou simplement étudier des technologies produites par de grandes actions technologiques telles que Facebook, car cela dénote immédiatement de grandes idées suivies d'une exécution impeccable. Avec les meilleurs ingénieurs du marché et d'importants investissements économiques en recherche et développement, c'est toujours une garantie.

Zstandard, ou zstd pour sa version abrégée, est un algorithme de compression rapide sans perte, qui vise des scénarios de compression en temps réel de niveau zlib et des taux de compression bien meilleurs.

Il offre une très large gamme de compromis entre compression et débit, tout en étant épaulé par un décodeur très rapide. Il offre également un mode spécial pour les petites données, appelé compression de dictionnaire, et peut créer des dictionnaires à partir de n'importe quel ensemble d'échantillons.

Facebook a ouvert Zstandard il y a près de six ans dans le but de surpasser Zlib en termes de rapidité et d'efficacité. Zstandard 1.5 améliore la vitesse de compression à des niveaux de compression intermédiaires, le taux de compression à des niveaux plus élevés et apporte une vitesse de décompression plus rapide.

zstandard prend en charge les niveaux de compression jusqu'à 22. Grâce à un nouveau chercheur de correspondance prédéfini, Zstardard 1.5 atteint un taux de compression plus élevé pour les niveaux entre 5 et 12 et les entrées supérieures à 256K. Selon les benchmarks de Facebook, les améliorations vont de +25% à +140% sans pertes significatives en termes de taux de compression. 

Facebook revendique des résultats encore meilleurs sur des machines fortement chargées en cas de conflit de cache important.

En plus d'améliorer les performances de compression, Zstandard 1.5 est compilé par défaut avec un support multithread, standardise certaines nouvelles API et déprécie un certain nombre d'anciennes. Vous pouvez trouver tous les détails dans les notes de version officielles.

En fait, Zstandard a été créé par Yann Collet chez Facebook et est utilisé dans l'environnement de production de Facebook depuis 2015.

En plus de l'outil de ligne de commande, Zstandard est fourni sous forme de bibliothèque pour que vous puissiez l'intégrer facilement dans vos projets.

La bibliothèque Zstandard est fournie en tant que logiciel open source utilisant une licence BSD.

Veuillez vous référer au lien Facebook officiel qui peut vous présenter non seulement le projet mais l'énorme polyvalence du projet lui-même qui a été adopté par une mer d'autres projets :.

5 façons dont Facebook a amélioré la compression à grande échelle avec Zstandard

Sauvegardes plus rapides

L'un des principaux avantages de zstd est qu'il peut compresser les données en paquets plus petits plus rapidement que les autres algorithmes, ce qui accélère les sauvegardes. De nombreuses entreprises ont des téraoctets de données à sauvegarder chaque jour, donc tout moyen d'accélérer les sauvegardes est une grande victoire pour elles.

Selon les benchmarks de Facebook, Zstandard surpasse zlib pour toute combinaison de taux de compression et de bande passante.

En particulier, Zstandard a montré des performances exceptionnelles par rapport à zlib lors de l'utilisation de la compression standard sans perte :

• il était environ 3 à 5 fois plus rapide au même taux de compression
• produit des fichiers 10 à 15 % plus petits au même taux de compression
• il décompresse 2x plus vite quel que soit le taux de compression
• il est adapté à un taux de compression beaucoup plus élevé (~ 4x contre ~ 3,15).

Zusages standards entropie un état fini, basé sur les travaux de Jarek Duda sui systèmes de nombres asymétriques (ANS) pour le codage entropique. ANS vise à "mettre fin au compromis entre vitesse et vitesse" et peut être utilisé à la fois pour un codage précis et un codage très rapide, avec prise en charge du cryptage des données. Mais derrière les meilleures performances de Zstandard se cachent un certain nombre d'autres choix de conception et d'implémentation :

• Alors que zlib est limité à une fenêtre de 32 Ko, Zstandard tire parti d'une plus grande disponibilité de mémoire dans les environnements modernes, y compris les environnements mobiles et embarqués, et n'impose aucune limitation inhérente.
• un nouveau décodeur Huffman, Huff0 , permet de décoder des symboles en parallèle grâce à plusieurs ALU réduire les dépendances de données entre les opérations arithmétiques
• Zstandard essaie d'être aussi dépourvu de branchement que possible, minimisant ainsi le rinçage coûteux des tuyaux dû à une prévision de branchement incorrecte. Par exemple, voici comment c'est whileIl est possible de réécrire une boucle sans utiliser de branches :

  /* classic version */
  while (nbBitsUsed >= 8) { /* each while test is a branch */
    accumulator <<= 8;
    accumulator += *byte++;
    nbBitsUsed  -= 8;
  }
  
  /* branch-less version */
  nbBytesUsed = nbBitsUsed >> 3;
  nbBitsUsed &= 7;
  ptr += nbBytesUsed;
  accumulator = read64(ptr);

• la modélisation repcode améliore considérablement la compression des séquences qui ne diffèrent que de quelques octets

Zstandard est à la fois un outil en ligne de commande et une bibliothèque, tous deux écrits en C. Il fournit plus de 20 niveaux de compression qui permettent d'optimiser avec précision son utilisation pour le matériel concret disponible, les données à compresser et les goulots d'étranglement à optimiser. Facebook recommande de commencer par le niveau 3 par défaut, qui convient à la plupart des cas, puis d'essayer des niveaux supérieurs jusqu'au niveau 9 pour assurer un compromis raisonnable entre la vitesse et l'espace, ou supérieur pour de meilleurs taux de compression., économisant plus de 20 niveaux pour les cas où vous ne vous souciez pas de la vitesse de compression.

Collet et Turner ont également fourni quelques conseils sur ce que les futures versions de Zstandard apporteront, y compris la prise en charge du multi-threading et de nouveaux niveaux de compression qui permettent des compressions plus rapides et des ratios plus élevés.

Faisons un vrai test

Au-delà de toutes les dissertations théoriques que l'on peut produire, ce qui compte pour un ingénieur système, c'est de pouvoir disposer d'un outil à usage humain et extrêmement efficace dans l'exercice de son métier.

On parle d'un système 6core/12 threads avec FS en RAID6 avec disques SATA et non nVME. L'utilitaire zstd a été installé sur CentOS7 via le référentiel REMI via : yum install zstd.

Nous avons donc réalisé cette documentation à partir de ce test qui cible le répertoire /var/lib/mysql d'un SGBD MariaDB tout à fait normal d'un de nos vrais clients.

Ce répertoire a une taille de 80 Go et est d'abord compressé par les utilitaires tar et gz, puis par l'utilitaire tar ztds.

Dans chaque phase de compression nous allons mesurer trois paramètres fondamentaux :

1. La syntaxe donnée de la commande
2. Le taux de compression
3. La taille de l'archive produite

Compression via tar et gzip

temps tar czvf test.tar.gz / var / lib / mysql

réel 19m19.862s

10.121.258.046 11 mars 16:28 test.tar.gz

Nous pouvons voir comment l'opération de compression a pris 19 minutes et 19 secondes et a produit un fichier de 10,12 gigaoctets

Compression via tar et zstd

temps tar –use-compress-program zstd -cf test.tar.zst / var / lib / mysql

réel 6m24.006s

5.727.249.564 11 16 47 XNUMX mars XNUMX:XNUMX test.tar.zst

Nous pouvons voir comment l'opération de compression a pris 6 minutes et 24 secondes et a produit un fichier de 5,7 gigaoctets

Conclusions de l'épreuve

Même si un seul test sur une base de données SQL et donc principalement du texte avec une forte redondance, les résultats sont sans appel, ZStandard a produit en à peine un tiers du temps par rapport à tar et gzip une archive qui pèse la moitié de celle produite avec tar et gzip.

Vous comprendrez à quel point il peut être important pour nos politiques de sauvegarde et de reprise après sinistre sur plus d'un millier de machines avec une conservation des données de 60 jours d'avoir un système rapide et efficace comme celui-ci.