semadb
v2.0.2
버스트 다중 인덱스 하이브리드 벡터 데이터베이스 / 검색 엔진이 없습니다
SEMADB는 다중 인덱스, 다중 벡터, 문서 기반 벡터 데이터베이스 / 검색 엔진입니다. 명확하고 사용하기 쉬운 JSON RESTFUL API를 제공하도록 설계되었습니다. SemADB의 원래 구성 요소는 Semafind의 지식 관리 프로젝트를 위해 구축되어 독립형 프로젝트로 개발되었습니다. 목표는 다양한 응용 분야에서 사용할 수있는 간단하고 현대적이며 효율적인 검색 엔진을 제공하는 것입니다.
호스팅 된 솔루션을 찾고 계십니까? SemADB Cloud Beta는 RapidApi에서 사용할 수 있습니다.
소스에서 시작하려면 지침을 따라 GO를 설치하십시오. 이것이 SEMADB를 실행하는 데 필요한 유일한 의존성입니다. 우리는 SemADB를 최신 GO 릴리스와 함께 가능한 한 자체 포함하고 최신 상태로 유지하려고 노력합니다.
SemADB는 YAML 파일에서 모든 구성을 읽습니다. config 폴더에 포함 된 몇 가지 예가 있습니다. 다음을 사용하여 단일 서버를 실행할 수 있습니다.
SEMADB_CONFIG=./config/singleServer.yaml go run ./VS 코드를 편집기로 사용하는 경우 이미 동일한 작업을 수행하지만 디버그 모드에서도 로컬로 클러스터를 시작하는 사전 제작 작업이 이미 있습니다.
서버가 실행되면 샘플 파일을 사용하여 서버에 대한 몇 가지 예제 요청을 볼 수 있습니다. 최대한 활용하려면 나머지 클라이언트 확장을 설치하여 편집기에서 직접 요청하고 결과를 표시 할 수 있습니다.
다음 저장소 컨테이너 이미지를 사용하여 최신 버전의 Semadb를 실행할 수 있습니다.
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:main메인 브랜치를 실행합니다. 특정 릴리스에 대한 태그 버전도 있습니다. 저장소 안정 및 생산 준비 버전의 컨테이너 레지스트리를 참조하십시오.
다음을 사용하여 컨테이너 이미지를 로컬로 빌드하고 실행할 수 있습니다.
docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb 데이터 지속성 : SemADB는 구성 파일에 rootDir 로 지정된 디스크 디렉토리에 데이터를 저장합니다. 기본적으로 데이터 디렉토리는 ./data 이고 semadb 실행 파일은 컨테이너의 마운트 포인트로 / 제공 /data 에 있습니다.
Docker를 사용할 때 Docker의 네트워크 구성에 따라 IP의 호스트 이름 및 화이트리스트를 조정해야 할 수도 있습니다. 호스트 이름을 빈 문자열로 남겨두고 WhiteListing을 '*' 로 설정하면 singleServer.yaml 구성에서 수행 된 모든 연결에 SEMADB가 열립니다.
기부금을 환영합니다! 자세한 내용은 기고 안내서 파일을 읽으십시오. 기고 가이드에는 SEMADB의 아키텍처에 대한 정보와 개발 시작 방법도 포함되어 있습니다.
SemADB의 핵심 벡터 검색 알고리즘은 다음과 같은 훌륭한 연구 논문을 기반으로합니다.
문자열 또는 텍스트와 같은 다른 지수는 역 색인 접근법을 따릅니다. 역 색인은 단어 나 숫자와 같은 컨텐츠에서 데이터베이스 파일의 위치 또는 문서 또는 문서 세트에 매핑을 저장하는 데이터 구조입니다. 역 색인의 목적은 빠른 전체 텍스트 검색, 문자열 접두사 조회, 정수 범위 검색 등을 허용하는 것입니다.
Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz 상품 워크 스테이션에 기본 구성 값이있는 SEMADB는보고 된 결과와 유사하게 표준 벤치 마크에서 좋은 리콜을 달성합니다.
| v1 | v2 | V2-PQ | v2-bq | |||||
|---|---|---|---|---|---|---|---|---|
| 데이터 세트 | 상기하다 | QPS | 상기하다 | QPS | 상기하다 | QPS | 상기하다 | QPS |
| 글러브 -100- angular | 0.924 | 973.6 | 0.853 | 773.9 | 0.526 | 628.6 | ||
| DBPEDIA-OPENAI-100K-angular | 0.990 | 519.9 | 0.920 | 240.8 | 0.766 | 978.6 | ||
| 장갑 -25- angular | 0.999 | 1130.3 | 0.992 | 914.4 | 0.989 | 805.8 | ||
| MNIST-784-EUCLIDEAN | 0.999 | 1898.6 | 0.999 | 1267.4 | 0.928 | 571.6 | 0.667 | 2369.7 |
| nytimes-256-angular | 0.903 | 1020.6 | 0.891 | 786.7 | 0.438 | 983.6 | ||
| SIFT-128-EUCLIDEAN | 0.999 | 1537.7 | 0.991 | 1272.9 | 0.696 | 967.4 |
결과는 Ann-Benchmarks를 사용하여 얻습니다. 초당 쿼리 (QPS)는 다른 메소드와 유사한 단일 스레드와 함께 메모리 캐시에서 전체를 사용하지만 전체 성능을 잘 나타내는 것은 아닙니다. 요청의 엔드 투 엔드 여정으로 인해 전체 파이프 라인은 HTTP 처리, 인코딩, 인코딩, 쿼리 디코딩, 파싱, 검증, 클러스터 라우팅, 원격 프로 시저 호출, 디스크에서 데이터로드의 오버 헤드가 있습니다. 이는 하드웨어, 특히 SSD 대 하드 디스크에 따라 다릅니다. 그러나 단일 샤드 내에서 검색 알고리즘의 원시 성능은 이론적으로 연구 논문에보고 된 것과 유사합니다.
버전 1 (v1)은 SEMADB의 원래 순수 벡터 검색 구현입니다. 버전 2 (v2)는 다중 인덱스, 하이브리드, 키워드 검색 등 구현으로, 디코딩의 오버 헤드, 데이터를 인덱스로 파견하고 양자를 사용하는 오버 헤드가 훨씬 높습니다. 제품 양자화 (V2-PQ) 및 이진 양자화 (V2-BQ)가있는 버전 2는 각각의 양자화 방법을 사용하여 메모리 사용을 줄입니다. 양자화 방법이 손실되고 검색이 대략적이기 때문에 리콜이 더 낮아질 것으로 예상합니다.
콜드 디스크 스타트는 정말 느릴 수 있습니다. 체인의 하단에는 모든 데이터가 저장된 디스크가 있습니다. 메모리 인 캐시와 운영 체제 파일 캐시의 두 캐시가 있습니다. OS 캐시는 우리의 제어에 있지 않으며 파일을 읽거나 작성하여 채워집니다. 요청이 이루어지면 인덱스 그래프가 통과되고 디스크에서 작동 시스템 캐시에 포인트가로드되어 메모리 내 포인트 세트로 디코딩됩니다. 검색 작업은 종종 유사성 그래프를 가로 지르기 때문에 디스크에서 임의의 판독을 수행합니다. 따라서 콜드 스타트 중에 하드웨어에 따라 오랜 시간 (1 초, 10 초 이상)이 걸릴 수 있습니다. 솔리드 스테이트 디스크 (SSD)는 무작위 읽기를 더 잘 제공하므로 이러한 이유로 강력히 권장됩니다. 단일 애플리케이션 배포의 경우 이는 데이터 / 인덱스의 일부가 작동 중에 메모리 또는 운영 체제에 의해 캐시 될 것으로 예상하기 때문에 큰 관심사는 아닙니다. 대안은 디스크에서 사용자 정의 그래프 지향 스토리지 레이아웃을 사용하여 블록 / 페이지가 유사성 그래프에서 노드의 이웃과 더 잘 정렬됩니다.
자동 수평 스케일링 : SEMADB의 서버 수를 조정할 수 있지만 시작시 동기화됩니다. 사용 된 RendezVous 해싱은 1/n 양의 데이터를 새 서버로 이동하거나 제거 된 서버 데이터를 나머지 서버로 다시 이동시킵니다. 이 작업은 스타트 업에서만 발생하므로 라이브로드가 아닌 미리 배치 또는 다운 배치를 미리 스케일링하는 데 더욱 적합합니다. 라이브 자동 스케일링은 서버의 레이스 조건으로 인해 데이터베이스가 작동하는 동안 안전하게 수행하기가 까다 롭습니다. 일부 함정은 다음과 같습니다. 구성에서 데이터 전송이 기존 서버로 전송되는 경우 서버가 뒤처지는 반면, 데이터 전송이 발생하는 반면 사용자 요청이 처리되어야하며, 잘못된 데이터는 결국 올바른 서버에 도착해야하며, 네트워크가 분할 된 경우 시스템은 분할 뇌 시나리오에서 복구해야합니다. 많은 분산 데이터베이스에는 추가 기계가 통합되어 버전 키, 벡터 클록 등과 같은 이러한 이러한 복잡성을 추가 할 수 있습니다. 현재 서버를 조정하고 클러스터를 다시 시작하여 데이터를 재분배 할 수 있습니다.
쓰기 고 가용성 없음 : SEMADB는 검색 무거운 워크로드에 최적화됩니다. 수집 및 포인트 쓰기 작업을 위해서는 모든 관련 (데이터 배포 된 서버)이 참여해야합니다. 검색 경로에서 실패는 확률 론적 검색이기 때문에 허용 할 수 없기 때문에 실패를 허용 할 수 있습니다. 우리는 물리적 서버 실패에서 Kubernetes와 같은 컨테이너 오케스트레이션 도구로 건강한 시스템을 유지 관리합니다. 우리는 구성된 SEMADB의 상태가 활발하게 유지 될 것이라고 가정하고 결과적으로 설계에 피어 발견 또는 합의 알고리즘이 포함되어 있지 않다고 가정합니다. 이 디자인 선택은 다시 SemADB의 아키텍처를 단순화하고 빠른 개발로 AIDS를 단순화합니다. 독창적 인 디자인에는 RAFT와 같은 합의 메커니즘과 동료 발견이있는 완전히 자체 포함 된 분산 시스템이 포함되었지만 이는 과잉으로 간주되었습니다.
많은 오픈 소스 벡터 검색 및 검색 엔진 프로젝트가 있습니다. SEMADB를 일부와 비교하여 사용 사례에 더 잘 맞는지 확인하는 것이 도움이 될 수 있습니다.
