locate(또는 updatedb)은 다소 간단합니다. 원하는 경로(보통 "/")의 출력을 가져와 find정렬한 다음 frcode사전 압축 도구( )를 사용하여 압축합니다. 여기서 연속적인 공통 접두사는 다음 수로 대체됩니다. 반복되는 문자.
그렇다면 사람들이 전체 텍스트 검색과 유사한 것을 만드는 것을 막는 이유가 무엇인지 궁금합니다. 예를 들어 시스템의 모든 파일을 연결하고 각 줄을 format 으로 정렬한 다음 사전 압축을 수행하는 line:filename:linenumber것은 어떻습니까 ? 나는 당신이 더 빠른 것으로 끝날 것이라고 생각합니다 grep. 그러나 일간/주간 크론 작업이 실행되기 전에 최신 상태가 되지 않는 대가를 치르게 됩니다 locate.
시스템 전체에 있어서는 다소 과잉일 수도 있지만 locategrep, 하루 종일 크게 변하지 않는 대규모 프로젝트의 속도를 높이는 데 유용할 것이라고 생각합니다.
비슷한 것이 이미 존재합니까, 아니면 알려진 도구를 사용하여 구현하는 것이 쉽지 않습니까?
노트:나는 일반 텍스트 검색 이상의 기능을 포함하는 엔터프라이즈 수준 솔루션을 피하고 싶습니다(그러나 정규식 지원은 감사합니다).
답변1
일반적으로 GNU grep은 BSD와 매우 느리게 경쟁합니다.
ag(aka the_silver_searcher), rg(aka ) 또는 ;와 같은 사람들은 ripgrep텍스트 상당히ack를 색인화하려고 하지 않고 모든 쿼리에 대해 다시 검색하지만 약 3초가 소요됩니다. GNU는 10초 이상 소요됩니다.greprgrg FOOBARgrep
전체 텍스트 검색 속도를 높이기 위해 IMAP 서버에서 플러그인으로 사용하는 전체 텍스트 검색 엔진(주로 xapian)도 있습니다. 이것은 나에게 실제로 영향을 미치는 것으로 입증된 유일한 사용 사례입니다.
(Ceterum ceneo mandbem esse delendam; 우리 검색 도구는 너무 빨라서 190MB 매뉴얼 페이지 인덱스를 다시 작성하는 데 30초가 소요됩니다. 이는 도저히 용납할 수 없는 일입니다. 그리고 gzip이 좋은 압축기라는 아이디어진짜매뉴얼 페이지와 같은 통합 데이터에는 이러한 항목을 매우 작게 만드는 압축 사전이 포함되어 있는데, 이는 제가 가장 싫어하는 또 다른 문제입니다. 하지만 상황이 너무 얽혀 있어서 맨디를 없앨 수가 없어요. )