Найшвидший grep

Я хотів би знати, чи є якісь підказки, щоб зробити grepце якомога швидше. Я маю досить велику базу текстових файлів для найшвидшого пошуку. Я зробив їх усі малими літерами, щоб я міг позбутися -iваріанту. Це робить пошук набагато швидшим.

Крім того, я з’ясував, що -Fі -Pрежими швидші, ніж стандартний. Я використовую перший, коли рядок пошуку не є регулярним виразом (просто звичайний текст), другий, якщо йдеться про регулярний вираз.

Хтось має досвід прискорення grep? Можливо, скомпілювати його з нуля за допомогою певного прапора (я на Linux CentOS), впорядкувати файли певним чином або, можливо, зробити паралельним пошук якимось чином?

Спробуйте GNU паралельно , що включає приклад того, як використовувати його зgrep :

grep -rgreps рекурсивно через каталоги. На багатоядерних процесорах GNU parallelчасто може це прискорити.

find . -type f | parallel -k -j150% -n 1000 -m grep -H -n STRING {}

Це запустить 1,5 завдання на ядро ​​і надасть 1000 аргументів grep.

Для великих файлів він може розділити вхід на декілька фрагментів із аргументами --pipeта --block:

 parallel --pipe --block 2M grep foo < bigfile

Ви також можете запустити його на декількох різних машинах через SSH (ssh-агент, необхідний для уникнення паролів):

parallel --pipe --sshlogin server.example.com,server2.example.net grep foo < bigfile

Якщо ви шукаєте у дуже великих файлах, тоді налаштування мовної мови дійсно може допомогти.

GNU grep працює набагато швидше в мові C, ніж у UTF-8.

export LC_ALL=C

Ripgrep стверджує, що зараз він найшвидший.

https://github.com/BurntSushi/ripgrep

Також включає паралельність за замовчуванням

 -j, --threads ARG
              The number of threads to use.  Defaults to the number of logical CPUs (capped at 6).  [default: 0]

З README

Він побудований поверх двигуна регулярного виразу Rust. Двигун регулярних виразів Rust використовує обмежені автомати, SIMD та агресивні буквальні оптимізації, щоб зробити пошук дуже швидким.

Мабуть, використання --mmap може допомогти у деяких системах:

http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html

Не суто вдосконалення коду, але те, що я знайшов корисним після запуску grep на 2+ мільйони файлів.

Я перемістив операцію на дешевий накопичувач SSD (120 Гб). Приблизно 100 доларів - це доступний варіант, якщо ви регулярно обробляєте багато файлів.

Якщо вам байдуже, які файли містять рядок, можливо, ви захочете розділити читання та grepping на два завдання, оскільки це може коштувати grepбагато разів, ікру багато разів - один раз для кожного невеликого файлу.

1. Якщо у вас один дуже великий файл:

   parallel -j100% --pipepart --block 100M -a <very large SEEKABLE file> grep <...>

2. Багато невеликих стиснених файлів (відсортованих за inode)

   ls -i | sort -n | cut -d' ' -f2 | fgrep \.gz | parallel -j80% --group "gzcat {}" | parallel -j50% --pipe --round-robin -u -N1000 grep <..>

Зазвичай я стискаю свої файли за допомогою lz4 для максимальної пропускної здатності.

3. Якщо вам потрібна лише назва файлу, що відповідає:

   ls -i | sort -n | cut -d' ' -f2 | fgrep \.gz | parallel -j100% --group "gzcat {} | grep -lq <..> && echo {}

Спираючись на відповідь Сандро, я подивився посилання, яке він тут наводив, і погрався з BSD grep проти GNU grep. Мої результати швидкого тестування показали: GNU grep - це набагато швидше.

Тож моя рекомендація до вихідного запитання "якнайшвидший grep": переконайтесь, що ви використовуєте GNU grep, а не BSD grep (що є типовим для MacOS, наприклад).

Я особисто використовую ag (шукач срібла) замість grep, і це набагато швидше, також ви можете поєднувати його з паралельним та конвеєрним блоками.

https://github.com/ggreer/the_silver_searcher

Оновлення: Зараз я використовую https://github.com/BurntSushi/ripgrep, який швидший, ніж ag, залежно від вашого випадку використання.

Одне, що я швидше знайшов для використання grep для пошуку (особливо для зміни шаблонів) в одному великому файлі, це використання split + grep + xargs з паралельним прапором. Наприклад:

Маючи файл ідентифікаторів, який ви хочете шукати у великому файлі під назвою my_ids.txt Ім'я bigfile bigfile.txt

Використовуйте split, щоб розділити файл на частини:

# Use split to split the file into x number of files, consider your big file
# size and try to stay under 26 split files to keep the filenames 
# easy from split (xa[a-z]), in my example I have 10 million rows in bigfile
split -l 1000000 bigfile.txt
# Produces output files named xa[a-t]

# Now use split files + xargs to iterate and launch parallel greps with output
for id in $(cat my_ids.txt) ; do ls xa* | xargs -n 1 -P 20 grep $id >> matches.txt ; done
# Here you can tune your parallel greps with -P, in my case I am being greedy
# Also be aware that there's no point in allocating more greps than x files

У моєму випадку це скоротило б те, що було б 17-годинною роботою, на 1-годинну 20-хвилинну роботу. Я впевнений, що тут є якась крива дзвоника щодо ефективності, і, очевидно, перегляд наявних ядер не дасть вам жодної користі, але це було набагато кращим рішенням, ніж будь-який із наведених вище коментарів щодо моїх вимог, як зазначено вище. Це має додаткову перевагу порівняно зі сценарієм паралельного використання в основному власних інструментів (Linux).

cgrep, якщо він доступний, може бути на порядок швидше, ніж grep.

MCE 1.508 включає подвійний сценарій обгортки {file, list}, що підтримує багато бінарних файлів C. agrep, grep, egrep, fgrep та tre-agrep.

https://metacpan.org/source/MARIOROY/MCE-1.509/bin/mce_grep

https://metacpan.org/release/MCE

Не потрібно конвертувати в малу літеру, коли хочеться, щоб -i швидко працював. Просто передайте --lang = C в mce_grep.

Порядок виводу зберігається. Вивід -n та -b також правильний. На жаль, це не так для паралелі GNU, згаданої на цій сторінці. Я дуже сподівався, що GNU Parallel працюватиме тут. Крім того, mce_grep робить НЕ суб-оболонки (ш -c / шлях / до / Grep) при виклику виконуваного файлу.

Інший варіант - модуль MCE :: Grep, що входить до складу MCE.

Невелике відхилення від початкової теми: індексовані утиліти командного рядка пошуку з проекту googlecodesearch набагато швидші, ніж grep: https://github.com/google/codesearch :

Після того, як ви скомпілюєте його ( потрібен пакет golang ), ви можете проіндексувати папку за допомогою:

# index current folder
cindex .

Індекс буде створений під ~/.csearchindex

Тепер ви можете шукати:

# search folders previously indexed with cindex
csearch eggs

Я все ще передаю результати через grep, щоб отримати кольорові збіги.