ThingsDB의 핵심 메커니즘 이해

발행: (2025년 12월 23일 오전 12:46 GMT+9)
6 min read
원문: Dev.to

Source: Dev.to

Query Handling

ThingsDB 노드에 쿼리가 전송되면, 먼저 노드는 자신의 상태를 확인합니다.

  • AWAY mode – 노드는 요청을 로컬에서 처리하지 않고, 클러스터 내 다른 활성 노드로 쿼리를 전달합니다. 이를 통해 클라이언트는 차단된 연결을 경험하지 않게 됩니다.

노드가 쿼리를 수락하면 내부 캐시를 확인합니다:

  • Cache hit – 동일한 쿼리가 이전에 이미 처리된 적이 있어, ThingsDB는 컴파일을 건너뛰고 사전 컴파일된 버전을 사용합니다.
  • Cache miss – 새로운 쿼리이며, ThingsDB가 컴파일 과정을 시작합니다.

컴파일 중에 엔진은 해당 쿼리가 **변경(change)**이 필요한지 판단합니다.

Read‑only Queries

데이터 변경이 필요하지 않다면, 쿼리는 즉시 해당 노드에서 실행됩니다. 다른 노드가 관여하지 않으므로 읽기 작업이 매우 빠릅니다.

Procedures

프로시저는 항상 사전 컴파일됩니다. ThingsDB는 즉시 해당 프로시저가 변경이 필요한지 여부를 알 수 있어, 소중한 마이크로초를 절감합니다.

Change Handling

쿼리가 데이터를 수정해야 할 경우, ThingsDB는 다음 Change ID를 얻기 위한 “전투”를 시작합니다:

  1. 현재 전역 Change ID를 확인하고 다음 증가값(현재 + 1)을 제안합니다.
  2. 쿼럼 기반 합의를 통해 다수 노드가 이 ID에 동의해야 합니다.

합의가 이루어지면 변경이 처리됩니다. 컬렉션에 대한 모든 수정은 이 특정 ID에 묶이며 클러스터 전체에 동기화되어, 모든 노드가 정확히 같은 순서로 변경을 처리하고 완벽한 데이터 일관성을 유지합니다.

Futures

ThingsDB는 Futures를 사용해 복잡한 로직을 처리합니다. 쿼리에 하나 이상의 Future가 포함되어 변경이 필요할 경우, 각 Future는 자체 Change ID를 받을 수 있습니다. 이 최적화는:

  • 외부 모듈 호출 중 시스템이 잠기는 것을 방지합니다.
  • 무거운 “변경” 로직을 프로시저 또는 쿼리의 나머지 부분과 격리합니다.

전략 팁:
프로시저가 대부분 읽기 전용이지만 가끔 데이터를 쓰는 경우, 쓰기 부분을 Future로 감싸세요. 이렇게 하면 매 호출마다 전역 Change를 생성하지 않아도 됩니다(ThingsDB 책의 예시 참고).

Data Persistence

ThingsDB는 두 가지 메커니즘을 사용해 영속성을 보장합니다:

  • Full State Dumps – 특정 시점의 전체 데이터 상태 스냅샷.
  • Archive Files – 개별 변경 사항을 연속적으로 기록한 로그.

Node Boot and Recovery

노드가 부팅될 때는 엄격한 복구 절차를 따릅니다:

  1. 마지막 Full State Dump를 로드합니다.
  2. 해당 덤프에서 마지막 Change ID를 확인하고, Archive Files에 기록된 이후의 모든 변경을 재생합니다.
  3. 피어 노드가 Away 모드에 들어가기를 기다립니다. 부팅된 노드는 마지막으로 처리한 Change ID를 보고하고, Away 노드는 누락된 델타를 동기화합니다.

노드가 크게 동기화가 안 된 경우(또는 새 노드가 추가된 경우) Full Synchronization이 수행되어 전체 상태 덤프를 처음부터 전송합니다.

Away Mode

Away mode는 다운타임 없이 유지보수를 수행하기 위한 ThingsDB의 메커니즘입니다. 노드가 Away mode에 있는 동안 수행되는 무거운 작업에는 다음이 포함됩니다:

  • Full State Dumps(스냅샷)
  • Garbage Collection(메모리 관리)
  • Scheduled Backups(예정 백업)
  • 피어 노드 동기화

Away mode 중에도 노드는 클라이언트와 통신하지만, 쿼리를 전달하여 시스템이 응답성을 유지하도록 합니다. 변경 사항은 백그라운드에서 수집되어 노드가 Away mode를 종료하고 클러스터에 재가입하기 직전에 적용됩니다. 동시에 하나의 노드만 Away mode에 있을 수 있어, 나머지 클러스터는 주요 작업을 계속 수행할 수 있습니다.

Summary

블로킹 유지보수 작업을 클라이언트 요청과 분리하고, 변경에 대해 정교한 합의 메커니즘을 사용함으로써 ThingsDB는 고성능·고내구성을 갖춘 데이터베이스 경험을 제공합니다.

Next up: the client side.

Back to Blog

관련 글

더 보기 »

데이터베이스 샤딩 vs 파티션

데이터베이스 샤딩과 파티션의 차이점 데이터베이스 샤딩이란 - Horizontal Data Distribution – 데이터가 shards로 분할되어 각각 별도의 …

Bf-트리: 페이지 장벽을 깨다

안녕하세요, 저는 Maneshwar입니다. 저는 FreeDevTools – 온라인 오픈‑소스 허브를 개발하고 있습니다. 이 허브는 dev tools, cheat codes, 그리고 TLDRs를 한 곳에 모아 쉽게 이용할 수 있게 합니다.