Bleve: 초고속 검색 엔진을 구축하는 방법은 무엇입니까?

Go/Golang은 제가 가장 좋아하는 언어 중 하나입니다. 저는 미니멀리즘을 좋아하고 그것이 얼마나 깔끔한지 좋아합니다. 구문 면에서 매우 간결하고 단순함을 유지하기 위해 매우 열심히 노력합니다(저는 KISS 원칙의 열렬한 팬입니다).

최근 제가 직면한 주요 과제 중 하나는 빠른 검색 엔진을 구축하는 것입니다. 물론 SOLR 및 ElasticSearch와 같은 옵션이 있습니다. 둘 다 매우 잘 작동하고 확장성이 뛰어납니다. 그러나 종속성이 거의 또는 전혀 없이 더 빠르고 쉽게 배포할 수 있도록 하여 검색을 단순화해야 했습니다.

결과의 순위를 다시 매길 수 있도록 결과를 신속하게 반환할 수 있도록 충분히 최적화해야 했습니다. C/Rust가 이에 적합할 수 있지만 저는 개발 속도와 생산성을 중요하게 생각합니다. Golang은 두 가지 측면 모두에서 최고라고 생각합니다.

이 기사에서는 Go를 사용하여 자신만의 검색 엔진을 구축하는 방법에 대한 간단한 예를 살펴보겠습니다. 생각보다 복잡하지 않다는 사실에 놀랄 것입니다.

Golang: Python과 스테로이드

이유는 모르겠지만 Golang은 어떤 면에서는 Python과 같은 느낌을 줍니다. 구문은 이해하기 매우 쉽습니다. 아마도 세미콜론과 괄호가 어디에나 없거나 추악한 try-catch 문이 부족할 수도 있습니다. 어쩌면 멋진 Go 포맷터인지도 모르겠습니다.

어쨌든 Golang은 단일 독립형 바이너리를 생성하므로 모든 프로덕션 서버에 배포하기가 매우 쉽습니다. 간단히 "빌드"하고 실행 파일을 교체하면 됩니다.

저에게 꼭 필요한 내용이었습니다.

블레베요?

아니, 오타가 아니죠?. Bleve는 강력하고 사용하기 쉬우며 매우 유연한 Golang 검색 라이브러리입니다.

Go 개발자로서 일반적으로 전염병과 같은 타사 패키지를 피합니다. 때로는 타사 패키지를 사용하는 것이 합리적입니다. Bleve는 빠르고 디자인도 훌륭하며 사용하기에 충분한 가치를 제공합니다.

그리고 제가 "Bleve"를 하는 이유는 다음과 같습니다.

• Golang의 가장 큰 장점 중 하나인 Self-contained는 단일 바이너리이기 때문에 그 느낌을 유지하고 싶었고 문서를 저장하고 쿼리하기 위해 외부 DB나 서비스가 필요하지 않았습니다. Bleve는 Sqlite와 유사하게 메모리에서 실행되고 디스크에 기록됩니다.

• 확장하기 쉽습니다. Go 코드이므로 필요에 따라 라이브러리를 쉽게 조정하거나 코드베이스에서 확장할 수 있습니다.

• 빠름: 천만 개의 문서에 대한 검색 결과는 필터링을 포함하여 50~100ms밖에 걸리지 않습니다.

• 패싯: 일정 수준의 패싯 지원 없이는 최신 검색 엔진을 구축할 수 없습니다. Bleve는 범위 또는 단순 카테고리 개수와 같은 일반적인 패싯 유형을 완벽하게 지원합니다.

• 빠른 인덱싱: Bleve는 SOLR보다 다소 느립니다. SOLR은 30분 안에 1천만 개의 문서를 인덱싱할 수 있지만 Bleve는 1시간 넘게 걸리지만 1시간 정도는 여전히 내 요구 사항에 충분히 적합하고 빠릅니다.

• 좋은 품질의 결과. Bleve는 키워드 결과에 잘 작동하지만 일부 의미 유형 검색도 Bleve에서 정말 잘 작동합니다.

• 빠른 시작: 업데이트를 다시 시작하거나 배포해야 하는 경우 Bleve를 다시 시작하는 데 단 몇 밀리초도 걸리지 않습니다. 메모리에서 인덱스를 재구축하기 위한 읽기 차단이 없으므로 재시작 후 1000분의 1초 만에 중단 없이 인덱스 검색이 가능합니다.

인덱스를 설정하시겠습니까?

Bleve에서 "인덱스"는 데이터베이스 테이블이나 컬렉션(NoSQL)으로 생각할 수 있습니다. 일반 SQL 테이블과 달리 모든 단일 열을 지정할 필요가 없으며 기본적으로 대부분의 사용 사례에서 기본 스키마를 사용할 수 있습니다.

Bleve 인덱스를 초기화하려면 다음을 수행할 수 있습니다.

mappings := bleve.NewIndexMapping()
index, err = bleve.NewUsing("/some/path/index.bleve", mappings, "scorch", "scorch", nil)
if err != nil {
    log.Fatal(err)
}

Bleve는 몇 가지 다른 인덱스 유형을 지원하지만, 많은 노력 끝에 "scorch" 인덱스 유형이 최고의 성능을 제공한다는 것을 알았습니다. 마지막 3개의 인수를 전달하지 않으면 Bleve는 기본적으로 BoltDB를 사용합니다.

문서 추가

Bleve에 문서를 추가하는 것은 매우 쉽습니다. 기본적으로 모든 유형의 구조체를 인덱스에 저장할 수 있습니다.

type Book struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Genre string `json:"genre"`
}

b := Book{
    ID:    1234,
    Name:  "Some creative title",
    Genre: "Young Adult",
}
idStr := fmt.Sprintf("%d", b.ID)
// index(string, interface{})
index.index(idStr, b)

많은 양의 문서를 색인화하는 경우 일괄 처리를 사용하는 것이 좋습니다.

// You would also want to check if the batch exists already
// - so that you don't recreate it.
batch := index.NewBatch()
if batch.Size() >= 1000 {
    err := index.Batch(batch)
    if err != nil {
        // failed, try again or log etc...
    }
    batch = index.NewBatch()
} else {
    batch.index(idStr, b)
}

알다시피, 레코드를 일괄 처리하고 이를 인덱스에 쓰는 것과 같은 복잡한 작업은 일시적으로 문서를 인덱스하기 위한 컨테이너를 생성하는 "index.NewBatch"를 사용하여 단순화됩니다.

그런 다음 루프를 따라 크기를 확인하고 배치 크기 제한에 도달하면 인덱스를 플러시합니다.

색인 검색

Bleve는 검색 요구 사항에 따라 선택할 수 있는 다양한 검색 쿼리 파서를 제공합니다. 이 기사를 짧고 간결하게 유지하기 위해 표준 쿼리 문자열 파서를 사용하겠습니다.

searchParser := bleve.NewQueryStringQuery("chicken reciepe books")
maxPerPage := 50
ofsset := 0
searchRequest := bleve.NewSearchRequestOptions(searchParser, maxPerPage, offset, false)
// By default bleve returns just the ID, here we specify
// - all the other fields we would like to return.
searchRequest.Fields = []string{"id", "name", "genre"}
searchResults, err := index.Search(searchResult)

이제 몇 줄만 있으면 적은 메모리와 리소스 공간에서도 좋은 결과를 제공하는 강력한 검색 엔진을 갖게 됩니다.

다음은 검색 결과의 JSON 표현입니다. "히트"에는 일치하는 문서가 포함됩니다.

{
    "status": {
        "total": 5,
        "failed": 0,
        "successful": 5
    },
    "request": {},
    "hits": [],
    "total_hits": 19749,
    "max_score": 2.221337297308545,
    "took": 99039137,
    "facets": null
}

패싯

앞서 언급했듯이 Bleve는 스키마에서 이러한 기능을 설정할 필요 없이 즉시 완전한 패싯 지원을 제공합니다. 예를 들어 "장르"라는 책을 패싯하려면 다음을 수행할 수 있습니다.

//... build searchRequest -- see previous section.
// Add facets
genreFacet := bleve.NewFacetRequest("genre", 50)
searchRequest.AddFacet("genre", genreFacet)
searchResults, err := index.Search(searchResult)

단 두 줄의 코드로 이전의 searchRequest를 확장합니다. "NewFacetRequest"는 2개의 인수를 사용합니다:

• 필드: 패싯할 인덱스의 필드(문자열).

• 크기: 계산할 항목 수(정수). 따라서 이 예에서는 처음 50개 장르만 계산됩니다.

이제 위의 내용이 검색 결과의 "측면"을 채울 것입니다.

다음으로 검색 요청에 패싯을 추가하기만 하면 됩니다. "패싯 이름"과 실제 패싯을 사용합니다. "패싯 이름"은 검색 결과에서 이 결과 집합을 찾을 수 있는 "키"입니다.

고급 쿼리 및 필터링

"QueryStringQuery" 파서는 꽤 많은 마일리지를 얻을 수 있습니다. 검색어를 여러 필드와 일치시키고 하나 이상의 필드가 일치하는 경우 결과를 반환하려는 경우 "하나는 일치해야 함"과 같은 더 복잡한 쿼리가 필요한 경우가 있습니다.

이를 수행하려면 "접합" 및 "접합" 쿼리 유형을 사용할 수 있습니다.

• 결합 쿼리: 기본적으로 여러 쿼리를 연결하여 하나의 거대한 쿼리를 형성할 수 있습니다. 모든 하위 쿼리는 하나 이상의 문서와 일치해야 합니다.

• 분리 쿼리: 위에서 언급한 "하나는 반드시 일치해야 합니다" 쿼리를 수행할 수 있습니다. x개의 쿼리를 전달하고 하나 이상의 문서와 일치해야 하는 하위 쿼리의 수를 설정할 수 있습니다.

분리 쿼리 예:

mappings := bleve.NewIndexMapping()
index, err = bleve.NewUsing("/some/path/index.bleve", mappings, "scorch", "scorch", nil)
if err != nil {
    log.Fatal(err)
}

앞서 "searchParser"를 사용한 방법과 유사하게 이제 "searchRequest"의 생성자에 "Disjunction Query"를 전달할 수 있습니다.

정확히 동일하지는 않지만 다음 SQL과 유사합니다.

type Book struct {
    ID    int    `json:"id"`
    Name  string `json:"name"`
    Genre string `json:"genre"`
}

b := Book{
    ID:    1234,
    Name:  "Some creative title",
    Genre: "Young Adult",
}
idStr := fmt.Sprintf("%d", b.ID)
// index(string, interface{})
index.index(idStr, b)

"query.Fuzziness=[0 또는 1 또는 2]"를 설정하여 검색 범위를 조정할 수도 있습니다.

접속 쿼리 예:

// You would also want to check if the batch exists already
// - so that you don't recreate it.
batch := index.NewBatch()
if batch.Size() >= 1000 {
    err := index.Batch(batch)
    if err != nil {
        // failed, try again or log etc...
    }
    batch = index.NewBatch()
} else {
    batch.index(idStr, b)
}

구문이 매우 유사하다는 것을 알 수 있습니다. 기본적으로 "접합" 및 "접합" 쿼리를 서로 바꿔서 사용할 수 있습니다.

SQL에서는 다음과 유사하게 표시됩니다.

searchParser := bleve.NewQueryStringQuery("chicken reciepe books")
maxPerPage := 50
ofsset := 0
searchRequest := bleve.NewSearchRequestOptions(searchParser, maxPerPage, offset, false)
// By default bleve returns just the ID, here we specify
// - all the other fields we would like to return.
searchRequest.Fields = []string{"id", "name", "genre"}
searchResults, err := index.Search(searchResult)

요약하자면; 모든 하위 쿼리가 하나 이상의 문서와 일치하도록 하려면 "결합 쿼리"를 사용하고, 하나 이상의 하위 쿼리를 일치시키려고 하지만 반드시 모든 하위 쿼리를 일치시키지는 않으려는 경우 "분리 쿼리"를 사용하세요.

샤딩

속도 문제가 발생하는 경우 Bleve는 여러 인덱스 샤드에 데이터를 분산한 다음 한 번의 요청으로 해당 샤드를 쿼리할 수도 있습니다. 예를 들면 다음과 같습니다.

{
    "status": {
        "total": 5,
        "failed": 0,
        "successful": 5
    },
    "request": {},
    "hits": [],
    "total_hits": 19749,
    "max_score": 2.221337297308545,
    "took": 99039137,
    "facets": null
}

샤딩은 상당히 복잡해질 수 있지만 위에서 볼 수 있듯이 Bleve는 모든 인덱스를 자동으로 "병합"하고 검색한 다음 마치 검색한 것처럼 하나의 결과 세트로 결과를 반환하므로 많은 어려움을 겪지 않습니다. 단일 인덱스.

저는 샤딩을 사용하여 100개의 샤드를 검색해 왔습니다. 전체 검색 프로세스는 평균 100~200밀리초 내에 완료됩니다.

다음과 같이 샤드를 생성할 수 있습니다.

//... build searchRequest -- see previous section.
// Add facets
genreFacet := bleve.NewFacetRequest("genre", 50)
searchRequest.AddFacet("genre", genreFacet)
searchResults, err := index.Search(searchResult)

각 문서에 대해 고유한 ID를 생성하거나 색인을 엉망으로 만들지 않고 문서를 추가하고 업데이트할 수 있는 일종의 예측 가능한 방법이 있는지 확인하세요.

이를 수행하는 쉬운 방법은 소스 DB 또는 문서를 가져오는 모든 위치에 샤드 이름이 포함된 접두사를 저장하는 것입니다. 따라서 삽입하거나 업데이트하려고 할 때마다 ".index"를 호출할 샤드를 알려주는 "접두사"를 검색합니다.

업데이트 얘기가 나와서 말인데, 간단히 "index.index(idstr, struct)"를 호출하면 기존 문서가 업데이트됩니다.

결론

위의 기본 검색 기술을 GIN 또는 표준 Go HTTP 서버 뒤에 배치하면 복잡한 인프라를 구축할 필요 없이 매우 강력한 검색 API를 구축하고 수백만 개의 요청을 처리할 수 있습니다.

하지만 한 가지 주의할 점이 있습니다. 그러나 Bleve는 복제를 제공하지 않습니다. 이를 API로 래핑할 수 있기 때문입니다. 소스에서 읽고 고루틴을 사용하여 모든 Bleve 서버에 대한 업데이트를 "폭발"하는 크론 작업을 수행하기만 하면 됩니다.

또는 몇 초 동안 디스크 쓰기를 잠근 다음 슬레이브 인덱스에 대한 데이터를 "rsync"할 수도 있습니다. 하지만 매번 go 바이너리를 다시 시작해야 할 수도 있기 때문에 그렇게 하지 않는 것이 좋습니다. .

위 내용은 Bleve: 초고속 검색 엔진을 구축하는 방법은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!