hikari-systems/slater로컬 복제 그래프 사용 사례를 위해 설계된 저메모리 그래프 DB로, Bolt+TLS 지원, 저장 데이터 암호화 및 벡터를 제공합니다.
현재 버전: v0.25.2 — 모든 릴리스.
한 줄 요약: Slater는 메모리에 맞지 않는 그래프 — 수억 개의 노드와 수십억 개의 엣지를 수백 MB 남짓의 RAM으로 — 표준 Bolt 프로토콜로 서비스하므로 어떤 neo4j 드라이버든 그대로 동작하며, 그래프 옆에는 디스크 기반 벡터 검색이 자리 잡고, 이 모든 것을 포기하지 않으면서 실시간 내구성 있는 쓰기를 처리합니다. 상주 메모리는 그래프 크기가 아니라 사용자가 선택한 캐시 예산에 의해 결정됩니다.
바로가기
| Slater가 필요한 이유 | 읽기와 쓰기 | 제공 기능 | 기능 |
| Docker로 실행하기 | 작동 방식 | 쓰기 가능 계층 | 스토리지 백엔드 |
| 마운트 | 구성 | ACL | 상태 확인 |
| 작업 예제 | 개발 | 성능 | 라이선스 |
| Graphiti 메모리 저장소 | 📖 전체 매뉴얼 |
그래프 데이터베이스는 데이터를 사물(노드)과 사물 간의 관계(엣지)로 저장하며, 관계를 일급 시민으로 취급합니다. 이는 질문이 행이 아니라 연결에 관한 것일 때 필요한 것입니다. — "이 계정에서 세 홉 이내에 있는 사람은?", "이 빌드 뒤의 전체 의존성 체인은?", "어떤 계정이 장치, 주소, 카드를 공유하는가?" — SQL에서는 재귀 조인의 늪이 되지만 그래프에서는 자연스럽게 풀리는 질문들입니다.
그래프 데이터베이스에 대한 가장 흔한 불만은 RAM에 담을 수 있는 크기 이상으로 확장되지 않는다는 것입니다. 많은 제품(예: neo4j, Memgraph, FalkorDB 등)은 전체 그래프를 메모리에 상주시킵니다. 40 GB 그래프는 40 GB 메모리를 요구합니다 — 인스턴스당. 지역별, 테넌트별, 파드별로 복제본을 원하시나요? 비용이 배가됩니다. 그리고 특정 크기를 넘어서면 아예 로드되지 않습니다. 예를 들어 9천만 노드 / 15억 엣지 Wikidata 그래프는 ~64–128 GiB 상주 메모리가 필요하므로 인메모리 엔진은 전혀 열 수 없습니다.
Slater는 그에 대한 반박입니다. 그래프를 메모리에 로드하는 대신 오프라인에서 한 번 컴파일합니다. slater-build는 데이터를 콘텐츠 주소 지정 방식의 불변 온디스크 이미지로 변환하고, 원하는 수의 Slater 서버가 그 이미지를 Bolt 프로토콜로 서비스합니다(따라서 기존 neo4j 드라이버가 그대로 동작합니다). 블록을 요청 시 페이지인하고 고정된 캐시 예산만 상주시키는 방식입니다. 이것이 동일한 9천만 노드 그래프를 수백 MB의 RAM으로 서비스하는 이유입니다 — 그래프 크기와 메모리 비용이 분리됩니다. 4 GB 그래프와 400 GB 그래프를 서비스하는 데 필요한 RAM은 동일하므로, 저렴하고 상태 없는 읽기 복제본을 팬아웃하고 힙(heap)이 아닌 스토리지가 그래프를 보유하게 합니다.
따라서 RAG 뒤의 지식 그래프, 추천 및 신원 그래프, 의존성 그래프 — 저렴하고 자주 쿼리하고 싶은 크고 연결된 모든 것 — 에 자연스럽게 적합합니다. 디스크 기반 벡터 검색이 그래프 바로 옆에 있으므로, 같은 엔진이 임베딩의 검색 계층도 담당합니다.
하지만 한 번 컴파일한다고 해서 고정된 것은 아닙니다. 그 이미지는 **기본(base)**이지 최종 상태가 아닙니다. 옵트인 쓰기 계층이 그 위에 있으므로, 라이브 그래프를 재빌드 없이 수정하고 확장할 수 있습니다.
코어는 불변이지만 그래프는 불변이 아닙니다. 쓰기 가능 계층(delta.enabled)을 켜면 Bolt로 쓰기를 수행할 수 있습니다. — 속성 하나를 수정하고, 노드를 추가하고, 엣지를 철회하세요 — 이미지를 재빌드하지 않아도 변경 사항이 내구성 있게 저장됩니다. 읽기 측면에서 비용을 낮게 유지하는 비결은 쓰기가 어디에 저장되는가입니다.
쓰기는 불변 코어 위의 로그 구조 병합(LSM) 계층에 누적됩니다. 즉, 쓰기-어헤드 로그와 인메모리 테이블이 있고, 불변 델타 세그먼트로 넘쳐 흐르며, 주기적인 **통합(consolidation)**을 통해 새 코어로 접혀 들어갑니다. 이를 통해 얻는 이점은 다음과 같습니다.
count(*), 레이블 및 관계 유형 주변값(marginals) — 은 쓰기가 쌓여 있어도 메타데이터 읽기로 유지됩니다. 델타는 자체 카운터를 유지하므로, 50만 건의 대기 중인 쓰기가 있는 91.6M 노드 코어에 대한 count(*)는 블록 하나를 건드리지 않고도 수십 밀리초 안에 응답합니다.fsync 후에만 SUCCESS를 반환합니다. 쓰기를 그룹화하면 비용이 저렴합니다 — 쓰기-UNWIND는 행마다가 아니라 배치마다 하나의 fsync를 커밋합니다.MERGE / MATCH … SET / DELETE (및 CREATE / REMOVE, 분리 삭제, 관계 쓰기) — 또는 동일한 경로로 내려가는 ISO GQL 데이터 수정 문(INSERT / SET / REMOVE / DELETE). 데이터가 이미 정리된 방식으로 노드와 엣지에 대해 수정, 삽입, 업서트, 철회를 수행합니다.계층이 꺼진 상태(기본값)에서는 Slater가 순수한 불변 코어만 서비스하고 쓰기를 거부합니다. 전체 모델은 쓰기 가능 계층을 참조하세요.
이름에 대하여. Slater는 Archer (훌륭한 쇼)에 나오는 CIA 요원의 이름을 따서 지어졌습니다. 그 요원은 단 하나의 이름으로 불리기를 고집합니다 — "그냥… Slater" — 그리고 제가 가장 좋아하는 캐릭터 중 하나이기도 합니다. 자세한 내용은 캐릭터 위키 페이지를 참조하세요.
MERGE / SET / DELETE, 그룹 커밋 및 fsync 내구성, 통합을 통해 새 코어로 접힘. 읽기는 이에 대한 비용을 부담하지 않습니다.current 포인터를 원자적으로 전환하면 서버가 이를 인식합니다. 모든 블록이 체크섬 처리되므로, 절반만 복사된 이미지는 서비스되지 않고 거부됩니다.