blixt php
1.0.0
사용자, 제품 등과 같은 인덱스 내의 다른 유형을 나타냅니다.
전체 색인에 고유 한 단어의 줄기를 나타냅니다. (예 : Run은 실행, 러너, 런 등의 줄기입니다). 역 문서 주파수는 단어에 대해 계산 및 저장되어 인덱스에 대한 스키마가없는 검색을 수행하는 데 사용할 수있는 인덱스 전체 IDF를 제공합니다.
용어는 특정 스키마 내에 단어의 존재를 나타냅니다. 즉, 스템 "run"이 사용자 스키마 내에 나타나고 제품 스키마에도 나타나면 해당 스키마 내에 해당 단어에 대한 두 가지 용어 레코드가 있습니다. 역 문서 주파수는 또한 특정 스키마에 대한 검색을 허용하는 스키마 특정 IDF를 제공하기 위해 용어와 함께 저장됩니다 (이러한 검색은 단어의 인덱스 전체 IDF 값의 영향을받지 않습니다).
열은 스키마 내에서 사용 가능한 필드입니다. 열은 표현 된 데이터가 저장되어 있는지, 색인화되었는지 여부 및 쿼리의 열을 우선 순위를 정하는 데 사용할 수있는 가중치에 대한 규칙을 저장합니다 (예 : 제품 제목은 설명보다 무게가 더 높을 수 있습니다).
문서는 인덱스의 실제 엔티티를 나타내며, 실제로 인덱싱 된 항목이며 결과의 기초를 쿼리로 형성합니다.
필드는 열과 일치하는 문서의 속성입니다. 열, 문서 및 필드는 일반적인 데이터베이스처럼 작동합니다. 열은 테이블 열과 같고 문서는 행이나 레코드와 같고 필드는 셀 또는 항목입니다.
발생은 문서의 필드 내에 용어 (스키마 특정 단어)의 존재를 나타냅니다. 발생은 용어와 필드의 독특한 표현입니다. 사건이 발생하면 주파수를 저장하는데, 이는 필드가 필드 내에 나타나는 횟수를 나타냅니다 (검색 할 때 나중에 점수를 계산하는 데 사용됨).
위치는 필드 내에서 실제 용어 위치를 나타냅니다. "run"(또는 그 줄기)이 필드에 3 번 표시되면 3 개의 위치 레코드가 있으며, 각각의 해당 필드 내에서 해당 발생 위치를 표시합니다.
인덱스에 "사용자"스키마가 있다고 상상해보십시오. 이 스키마는 각 사용자 인스턴스에 대해 "이름"및 "정보"에 대해 2 개의 열을 정의합니다. 각 열은 저장 및 색인화되며 모두 가중치가 1입니다. 우리는 2 명의 사용자가 색인에 추가 할 2 명의 사용자가 있습니다. 우리는 다음과 같은 구조로 끝날 것입니다.
| ID | 이름 |
|---|---|
| 1 | 사용자 |
| ID | 이름 | 저장 | 색인 | 무게 |
|---|---|---|---|---|
| 1 | 이름 | 1 | 1 | 1 |
| 2 | ~에 대한 | 1 | 1 | 1 |
| ID | 단어 |
|---|---|
| 1 | 조 |
| 2 | 블로그 |
| 3 | 좋다 |
| 4 | 계집애 |
| 5 | 암사슴 |
| 6 | 사랑 |
| 7 | 에게 |
| 8 | 파티 |
| ID | schema_id | Word_id | document_count |
|---|---|---|---|
| 1 | 1 | 1 | 2 |
| 2 | 1 | 2 | 1 |
| 3 | 1 | 3 | 2 |
| 4 | 1 | 4 | 3 |
| 5 | 1 | 5 | 1 |
| 6 | 1 | 6 | 1 |
| 7 | 1 | 7 | 1 |
| 8 | 1 | 8 | 1 |
| ID | schema_id | 열쇠 |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 1 | 2 |
| ID | document_id | column_id | 값 |
|---|---|---|---|
| 1 | 1 | 1 | 조 블로그 |
| 2 | 1 | 2 | Joe는 Jane을 좋아합니다 |
| 3 | 2 | 1 | 제인 도어 |
| 4 | 2 | 2 | 제인은 파티를 좋아합니다 |
| ID | field_id | term_id | 빈도 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 2 | 1 | 2 | 1 |
| 3 | 2 | 1 | 1 |
| 4 | 2 | 3 | 1 |
| 5 | 2 | 4 | 1 |
| 6 | 3 | 4 | 1 |
| 7 | 3 | 5 | 1 |
| 8 | 4 | 4 | 1 |
| 9 | 4 | 3 | 1 |
| 10 | 4 | 7 | 1 |
| 11 | 4 | 8 | 1 |
| ID | 발생 _id | 위치 |
|---|---|---|
| 1 | 1 | 1 |
| 2 | 2 | 2 |
| 3 | 3 | 1 |
| 4 | 4 | 2 |
| 5 | 5 | 3 |
| 6 | 6 | 1 |
| 7 | 7 | 2 |
| 8 | 8 | 1 |
| 9 | 9 | 2 |
| 10 | 10 | 3 |
| 11 | 11 | 4 |
BLIXT 객체가 생성되면 처음에는 저장된 스키마 및 열 객체를 메모리에로드합니다. 이를 통해 BLIXT는 스키마 및 관련 열을 신속하게 조회하여 인덱스 요청을 유효하게하고 각 열에서 is_indexed 및 is_stored 제약 조건을 빠르게 수집 할 수 있습니다.
문서의 인덱싱이 이루어지기 전에 스키마는 각각 자신이 나타내는 필드가 저장되거나 인덱싱되어야하는지 여부를 지정하는 자체 속성을 갖는 열 세트로 정의되어야합니다. 스키마가 이미 존재하면이 부분을 건너 뛸 수 있습니다. 스키마 정의가 제공되지 않고 그러한 스키마가 존재하지 않으면 예외가 발생합니다.
문서는 인덱스 가능한 문서 형식으로 제공되며, 클라이언트 시스템에서 나중에 식별하기 위해 사용할 수있는 키를 지정합니다. 색인 가능한 문서에는 필드 세트가 포함되어 있습니다. BLIXT가 문서를 인덱스 내의 올바른 스키마에 배치 할 수 있도록 문서와 함께 스키마 (또는 유형)가 제공됩니다.
BLIXT는 먼저 해당 스키마의 색인에 존재하지 않는지 확인하여 문서를 처리하기 시작합니다. 존재한다면 예외가 발생합니다.
그런 다음 BLIXT는 문서 레코드를 추가하고 문서의 필드 처리를 시작합니다. 각 필드는 토큰으로 나뉘어져 있습니다 (대부분의 경우 토큰은 단어입니다). 그런 다음 각 토큰은 줄기가 있습니다 (즉, 단어의 근본을 찾는 것, 예를 들어 영어/포터 스템머와 같은 "run"이라는 단어는 "running", "runner", "runs"등의 줄기입니다.
그런 다음 해당 레코드가 이미 존재하지 않으면 각 토큰에 대한 워드 레코드가 추가 된 다음 스키마에서 용어 레코드가 작성됩니다. 용어 레코드의 문서 카운트 총계는 새 문서의 추가를 반영하도록 업데이트됩니다.
발생 레코드는 각 고유 한 용어 및 필드 조합에 대해 생성되며, 이는 지정된 용어가 특정 필드 내에서 발생 함을 나타냅니다. 주파수 (필드 내에서 발생한 용어 횟수)는 발생 기록과 함께 저장됩니다. 위치 데이터는 또한 용어가 발생한 필드의 각 위치를 나타내는 각 발생 레코드에 대해 저장됩니다.
다음 유형의 쿼리가 지원됩니다.
+ 모든 용어가 선택적으로 간주되는 단순화 ~ 부울 쿼리. 이 유형의 쿼리는 다른 모든 쿼리의 기초를 형성합니다. 검색은 검색 문구를 별도의 단어 (토큰 화)로 나눈 다음 각 단어를 루트 형식 (스템 밍)으로 전환하여 시작합니다. 그런 다음이 용어와 일치하는 단어 레코드를 찾도록 색인이 쿼리됩니다. 우리가 심문하는 단어 레코드와 스키마를 사용하여 용어 레코드가 추출됩니다. + 연산자가 첨부 된 검색어 중 하나가 레코드라는 용어에 존재하지 않으면 빈 결과 세트가 반환됩니다.
그런 다음 쿼리 용어 (운영자에 관계없이)를 포함하는 필드를 찾기 위해 쿼리가 수행되고 해당 필드와 관련된 문서가 반환됩니다 (해당 필드, 발생 및 위치에 따라 모든 위치를로드). 그런 다음 각 문서가 분석 및 허용 또는 거부됩니다. 문서에 필요한 용어 ( + )가 포함되어 있지 않거나 제거 된 용어 ( ~ )가 거부 된 경우 다른 모든 문서가 수락됩니다. 허용 된 문서 세트는 결과로 반환됩니다.
다음 유형의 쿼리는 나중에 지원할 예정입니다.
단일 용어 쿼리 : 다기 쿼리와 유사하게 문서는 단일 용어에 대해 점수를 매 깁니다.
전체 문구 쿼리 : 다기 쿼리와 유사하지만 올바른 순서의 모든 용어를 포함하는 문서 만 허용됩니다.
또한 검색을 수행하기 전에 입력 검색 문자열을 올바른 쿼리 유형으로 변환 할 수 있도록 쿼리 구문 분석을 구현하기위한 것입니다.
이것들은 미래를위한 개선입니다.
검색 성능을 향상시키는 데 사용할 수있는 스토리지 비영리 캐시 (Redis, Memcached, FileSystem 등)를 구현하십시오. 이 프로젝트에는 캐시에 대한 여러 가지 사용 사례가 있습니다.
참고 : 위의 기능 중 일부를 구현하려면 고유 한 세션 식별자를 사용하여 캐시 된 검색이 해당 사용자에게만 유효하고 캐시 된 개체를 지우는 것을 중지하기 위해 사용자로부터 전달하고 수신해야합니다. 이는 사용자가 페이지를 이용할 수 있도록 전체 검색 결과 세트를 캐싱 할 때 분명히 그렇습니다. 또한 많은 사용자가 동일한 검색 결과를 빠르게 볼 수 있도록 세션별로 간주되지 않는 캐싱 버전의 가치가있을 수 있습니다.
인덱싱 프로세스 중에 추가 테이블을 사용하여 용어 매핑을 문서에 저장할 수 있습니다. 이는 주어진 용어가 나타나는 문서가 어떤 문서에 나타나는지 알려줍니다.이를 통해 항은 신속하게 생성 할 수있는 용어가 나타나는 문서 목록을 가져 와서 후보자 문서 ID를 결정하려는 많은 프로세스를 건너 뛸 수 있습니다 (또는 금지 된 경우) 후보자 ID를 줄일 수 있습니다.
