Comparaison des bibliothèques de compression pour JavaVM
Plusieurs bibliothèques ont été collectées et testées pour la sélection d'algorithmes de compression réversible dans JavaVM (sources et nombres sur github). En conséquence, ma perception personnelle de l'algorithme de compression est la suivante.
| algorithme | type | Applications qui semblent convenir |
|---|---|---|
| Zstandard | Taux de compression élevé/Type de vitesse de traitement faible | Stockage et transfert de données basés sur des fichiers entre serveurs |
| lz4>Snappy | Faible taux de compression/Type de vitesse de traitement élevée | Débit élevé tel que le traitement en continu/Phases nécessitant une faible latence |
| bzip2 |
Taux de compression priorité absolue | Distribution d'énormes données et stockage de données froides |
| gzip |
La portabilité est la priorité absolue | Transfert de données et stockage à long terme |
En plus du standard Java GZIP et Deflate (ZIP), nous avons utilisé une bibliothèque qui implémente les algorithmes suivants. Voir build.sbt à la fin de la page pour chaque ID de référentiel Maven.
- ** Zstandard **: Le taux de compression est supérieur ou égal à gzip et inférieur à bzip2, mais nettement plus rapide qu'eux. Sans parler du gzip existant, bzip2 vaut également la peine de considérer Zstd, à moins que la différence de taille de quelques pour cent n'augmente le coût de l'entreprise. Réglable par niveau.
- ** lz4 **: équivalent à Snappy en taux de compression et plus avantageux que Snappy en termes de vitesse, donc lz4 est pour la priorité de vitesse de traitement.
- ** Brotl i **: Même avec des taux de compression élevés, il peut être l'un des meilleurs. La différence de vitesse entre la compression et la décompression est importante, et la vitesse de décompression est inférieure à Zstd mais plus rapide que gzip et bzip2. L'utilisation du mode UTF-8 rend la compression de texte plus efficace (non confirmée).
- ** Snappy **: Type à grande vitesse, mais inférieur à lz4 en termes de vitesse, donc il ne semble y avoir aucun virage particulier Je comprends qu'il s'agit d'une méthode de transfert lorsque lz4 ne peut pas être utilisé pour une raison quelconque.
Dans les benchmarks suivants, Block est la vitesse lors de l'utilisation de l'API byte [] to byte [] fournie par chaque bibliothèque, et Stream est lors de l'utilisation du standard Java ʻInputStream / ʻOutputStream. Le résultat.
Compression de données texte
Le premier exemple de fichier binaire est la [Déclaration d'indépendance] américaine (http://memory.loc.gov/cgi-bin/query/r?ammem/bdsdcc:@field%28DOCID+@lit%28bdsdcc02101%29%29) Le résultat du traitement de compression. Puisqu'il s'agit de US-ASCII, toutes les valeurs d'octets sont comprises entre 0x00-0x7F et l'entropie est faible. Brotli avait le taux de compression le plus élevé et lz4 avait la vitesse de traitement la plus élevée.
Ce qui suit est le résultat de l'utilisation du texte intégral du "Kokoro" de Soseki Natsume comme exemple. La représentation japonaise UTF-8 a un taux de compression plus élevé que le document us-ascii car chaque caractère est de 3 octets et le modèle est redondant.
En ce qui concerne les données textuelles, les caractéristiques du type à taux de compression élevé et du type à grande vitesse sont clairement indiquées. Brotli semble avoir un mode d'optimisation UTF-8, mais ce benchmark utilise le mode GENERAL pour la comparaison avec le type binaire.
Compression de données numériques
La figure ci-dessous est un exemple de ʻint [] ʻinitialisé avec un nombre aléatoire normal $ \ lfloor {\ rm Norm (\ mu = 0, \ sigma ^ 2 = 100)} \ rfloor $ avec des éléments de tableau arrangés en octets avec big endian. Binaire. Autrement dit, 68% de tous les éléments du tableau sont dans la plage $ \ pm 10 $ et 95% dans la plage $ \ pm 20 $. En d'autres termes, la plupart des valeurs sont des tableaux d'octets où les 3 octets à l'exclusion du 1 octet le moins significatif sont «0x00» ou «0xFF».
Le taux de compression de ces binaires est élevé et le type à taux de compression élevé réduit le taux de compression d'environ 70 à 80%. De plus, comme la différence avec le type à grande vitesse est réduite en termes de vitesse, la supériorité du type à grande vitesse est réduite.
La figure ci-dessous montre un échantillon compressé de double [], qui a généré une valeur avec le nombre aléatoire normal standard $ {\ rm Norm (\ mu = 0, \ sigma ^ 2 = 1)} $, dans un tableau d'octets au format IEEE 754. .. Pour les données à virgule flottante, même avec un type à taux de compression élevé, l'effet de compression était presque imprévisible à moins de 5%. En fait, l'entropie du binaire de l'échantillon est également élevée, et il semble que le tableau d'octets soit proche du cas où chaque valeur d'octet est générée par un nombre aléatoire uniforme.
La valeur négative de lz4 indique qu'il y a eu une légère augmentation de taille.