안녕하세요! 저는 Nim으로 작성된 오픈 소스 NoSQL 문서 및 벡터 저장소인 RocheDB를 구축하고 있습니다.

이 프로젝트는 간단한 질문에서 시작되었습니다:

비용이 많이 드는 검색 (retrieval) 및 애플리케이션 프로세싱이 시작되기 전에, 데이터베이스가 관련 없는 데이터를 여는 것을 피할 수 있다면 어떨까?

현대 시스템은 문서, 테넌트 (tenant) 데이터, 애플리케이션 상태, 임베딩 (embeddings), 로그, 그리고 지식 베이스를 축적합니다. 하나의 요청은 궁극적으로 유용하지 않은 데이터를 읽고, 전송하고, 메모리에 유지하고, 재순위화 (reranking)하고, 요약하거나, LLM 컨텍스트로 전달하는 데 상당한 리소스를 소비할 수 있습니다.

RocheDB는 애플리케이션의 자연스러운 데이터 지역성 (data locality)을 저장 및 검색 모델의 일부로 만들려는 저의 시도입니다.

핵심 아이디어: 링 (ring)

RocheDB는 의미론적 및 구조적 배치 단위로 **링 (ring)**을 사용합니다.

애플리케이션 또는 가져오기 규칙 (import rule)은 데이터를 작성할 때 링을 선택합니다. 동일한 링은 이후 읽기 작업의 초기 범위를 정의할 수 있습니다.

docs/japan/support
tenant/acme/orders/2026
users/123/profile

이것들은 단순한 디렉토리와 같은 이름이 아닙니다. 이것들은 검색 공간에서의 좌표입니다. 동일한 링에 배치된 레코드들은 검색을 위한 유용한 이웃이 될 것으로 기대됩니다.

이 점이 링을 일반적인 컬렉션 레이블과 다르게 만듭니다. 링은 다음 두 가지를 모두 나타냅니다:

• 레코드가 어디에 속하는지
• 요청을 위해 어떤 로컬 영역을 가장 먼저 열어야 하는지

링은 B+ 트리 (B+ tree)가 아닙니다

RocheDB의 링은 B+ 트리를 대체하기 위한 것이 아닙니다.

A B+ 트리는 정렬된 키 (ordered keys)에 따라 데이터를 구성합니다. 이는 기본 키 (primary-key) 읽기, 보조 인덱스 (secondary-index) 조회, 시간 범위, 정렬된 페이지네이션 (sorted pagination), 그리고 키 조회나 키 범위 스캔으로 표현할 수 있는 기타 쿼리에 탁월합니다.

B+ 트리는 다음과 같이 답합니다:

이 키 또는 키 범위는 어디에 있는가?

RocheDB 링은 다음과 같이 답합니다:

이 컨텍스트에서 데이터의 어느 로컬 영역을 가장 먼저 열어야 하는가?

이들은 시스템의 서로 다른 부분을 최적화합니다. B+ 트리는 정렬된 키 접근을 효율적으로 만듭니다. 링은 더 비용이 많이 드는 다운스트림 작업이 시작되기 전에 의미론적 후보 집합 (semantic candidate set)을 줄이려고 시도합니다.

왜 궤도 역학 (orbital mechanics)인가?

명칭과 모델의 일부는 궤도 역학 (orbital mechanics)에서 영감을 받았습니다.

궤도 시스템 (orbital system)에서 물체의 위치는 주기 (period), 위상 (phase) 또는 에포크 (epoch), 이심률 (eccentricity), 장반경 (semi-major axis)과 같은 간결한 궤도 요소 (orbital elements)를 통해 추정될 수 있습니다.

RocheDB는 이를 엔지니어링 추상화 (engineering abstraction)로 사용합니다.

링 (ring)은 의미론적 데이터 궤도 (semantic data orbit)와 같습니다. 링 내의 레코드들은 주기 (period) 및 headAngle과 같은 값을 포함한 경량 궤도 메타데이터 (orbital metadata)를 상속받습니다. 이를 통해 링은 배치 단위 (placement unit)이자 쿼리 계획 (query plan)의 작은 부분으로서 작동할 수 있습니다.

링 (rings), 궤도 (orbits), 조우 (encounters), 집적 (accretion)과 같은 천체 역학 (celestial-mechanics) 어휘가 핵심 가치 제안 (value proposition)은 아닙니다. RocheDB는 물리 시뮬레이터가 아닙니다.

유용한 아이디어는 배치 (placement), 이동 (movement), 근접성 (proximity), 그리고 검색 범위 (retrieval scope)가 중앙 디렉토리 (central directory) 뒤에 숨겨지거나 매 요청마다 재구성되는 대신, 명시적이고 관찰 가능할 수 있다는 점입니다.

요약하자면: RocheDB는 비용이 많이 드는 검색 (retrieval), 재순위화 (reranking), 메모리 사용 (memory use), 네트워크 전송 (network transfer), 또는 LLM 컨텍스트 구축 (LLM context construction)이 시작되기 _전_에, 애플리케이션 수준의 지역성 (application-level locality)을 사용하여 후보 집합 (candidate set)을 줄입니다.

작은 예시

다음은 Nim에서 링 배치 (ring placement)가 어떻게 이루어지는지 보여주는 예시입니다:

import rochedb

var db = rochedb.open(dataDir = "data")
...

만약 애플리케이션이 이미 일본어 문서가 필요하다는 것을 알고 있다면, 해당 링에서 시작할 수 있습니다:

for item in db.listByRing("docs/japan"):
  echo item.payload

동일한 아이디어가 벡터 검색 (vector retrieval)에도 적용됩니다:

let query = @[1.0'f32, 0.0'f32]

let hits = db.retrieve(
...

중요한 세부 사항은 docs/japan이 검색 후에 추가되는 레이블 (label)이 아니라는 점입니다. 이는 쓰기 시점 (write time)의 배치 결정 (placement decision)이자 읽기 (reads)를 위한 초기 범위 (initial scope)입니다.

애플리케이션은 여전히 유용한 링을 설계할 책임이 있습니다. 하지만 많은 애플리케이션이 이미 테넌트 (tenant), 지역 (region), 제품 영역 (product area), 문서 도메인 (document domain), 사용자 (user), 또는 시간 범위 (time range)와 같은 의미 있는 지역성 (locality)을 알고 있습니다. RocheDB는 데이터베이스가 해당 정보를 직접 사용할 수 있도록 하려는 시도입니다.

이것이 AI, RAG 및 웹 시스템에 중요한 이유

트랜잭션 워크로드 (Transactional workloads)의 경우, 효율적인 인덱스 조회 (Indexed lookup)만으로도 충분한 경우가 많습니다.

검색 중심의 워크로드 (Retrieval-heavy workloads)에서는 단일 행을 찾는 것이 항상 비용이 많이 드는 부분은 아닙니다. 더 큰 비용은 조회 후 의미론적으로 취약한(semantically weak) 광범위한 후보군을 처리하는 데서 발생할 수 있습니다.

이는 특히 AI 및 RAG 시스템과 밀접한 관련이 있습니다. 데이터베이스가 특정 키 범위 (Key range)를 효율적으로 검색할 수는 있지만, 그 결과에는 여전히 많은 취약한 후보들이 포함될 수 있습니다.

그러한 후보들은 이후 임베딩 (Embedded), 재순위화 (Reranked), 요약 (Summarized)되거나, 메모리에 유지되거나, LLM으로 전송될 수 있습니다.

RocheDB는 이러한 후보군 (Candidate set)을 더 이른 단계에서 줄이려고 시도합니다.

링 배치 (Ring placement)가 유용한 지역성 (Locality)을 반영할 때, 기대할 수 있는 이점은 다음과 같습니다:

• 순위를 매겨야 할 레코드 수 감소
• 메모리에 유지되는 페이로드 (Payloads) 감소
• 서비스 간 전송되는 바이트 (Bytes) 감소
• 다운스트림 LLM (Downstream LLMs)으로 전달되는 토큰 (Tokens) 감소
• 테넌트 (Tenants), 리전 (Regions), 백업 (Backups), 마이그레이션 (Migrations) 및 권한 부여 (Authorization)를 위한 더 명확한 경계

초기 수치가 보여주는 것

현재의 벤치마크 (Benchmarks)가 RocheDB가 모든 B+ 트리 기반 데이터베이스보다 보편적으로 더 빠르다고 주장하는 것은 아닙니다.

이들은 더 좁은 가설을 테스트합니다: 링 배치 (Ring placement)가 유용한 지역성 (Locality)을 포착할 때, RocheDB가 읽기 경로 (Read path)를 가볍게 유지하면서 워킹 셋 (Working set)과 다운스트림 후보군 (Downstream candidate)의 양을 줄일 수 있는가?

워킹 셋 (Working-set) 벤치마크

100개의 링과 10,000개의 문서로 테스트했을 때, 쿼리당 스캔된 레코드 수는 10,000개에서 100개로 감소했습니다. 이는 후보 워킹 셋 (Candidate working set)이 99% 감소했음을 의미합니다.

메모리 압박 (Memory-pressure) 벤치마크

100개의 링, 100,000개의 문서, 그리고 512바이트 페이로드 환경에서 쿼리당 후보 메모리는 93.079 MiB에서 0.931 MiB로 감소했습니다. 이 또한 99% 감소한 수치입니다.

RAG 지향 사례

고정된 품질의 합성 RAG (Synthetic RAG) 사례에서, 스캔된 레코드는 8,000개에서 1,000개로 감소했고, 쿼리당 토큰은 3,960개에서 657.8개로 감소했습니다.

400개의 문서와 6개의 링을 사용하는 AI/RAG 사례 연구에서는, 재현율 (Recall)을 1.000으로 유지하면서 스캔된 레코드는 400개에서 40개로, 쿼리당 토큰은 615.2개에서 231.6개로 감소했습니다.

이것은 보편적인 성능 주장이라기보다는 초기 단계의 재현 가능한 결과입니다.

이 결과는 링 배치 (ring placement)가 유용한 지역성 (locality)을 나타내는지에 따라 달라집니다. 벤치마크 스크립트, 해당 조건 및 제한 사항은 프로젝트 저장소에 있습니다.

소스 코드, 문서, 벤치마크 스크립트 및 이슈 트래킹은 github.com/puffball1567/rochedb에서 확인할 수 있습니다.

장기적인 희망

당장의 목표는 실용적입니다: 비용이 많이 드는 다운스트림 프로세싱 (downstream processing) 이전에 불필요한 후보 데이터를 줄이는 것입니다.

만약 이것이 시간이 흐름에 따라 AI 및 RAG 시스템의 토큰 소비를 낮추고, 불필요한 읽기 및 연산에 소모되는 에너지를 줄이며, 메모리, 스토리지 및 컴퓨팅 하드웨어 용량을 지속적으로 확장해야 하는 압박을 완화하는 데 기여할 수 있다면, 그것은 의미 있는 결과가 될 것입니다.

RocheDB 단독으로 토큰, 에너지 또는 반도체 수요 문제를 직접 해결하지는 못할 것입니다.

하지만 불필요한 데이터 이동을 피하는 것은 유용한 시작점이 될 것으로 보입니다.

현재의 경계

RocheDB는 모든 데이터베이스나 모든 B+ 트리 (B+ tree) 사용 사례를 대체하기 위한 것이 아닙니다.

이것은 애플리케이션이 이미 의미 있는 지역성을 가지고 있을 때 가장 흥미롭습니다:
테넌트 (tenants), 사용자 (users), 지역 (regions), 주제 (topics), 문서 그룹 (document groups), 시간 파티션 (time partitions),
프롬프트/컨텍스트 저장소 (prompt/context stores), 또는 RAG 문서 컬렉션 (RAG document collections).

현재는 기술 프리뷰 (technical preview) 단계입니다. 저는 이것을 PostgreSQL, Redis, MongoDB 또는 전용 벡터 데이터베이스 (vector databases)를 대체할 프로덕션용 솔루션으로 제시하는 것이 아닙니다.

RocheDB는 Nim API, CLI, 서버 모드, C ABI 및 언어 드라이버를 제공합니다. 이 시리즈에서 저는 링 배치 (ring placement), 검색 (retrieval), 클러스터 동작 (cluster behavior), 벤치마크, Nim 구현 세부 사항 및 드라이버 개발에 대해 작성할 계획입니다.

RocheDB가 불필요한 데이터 이동을 줄이는 실용적인 실험으로서, 그리고 지역성 우선 (locality-first) 데이터베이스 모델이 어떤 모습일 수 있는지 탐구하는 방법으로서 유용하기를 바랍니다.

피드백, 질문 및 사용 사례는 언제나 환영합니다.