grep -f alternative pour les gros fichiers

Je ne pense pas qu'il y est une solution de facilité.

Imaginez que vous écrivez votre propre programme qui fait ce que vous voulez et vous allez vous retrouver avec une boucle imbriquée, où la boucle externe effectue une itération sur les lignes dans fichier2 l'intérieur de la boucle itère sur fichier1 (ou vice versa). Le nombre d'itérations augmente avec size(file1) * size(file2). Ce sera un très grand nombre lorsque les deux fichiers sont volumineux. Faire un fichier plus petit à l'aide de head apparemment résout ce problème, au prix de ne pas donner le résultat correct plus.

Une voie de sortie est de l'indexation (ou tri) d'un des fichiers. Si vous parcourez fichier2 et pour chaque mot, vous pouvez déterminer si oui ou non il est dans le fichier de modèle sans complet parcourir le fichier de modèle, alors vous êtes beaucoup mieux. Cela suppose que vous avez un mot-par-mot de comparaison. Si le fichier de modèle contient non seulement les mots, mais aussi des sous-chaînes, alors cela ne fonctionnera pas, parce que, pour un mot donné dans fichier2 vous ne savez pas quoi chercher dans fichier1.

L'apprentissage du SQL est certainement une bonne idée, parce que l'apprentissage de quelque chose est toujours bon. Il hovever, de ne pas résoudre votre problème, parce que SQL va souffrir de la même quadratique effets décrits ci-dessus. Il peut simplifier l'indexation, l'indexation devrait être applicable à votre problème.

Votre meilleur pari est probablement prendre un peu de recul et de repenser votre problème.

OriginalL'auteur Martin Drautzburg

Grep ne peut pas gérer de nombreuses questions, et à ce volume, il ne sera pas aidé par la fixation de la grep -f bug qui le rend si insupportablement lent.

Sont à la fois fichier1 et fichier2 composé d'un seul mot par ligne? Cela signifie que vous êtes à la recherche pour les correspondances exactes, nous pouvons le faire très rapidement avec awk:

awk 'NR == FNR { query[$0] = 1; next } query[$0]' file1 file2

NR (nombre de dossiers, le numéro de la ligne) n'est égale qu'à la FNR (fichier spécifique nombre d'enregistrements) pour le premier fichier, où nous remplir de la table de hachage, puis passer à la ligne suivante. La deuxième clause de vérifications de l'autre fichier(s) pour savoir si la ligne correspond à celui enregistré dans notre base de hachage, puis imprime les lignes correspondants.

Sinon, vous aurez besoin pour effectuer une itération:

awk 'NR == FNR { query[$0]=1; next }
     { for (q in query) if (index($0, q)) { print; next } }' file1 file2

Au lieu de se contenter de vérification du hachage, nous avons à parcourir chaque requête et voir si elle correspond à la ligne actuelle ($0). C'est beaucoup plus lent, mais malheureusement nécessaire (bien que nous sommes au moins d'appariement de la plaine des chaînes sans utiliser les regexes, de sorte qu'il pourrait être plus lent). La boucle s'arrête quand on a un match.

Si vous avez réellement voulu évaluer les lignes du fichier de requête que les expressions régulières, vous pouvez utiliser $0 ~ q au lieu de la plus rapide index($0, q). Notez que cela utilise POSIX étendue des expressions régulières, à peu près le même que grep -E ou egrep mais sans délimitée quantificateurs ({1,7}) ou le GNU extensions pour les limites de mot (\b) et abréviation classes de personnage (\s,\w, etc).

Ceux-ci devraient travailler aussi longtemps que le hachage de ne pas dépasser les limites de ce awk peut stocker. Cela pourrait être aussi bas que 2.1 B entrées (une supposition basée sur la plus haute signé 32 bits int) ou aussi haut que la quantité de mémoire libre.

OriginalL'auteur Adam Katz