Accès aléatoire au fichier gzip en plusieurs parties (en Java)

Question

Cela peut tomber dans le domaine de "pas vraiment faisable" ou "ne vaut pas vraiment la peine" mais voilà.

J'essaie d'accéder de manière aléatoire aux enregistrements stockés dans un fichier gzip en plusieurs parties. Plus précisément, les fichiers qui m'intéressent sont les fichiers Arc compressés Heretrix. (Si vous n'êtes pas familier avec les fichiers gzip en plusieurs parties, la spécification gzip autorise la concaténation de plusieurs flux gzip dans un seul fichier gzip, qui ne partage aucune information de dictionnaire, mais un simple ajout binaire.)

Je pense qu'il devrait être possible de le faire en cherchant un certain décalage dans le fichier, puis rechercher les octets d'en-tête magiques gzip (ie 0x1f8b, comme RFC), et essayer de lire le flux gzip à partir des octets suivants . Le problème avec cette approche est que ces mêmes octets peuvent également apparaître dans les données réelles, donc la recherche de ces octets peut conduire à une position invalide pour commencer à lire un flux gzip. Existe-t-il un meilleur moyen de gérer l'accès aléatoire, étant donné que les compensations d'enregistrements ne sont pas connues a priori?

Answer 1

La conception de GZIP, comme vous l'avez compris, n'est pas conviviale pour un accès aléatoire.

Vous pouvez faire ce que vous décrivez, puis, si vous rencontrez une erreur dans le décompresseur, concluez que la signature que vous avez trouvée était en fait une donnée compressée.
Si vous avez terminé la décompression, il est facile de vérifier la validité du flux décompressé via le CRC32.

Si les fichiers ne sont pas trop volumineux, vous pouvez envisager de décomprimer uniquement toutes les entrées en série et de conserver les décalages des signatures afin de créer un répertoire. Lorsque vous décompressez, placez les octets dans un compartiment. À ce stade, vous aurez généré un répertoire, et vous pourrez ensuite prendre en charge l'accès aléatoire basé sur le nom de fichier, la date ou d'autres métadonnées.

Cela sera raisonnablement rapide pour les fichiers de moins de 100k. En guise de supposition, si vous aviez 10 fichiers d'environ 100k chacun, cela se ferait probablement en 2s sur un CPU moderne. C'est ce que je veux dire par "assez rapide". Mais vous seul connaissez les exigences de perf de votre application.

Avez-vous une classe GZipInputStream? Si c'est le cas, vous êtes à mi-chemin.

Answer 2

Le format de fichier BGZF, compatible avec GZIP a été développé par les biologistes.

(...) L'avantage de BGZF sur gzip classique est que BGZF permet de rechercher sans avoir pour parcourir le fichier entier jusqu'à la position recherchée.

En http://picard.svn.sourceforge.net/viewvc/picard/trunk/src/java/net/sf/samtools/util/, un coup d'oeil à BlockCompressedOutputStream et BlockCompressedInputStream.java