LatticeDB: 벡터 및 전체 텍스트 검색 기능을 갖춘 내장형 단일 파일 그래프 데이터베이스

LatticeDB는 단일 머신에서 관계 중심 워크로드를 위한 내장형 단일 파일 속성 그래프 데이터베이스입니다. 그래프 탐색, HNSW 벡터 유사성 검색, BM25 전체 텍스트 검색을 하나의 쿼리 엔진에 통합하여 의미적, 텍스트적, 관계적 데이터를 위한 별도의 데이터베이스가 필요 없도록 합니다.

그래프, 벡터, 텍스트를 위한 통합 쿼리 레이어

LatticeDB는 단일 쿼리 언어 내에서 관계, 의미, 텍스트 기반으로 데이터를 쿼리할 수 있게 해줍니다. 이 통합은 쿼리가 의미적 매칭을 찾고 관련 엔티티로 탐색하며 특정 텍스트로 필터링이 필요할 수 있는 그래프 RAG 및 에이전트 메모리 시스템에 특히 유용합니다.

Cypher 쿼리 언어 지원

LatticeDB는 Cypher 쿼리 언어의 일부를 구현하며, 다음과 같은 주요 작업을 지원합니다:

탐색: MATCH, WHERE, RETURN, 그리고 변수 길이 경로 (예: *1..3)
수정: CREATE, DELETE, SET, REMOVE, MERGE
검색 연산자: 벡터 거리에 대한 <=> 연산자와 전체 텍스트 검색에 대한 @@ 연산자
데이터 처리: WITH, UNWIND, 그리고 count, sum, avg, min, max, collect와 같은 집계

통합 검색 기능

벡터 검색: 구성 가능한 M 및 ef 매개변수를 사용하는 계층적 탐색 가능한 소형 세계(HNSW) 근사 최근접 이웃 검색을 사용합니다. 내장 해시 임베딩을 지원하며, Ollama 및 OpenAI용 HTTP 클라이언트를 제공합니다.
전체 텍스트 검색: 토큰화, 어간 추출, 구성 가능한 레벤슈타인 거리 기반의 퍼지 검색을 지원하는 BM25 순위 역색인을 사용합니다.

성능 벤치마크

LatticeDB는 저지연 로컬 작업을 최적화한 Zig로 작성되었습니다. Apple M1(단일 스레드)에서 수행된 벤치마크 결과는 다음과 같습니다.

핵심 연산 지연 시간

작업	지연 시간	처리량
노드 조회	0.13 µs	7.9M ops/sec
노드 생성	0.65 µs	1.5M ops/sec
엣지 탐색	9 µs	111K ops/sec
전체 텍스트 검색 (100개 문서)	19 µs	53K ops/sec
10-NN 벡터 검색 (1M 벡터)	0.83 ms	1.2K ops/sec

벡터 검색 확장성

100만 개의 벡터(128차원 코사인 벡터) 규모에서 LatticeDB는 평균 지연 시간 0.83ms를 기록하며, 100% recall@10을 달성합니다. 검색 지연 시간은 하위 선형적( O(log N))으로 확장됩니다.

그래프 탐색 vs. SQLite

LatticeDB는 그래프 탐색에서 SQLite의 재귀 CTE보다 크게 우수합니다. 10만 개의 노드와 50만 개의 엣지를 가진 소셜 네트워크 그래프에서 2단계 탐색은 LatticeDB에서는 38.7 µs, SQLite에서는 548.3 µs로, 14배의 속도 향상을 보였습니다. 더 깊은 탐색(깊이 50)의 경우 속도 향상은 2,819배에 달합니다.

아키텍처 및 운영 모델

LatticeDB는 SQLite와 유사한 운영 단순성을 반영하는 "로컬 우선" 철학을 따릅니다.

저장소: 전체 데이터베이스는 단일 이동 가능한 파일에 저장됩니다.
병렬성: 내장된 단일 쓰기자 모델을 사용합니다. 한 프로세스만 파일을 소유하므로, 다중 애플리케이션 동시 쓰기에 적합하지 않습니다.
내구성: 충돌 복구 및 ACID 트랜잭션(커밋/롤백 가능)을 위한 쓰기 전 로그(WAL)를 사용합니다.
이벤트 스트리밍: 내구성 있는 이름 붙은 스트림과 그래프 변경 피드를 내장하고 있으며, 그래프 쓰기와 동일한 트랜잭션/WAL 경로를 공유합니다.
바인딩: 핵심은 Zig로 작성되었지만, 공식적으로 Python, TypeScript/Node.js, Go용 바인딩을 제공합니다.

사용 사례 분석

이상적인 사용 사례

로컬 지식 도구: 별도의 서버 없이 그래프 구조가 필요한 애플리케이션
에이전트 메모리 및 RAG: 의미 검색과 관계 탐색을 결합하는 파이프라인
연결된 로컬 데이터: 인용 그래프, 엔티티 그래프, 개인 노트 관리
로컬 개발: 단일 머신에서 Neo4j 또는 Weaviate용 프로토타이핑

LatticeDB를 피해야 할 경우

다중 쓰기자 요구사항: 여러 애플리케이션이 동일한 데이터베이스에 동시에 쓰기를 해야 하는 경우, PostgreSQL 또는 Neo4j와 같은 클라이언트-서버 데이터베이스가 필요합니다.
표 형식 데이터: 행과 열에 자연스럽게 맞는 데이터(예: 매출 기록)의 경우, 관계형 데이터베이스가 여전히 더 효율적입니다.
분산 확장성: LatticeDB는 단일 머신에 국한되며, 클러스터 간 샤딩 또는 복제를 지원하지 않습니다.
전체 Cypher 호환성: 아직 OPTIONAL MATCH 또는 CALL 프로시저를 지원하지 않습니다.

커뮤니티 인사이트

Hacker News 사용자들은 프로젝트의 인상적인 성능과 "사용하지 말아야 할 경우" 문서의 유용성을 언급했습니다. 그러나 일부 벤치마크 결과의 차이점이 보고되었습니다. 한 사용자(@adsharma)는 M4 맥 미니에서 다른 결과를 보고했으며, LatticeDB가 여전히 탐색에서 SQLite를 앞섰지만, 공식 벤치마크보다 속도 향상 비율이 낮았다고 지적했습니다(예: 1단계 탐색에서 36배가 아닌 2.8배).

다른 커뮤니티 논의에서는 LadybugDB, SparrowDB, DuckPGQ와 같은 다른 새로운 "로컬 우선" 그래프 도구들과의 대안 및 비교가 제기되었습니다.