0
votes

Comment accélérer la commande grep / awk?

Je vais traiter le fichier texte (> 300 Go) et le diviser en petits fichiers texte (~ 1 Go). Je veux accélérer les commandes Grep / Awk.

J'ai besoin de grep la ligne qui a des valeurs sur la colonne B, voici mes façons: p> xxx pré>

les deux moyens de coût 1min pour chaque fichier. Alors, comment puis-je accélérer cette opération? P>


échantillon de fichier d'entrée: p> xxx pré>

fichier de sortie attendu: p>

a,b,c,d
1,4a337485,2,54
4,2a4645647,4,56
6,5a3489556,3,22
24,4a83944,3,22


6 commentaires

Les autres colonnes peuvent-elles être vides? Si ce n'est pas fgrep -v ',' Entrée devrait donner des performances légèrement meilleures que grep -e .


Question muette ... Pourquoi utilisez-vous la coquille? Si la performance est une préoccupation due aux grandes données, pourquoi ne pas écrire le programme C optimisé? (Je suppose que vous allez le faire plus d'une fois).


D'où vient les données? Comment tu l'as obtenu? Quelles données réelles ces énormes fichiers contiennent-ils? Comment avez-vous exécuté vos points de repère? S'il vous plaît Modifier Votre question pour l'améliorer (que j'ai voté pour fermer, depuis trop large et peu claire)


@infaak, IMHO, à la première place, vous devez avoir un mécanisme de rotation du journal afin de ne pas avoir d'énormes fichiers de taille dans votre boîte (sauf s'il s'agit d'un fichier de données et que vous avez des données utilisateur, que je doute), vous sauvera vraiment tout autre problème d'espace. Des problèmes inutiles aussi.


Vous mentionnez que vous souhaitez traiter un fichier 300 Go et le diviser en fichiers plus petits. La question que vous demandez semble faire partie d'un programme plus grand qui conviendrait à la scission. Si cela est vrai, je suis convaincu qu'avec un célibataire, nous pouvons diviser les 300 Go en fichiers plus petits avec une seule lecture. Nous devons toutefois comprendre les conditions pour cela.


Lorsque vous dites coûte 1min pour chaque fichier - voulez-vous dire pour chaque fichier d'entrée ou pour chaque fichier de sortie? Si ce dernier, comment savez-vous que donner 1 appel à 1 outil doit produire tous vos fichiers de sortie à 1 fois? Je me sens comme si vous appelez probablement AWK (ou GREP) dans une boucle et c'est votre problème plutôt que de la rapidité avec laquelle la commande AWK est exécutée. De plus, si vous vous souciez de la performance, cela implique que c'est quelque chose que vous devez faire à plusieurs reprises - vous voudrez peut-être réparer tout ce qui générerait ces énormes fichiers au lieu de mettre après une aide à la bande.


3 Réponses :


2
votes

Utilisez Mawk, Éviter Regex et faire: S>

$ time mawk -F, '$2~/a/' file > /dev/null

real    0m3.672s
user    0m3.600s
sys     0m0.068s


1 commentaires

Oh, votre définition de a des valeurs sur la colonne B est différente de la mienne (remarquez votre ligne d'en-tête, cependant). Mawk -f, '$ 2! = "" && $ 2! = 0' Fichier corrigez-le pour cette entrée, mais si vous voulez uniquement des enregistrements où le champ B a A , Utilisez: Mawk -f, '$ 2 ~ / A / fichier`.



3
votes

Comment accélérer la commande grep / awk? p>

Êtes-vous si sûr que grep code> ou awk code> est le coupable de votre lenteur perçue? Connaissez-vous sur CUT (1) ou sed (1) ? Avez-vous comparé le temps d'exécuter wc (1) sur vos données? Probablement les E / S textuels prennent beaucoup de temps. P>

Veuillez indiquer plusieurs fois em> et utilisez heure (1) pour comparer votre programme. P>

J'ai un bureau de Debian haut de gamme (avec une AMD 2970WX, 64 Go de RAM, disque SSD de 1TBYTE SSD, disques de données SATA multi-téraabyte 7200RPM) et il suffit d'exécuter wc code> sur un fichier de 25 gbyte (certains *. TAR.XZ CODE> Archives) Assis sur un disque dur prend plus de 10 minutes (mesuré avec temps code>), et wc code> fait du vraiment simple textuel em> traitement en lisant ce fichier séquentiellement em> devrait fonctionner plus vite que grep code> (mais, à ma surprise, ne le fait pas!) ou awk code> sur le même em> Données: P> xxx pré>

et (en utilisant grep code> sur le fichier même em> fichier à compter les occurrences de A code >) P>

grep -c a /big/basile/backup.tar.xz  38.30s user 7.60s system 33% cpu 2:17.06 total


1 commentaires

Ceci est passé votre point valide, mais que wc a l'air si terrible je viens de le voir moi-même. J'ai eu un fichier JSON de 9 Go pour lequel temps wc produit réel 2m51.558s qui correspond à votre observation. Cependant, temps mawk '{nf + = nf; l + = longueur () + 1} fin {printf "% d% d% d% .0f", nr, nf, l}' produit réel 1m0.348s qui était un type de surprenant car j'attendais wc étant un outil de but spécial pour dépasser Mawk.



0
votes

Je soupçonne que votre vrai problème est que vous appelez Awk à plusieurs reprises (probablement dans une boucle), une fois par ensemble de valeurs de 2 $ et générant un fichier de sortie à chaque fois, par exemple: xxx pré>

Ne faites pas cela car il est très inefficace puisqu'il lise tout le dossier sur chaque itération. Faites cela à la place: P>

sort -t, -k2,2 -s


0 commentaires