"인덱스를 통째로 버리고 다시 만들어도 모든 인용은 같은 내용을 다시 찾아야 해. 마법이 아니라 계산이야."
버리는 인덱스와 오래 가는 인용
두 요구는 처음에 모순처럼 보여. 검색 인덱스는 파생 상태라서 의심스러우면 지우고 다시 만들어야 해. 하지만 인용은 오래도록 같은 텍스트를 가리켜야 하지. 인용이 인덱스 안의 chunk를 가리키는데 그 인덱스를 통째로 버려도 괜찮다는 말이 어떻게 동시에 참일까?
재구축은 새 이름 붙이기가 아니라 같은 값 다시 계산하기야
Lantern의 chunk id는 저장 순서가 아니라 내용에서 나와. 같은 원본을 같은 얼린 profile로 다시 나누면 각 chunk의 문서 해시와 문자 위치, profile id가 같고 따라서 id도 바이트 단위로 같아. 예전에 9f3ce1a7…을 가리키던 인용은 재구축 뒤에도 같은 id를 만나고, 그 id는 같은 문서의 같은 범위에 연결돼.
복구 절차는 지우고 다시 계산하는 것으로 끝나
인덱스가 오염되거나 원본과 어긋났다면 틀린 행을 찾아 하나씩 고치지 않아. 파생 상태를 지우고 권위 있는 소스를 다시 읽어. 차이를 맞추는 복잡한 코드도, 상태를 일일이 대조하다 예외를 놓칠 일도 없어. 같은 입력과 같은 규칙이 같은 결과를 만든다는 보장이 있으니, 건강한 인덱스를 처음부터 다시 얻을 수 있어.
대신 정말 귀한 상태를 헷갈리지 마
FTS 인덱스와 벡터, chunk 테이블은 다시 만들 수 있는 파생 상태야. captured 스냅샷과 뒤에서 만날 증거 레이어의 판단은 원본을 다시 읽는다고 되살아나지 않는 귀한 상태고. 전자는 과감히 버릴 수 있어야 하고 후자는 덧붙이기만 하며 지켜야 해. 시스템이 가진 모든 데이터가 어느 쪽인지 분명히 알아야 복구할 때 버려도 되는 것은 과감히 버리고, 잃으면 안 되는 것은 끝까지 보호할 수 있어.
여기서 말하는 내구성의 조건은 분명해. 원본 바이트와 얼린 profile이 같아야 같은 id가 돌아와. 그 조건 안에서는 인덱스와 구현, 기계가 달라져도 괜찮아. 어떤 입력을 고정해야 보장이 성립하는지 밝히는 것이 '영원히 안 깨진다'는 막연한 구호보다 훨씬 강한 계약이야.