21 votes

Compression de plusieurs gros fichiers similaires

J'ai des centaines de gros fichiers similaires (30 mégaoctets chacun) que je veux compresser. Chaque paire de fichiers contient 99% des mêmes données (moins de 1% de différence), donc je m'attends à ne pas avoir plus de 40-50 mégaoctets d'archives.

Un fichier unique peut être compressé de 30 Mo à 13-15 Mo (avec xz -1 , gz -1 , bzip2 -1 ), mais lorsque je compresse deux fichiers ou plus, je veux avoir une archive de taille 13-15MB + N*0.3MB où N est le nombre de fichiers.

Lorsque vous utilisez tar (pour créer une archive solide) et xz -6 (pour définir le dictionnaire de compression comme étant plus grand qu'un fichier). Mise à jour - ce n'était pas suffisant ! ), j'ai toujours des archives avec la taille N*13MB .

Je pense que les deux gzip y bzip2 ne m'aideront pas car ils ont un dictionnaire de moins de 1 Mo, et mon flux tar a des répétitions tous les 30 Mo.

Comment puis-je archiver mon problème dans un Linux moderne en utilisant des outils standards ?

Est-il possible de régler xz pour compresser rapidement, mais utiliser un dictionnaire de plus de 30-60 MB ?

Mise à jour : A fait l'affaire avec tar c input_directory | xz --lzma2=dict=128M,mode=fast,mf=hc4 --memory=2G > compressed.tar.xz . Pas sûr de la nécessité de mf=hc4 y --memory=2G options ; mais dict=128M définir le dictionnaire pour qu'il soit suffisamment grand (plus grand qu'un fichier), et mode=fast rendre le processus un peu plus rapide que -e .

0 votes

Ejecutar xz -1 --memory=2G n'a pas aidé, testé sur 2 et 4 fichiers de l'ensemble.

14voto

woliveirajr Points 4110

Compte tenu de vos détails, je suppose que vous avez vérifié que vos fichiers ont réellement 99% de données en commun, avec un 1% contigu (ou presque) de différence entre eux.

Tout d'abord, vous devez utiliser tar pour créer une archive contenant vos fichiers. Pour les tests, je crée un .tar avec 10 fichiers, soit une taille de 300 Mo.

Ensuite, en utilisant xz, vous devez le paramétrer pour que le dictionnaire soit plus grand que la taille d'un fichier. Puisque vous ne dites pas si vous avez des restrictions de mémoire, je choisirais xz -9. Il n'y a aucun intérêt à ne pas utiliser toute la mémoire disponible.

J'utiliserais également le préréglage --extreme, pour tester si cela fait une différence.

Taille du dictionnaire

Dans une documentation que j'ai à ma disposition - site - il est dit que la taille du dictionnaire est à peu près égale à l'utilisation de la mémoire du décompresseur. Et le paramètre -1 signifie un dictionnaire de 1MiB, -6 signifie 10 MiB (ou 8 MiB dans une autre partie du même manuel). C'est pourquoi vous n'obtiendrez aucun avantage en regroupant ces fichiers. L'utilisation du -9 rendrait le décompacteur (et, ainsi, le dictionnaire) de 64 MiB, et je pense que c'est ce que vous vouliez.

Modifier

Une autre possibilité serait d'utiliser un autre compresseur. Je choisirais 7zip, mais je mettrais d'abord les fichiers sous forme de goudron avant de les compresser avec 7zip.

Selon le contenu de vos fichiers, vous pourriez peut-être utiliser 7zip avec la méthode PPM-D (au lieu de LZMA ou LZMA2, qui est la méthode par défaut et celle utilisée par xz).

Pas bon : Zip (dict = 32kB), Bzip (dict = 900 kB).

0 votes

Xz et 7-Zip utilisent tous deux LZMA2, il n'y a donc aucun avantage. PPMD est optimisé pour une extraction d'entropie extrêmement lente mais à haut taux de compression à partir de médias déjà compressés (par exemple, les MP3 et les vidéos). Il n'est pas particulièrement susceptible de trouver les grandes similitudes entre les deux fichiers et de les stocker dans le dictionnaire -- pas plus que LZMA2.

0 votes

Woliveirajr, qu'en est-il de l'utilisation de ne pas -1 o -9 préréglé, mais spécifiez dict=64MB o dict=128MB et mettre mode=fast ?

0 votes

Utiliser dict=xxMB au lieu de -1 ou -9 irait directement à l'essentiel, mais comme je ne sais pas comment xz définit d'autres paramètres lorsque vous utilisez uniquement le -9, je ne sais pas si vous ne manqueriez pas quelque chose d'autre. Je pense que vous êtes dans la bonne direction, et qu'un simple test vous donnera une réponse précise.

9voto

Giuseppe R Points 1325

S'ils sont vraiment similaires à 99% comme vous le dites, vous devriez pouvoir utiliser bsdiff ou un algorithme similaire pour calculer les différences entre les fichiers. Est-ce que la différence cumulatif (c'est-à-dire que chaque fichier diffère un peu plus du premier), ou la différence entre deux fichiers est-elle à peu près la même ?

S'il n'est pas cumulatif, vous devriez pouvoir le faire :

  • Prenez n'importe quel fichier arbitraire comme "ligne de base".
  • Exécuter bsdiff comparer le fichier de base à chaque fichier supplémentaire
  • Stocker chaque diff comme un fichier séparé, à côté du fichier de base.
  • Faites fonctionner un compresseur comme xz à travers les résultats (la ligne de base + les diffs).

Le résultat devrait être beaucoup plus petit que juste xz l'ensemble des archives.

Vous pouvez ensuite "reconstituer" les fichiers originaux en "appliquant" le diff sur la ligne de base pour faire sortir chacun des autres fichiers.

0 votes

Non cumulatif. (" Chaque paire de fichiers contient 99% des mêmes données... ")

1 votes

Si les différences ne sont pas cumulatives, alors cela devrait être une bonne application de l'approche de la bsdiff algorithme. Faites-en l'essai.

0 votes

Merci pour votre réponse, mais j'ai déjà fait la tâche avec xz : tar c directory|xz --lzma2=dict=128M,mode=fast et des fichiers d'entrée supprimés. En fait, mes fichiers d'entrée étaient du texte, donc je peux même utiliser diff au lieu de bsdiff (qui n'est pas installé sur mon PC).

5voto

osgx Points 6257

Vous (je) pouvez utiliser tar avec un archiveur capable de détecter des motifs à longue portée, par exemple, rzip o lrzip ( Readme ). Les deux utilisent la détection/dédoublonnage de la redondance à longue portée, puis rzip utilise bzip2 et lrzip utilise xz(lzma)/ZPAQ :

rzip est un programme de compression, similaire en termes de fonctionnalité à gzip ou bzip2, mais capable de tirer parti des redondances à longue distance dans les fichiers, ce qui permet parfois à rzip de produire des taux de compression bien meilleurs que les autres programmes. ... Le principal avantage de rzip est qu'il possède un tampon d'historique effectif de 900 Mbyte. Cela signifie qu'il peut trouver des morceaux correspondants du fichier d'entrée sur d'énormes distances par rapport à d'autres programmes de compression couramment utilisés. Le programme gzip, par comparaison, utilise un tampon d'historique de 32 kbyte et bzip2 utilise un tampon d'historique de 900 kbyte.

lrzip a une plus grande mémoire tampon et peut utiliser de nombreux algorithmes de compression (très rapide, rapide, bon, et l'un des meilleurs - ZPAQ) après la déduplication :

Lrzip utilise une version étendue de rzip qui effectue une première passe longue distance réduction de la redondance. Les modifications de lrzip le font évoluer en fonction de la taille de la mémoire.

Les données sont alors soit : 1. Compression par lzma (par défaut) qui donne une excellente compression. à environ deux fois la vitesse de la compression bzip2 ...

L'autre moyen est d'utiliser bup - programme de sauvegarde avec déduplication au niveau des blocs/segments, basé sur le packfile git :

Il utilise un algorithme de somme de contrôle mobile (similaire à rsync) pour diviser les gros fichiers en morceaux.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X