중복 감지, 무조건 해시셋(Hash Set)이 답은 아니다!

본 분석에서는 밀집된 32비트 정수(Dense 32-bit Integers)의 경우, 해시셋(Hash Set)보다 비트셋(Bitset)이 압도적인 성능 우위를 보인다고 강조한다. 비트셋(Bitset)은 단일 비트 연산으로 멤버십 테스트를 수행하는 반면, 해시셋(Hash Set)은 해싱, 버킷 탐색, 포인터 추적 등 추가적인 오버헤드를 발생시킨다. 특히, 100만 개의 요소를 처리할 때 비트셋은 5.1 나노초, 해시셋은 483 나노초로, 약 94배의 성능 차이를 보였다. 이는 키(Key)가 이미 배열 인덱스 형태를 띨 경우, 해싱(Hashing)을 사용하는 것은 불필요한 작업임을 시사한다.

긴 문자열(Long Strings)의 경우, 해시 테이블(Hash Table) 구조 자체보다 전체 키(Key) 비교 비용이 성능에 더 큰 영향을 미친다. 지문(Fingerprint) 기반 정렬은 XXH3 해시를 사용하여 64비트 지문을 생성하고, 지문 충돌 시에만 전체 문자열 비교를 수행함으로써 성능을 향상시킨다. 500바이트 문자열 100만 개 처리 시, 지문 기반 정렬은 해시셋(Hash Set)보다 약 2.7배 빠르다. 이는 긴 문자열 비교를 최소화하여 캐시 라인(Cache Line) 접근 비용을 줄이는 효과를 가져온다.

스트리밍 환경에서 중복 감지(Duplicate Detection)는 메모리 내 슬라이딩 윈도우(Sliding Window), RocksDB, PostgreSQL 등 다양한 백엔드(Backend)를 사용할 수 있다. 메모리 내 슬라이딩 윈도우(Sliding Window)는 가장 빠르지만, 데이터 손실 가능성이 있다. RocksDB는 로컬 디스크에 데이터를 저장하여 내구성을 확보하며, PostgreSQL은 트랜잭션(Transaction)을 통해 강력한 일관성을 제공한다. 성능은 메모리(Nanoseconds) → RocksDB(Microseconds) → PostgreSQL(Milliseconds) 순으로 낮아지며, 각 계층은 서로 다른 보장 수준을 제공한다.

내구성이 필요한 중복 감지(Duplicate Detection)의 경우, 배칭(Batching)은 성능 최적화가 아닌 필수적인 설계 요소이다. PostgreSQL의 경우, 배치 크기 1과 1000 사이에서 60배의 성능 차이를 보이며, RocksDB 역시 배칭을 통해 성능 향상을 얻을 수 있다. 즉, 모든 이벤트를 개별적으로 커밋(Commit)하는 대신, 일정량의 이벤트를 묶어 한 번에 커밋하는 것이 중요하다. 이는 데이터베이스(Database)의 I/O 부하를 줄여 전반적인 시스템 성능을 향상시키는 핵심 전략이다.