Java a lu le dossier énorme (~100GB) efficacement


Je voudrais lire un énorme fichier binaire ( ~100 Go ) efficacement en Java. J'ai à traiter chaque ligne . Le traitement de ligne sera dans des threads séparés. Je ne veux pas charger le fichier entier en mémoire. La lecture de morceaux de travail? Quelle sera la taille optimale du tampon? N'importe quelle formule pour qui?

Author: Vivek, 2016-12-05

1 answers

S'il s'agit d'un fichier binaire, la lecture en "lignes" n'a pas beaucoup de sens.

Si le fichier est vraiment binaire, utilisez un BufferedInputStream et lisez les octets un à la fois dans byte[]. Lorsque vous arrivez à l'octet qui marque votre fin de "ligne", ajoutez le byte[] et le nombre d'octets de la ligne à une file d'attente pour que vous traitiez les threads de travail.

Et répétez.

Conseils:

  • Utilisez un tampon borné au cas où vous pouvez lire des lignes plus rapidement que vous ne pouvez traiter ils.
  • Recycler les objets byte[] pour réduire la génération de déchets.

Si le fichier est (vraiment) du texte, vous pouvez utiliser BufferedReader et la méthode readLine() au lieu d'appeler read().


Ce qui précède vous donnera une performance raisonnable. Selon la quantité de travail à faire pour traiter chaque ligne, il peut être assez bon pour qu'il ne soit pas utile d'optimiser la lecture du fichier. Vous pouvez vérifier cela en profilant.

Si vous profilez vous dit que la lecture est le goulot d'étranglement, puis envisager d'utiliser NIO avec ByteBuffer ou CharBuffer. C'est plus compliqué, mais potentiellement plus rapide que read() ou readLine().


La lecture en morceaux fonctionne-t-elle?

BufferedReader ou BufferedInputStream lisent tous deux en morceaux, sous les couvertures.

Quelle sera la taille optimale du tampon?

Ce n'est probablement pas si important quelle est la taille du tampon. Je lui ferais quelques Ko ou des dizaines de Ko.

Toute formule pour qui?

Non il n'y a pas de formule pour une taille de tampon optimale. Cela dépendra de variables que vous ne pouvez pas quantifier.

 3
Author: Stephen C, 2016-12-05 11:27:47