블룸 필터의 거짓 양성 원리와 RocksDB 구현 선택
블룸 필터가 부재를 빠르게 판정하고 거짓 양성을 허용하는 이유, 그리고 RocksDB 필터 형식·비트 예산의 선택을 설명합니다.
발행·오류 제보: infostoa · 편집 기준
이 글의 개별 작성자와 전문 검토자 정보는 제공되지 않습니다.
비트 배열과 확률적 멤버십 판정
이론적 기본형은 0으로 초기화한 m비트 배열에 각 원소의 해시 위치 k개를 1로 표시합니다. 조회할 때 확인한 비트 중 하나라도 0이면, 같은 삽입·조회 규칙을 지킨 필터에서는 원소가 없다고 판정할 수 있습니다. 모두 1이면 있을 가능성만 뜻하므로 원본 저장소에서 다시 확인해야 합니다. 수학 설명은 균등하고 적절히 분포된 해시를 가정하지만, 실제 구현은 여러 위치를 만들기 위해 해시 계산을 최적화할 수 있으며 암호학적 해시가 필요하다는 뜻은 아닙니다.
거짓 양성 확률과 매개변수 절충
삽입 전 비트가 0일 확률을 (1 − 1/m)^(kn)으로 근사하면, 삽입되지 않은 원소가 검사한 k개 비트가 모두 1일 확률은 대략 (1 − e^(−kn/m))^k입니다. 이는 원소 수 n, 배열 크기 m, 해시 수 k를 둔 이상화된 기본형의 근사식입니다. 이 모델에서 k를 연속값처럼 최적화하면 k ≈ (m/n) ln 2가 나오며, 실제로는 정수 k와 구현의 해시·메모리 배치를 골라야 합니다. RocksDB 설정의 false-positive 수치를 다른 구현이나 키 분포에 그대로 적용하지 마세요.
RocksDB 형식이 바꾸는 공간·조회 절충
RocksDB 문서는 블록 기반 형식과 SST 파일 전체를 대상으로 하는 full filter 등 형식별 구조를 설명합니다. 예를 들어 full filter는 파일의 키 해시를 더 넓게 보관하는 대신 한 조회에서 캐시 미스를 줄이도록 설계됐으며, 오래된 형식·새 형식과 버전에 따라 저장 공간과 거짓 양성 특성이 다릅니다. 문서는 생성 시점의 형식이 해당 SST 파일에서 사용되고 옵션으로 새 파일 형식을 선택할 수 있다고 설명합니다. 전체 키 필터와 prefix 필터 역시 동작과 조회 범위가 다르므로 버전과 옵션을 확인해야 합니다.
필터는 보조 색인이지 원본 데이터가 아니다
RocksDB 문서에 따르면 negative 결과는 해당 파일 또는 필터 범위에서 실제 키 검색을 생략하는 데 쓰일 수 있지만, positive 결과는 실제 키가 있는지 원본 데이터에서 확인해야 합니다. 기본 Bloom filter는 원소를 추가하는 정적 모델을 설명하므로 임의의 삭제·갱신 지원을 추정해서는 안 됩니다. prefix와 whole-key 설정도 조회 방식이 다릅니다. 필터는 저장 데이터를 대체하지 않으며, 선택한 필터 형식·키 수·비트 예산을 실제 워크로드에서 측정해야 합니다.
전문가 관점에서 보는 필터 선택과 검증
Bloom의 원 논문에서 중요한 운영 원칙은 오류를 허용해도 되는 위치와 실제 확인을 남겨야 하는 위치를 나누는 것입니다. 필터가 “있을 수 있다”고 답한 것은 데이터가 존재한다는 보증이 아닙니다. 잘못된 양성은 후속 저장소 조회로 확인해야 하며, 반대로 잘못된 음성은 정상 데이터를 놓칠 수 있어 삽입·조회 일관성과 갱신 절차를 지켜야 합니다. 이 구분은 수학식보다 먼저 애플리케이션의 정합성 요구사항으로 정해야 합니다.
RocksDB 프로젝트 문서는 각 필터 형식의 메모리와 캐시 동작을 설명하지만, 특정 형식이 모든 환경에서 가장 빠르다고 주장하지 않습니다. 데이터가 정렬·분할되는 방식, 키가 전체 키인지 prefix인지, 조회가 실제로 디스크 읽기를 생략하는지에 따라 결과가 달라집니다. 설정 이름만 보고 성능을 추정하지 말고, 사용하는 버전에서 실제 SST 구성과 옵션을 점검해야 합니다.
실무에서는 예상 키 수와 허용 가능한 추가 조회 비용을 먼저 정리한 다음 비트 예산을 바꿔 비교합니다. 대표적인 양성·음성 조회를 함께 재생하고, 메모리 사용량과 캐시 미스, 저장소 조회 횟수를 관찰하세요. 필터를 켜기 전후의 전체 응답 시간도 비교해야 합니다. 필터 조회 자체의 계산 비용이 절약한 작업보다 클 수도 있기 때문입니다.
따라서 블룸 필터는 정답을 저장하는 압축 색인이 아니라, 일부 조회를 빠르게 거르는 근사 구조입니다. 실제 키 검색을 유지하고, 오류 허용 여부를 먼저 정한 뒤, RocksDB의 형식과 작업량을 함께 측정할 때 그 절충을 안전하게 평가할 수 있습니다.
출처 및 기술 참고 문서: Bloom의 1970년 원 논문(PDF, Princeton 대학 아카이브), RocksDB Bloom Filter 공식 프로젝트 문서