VictoriaLogs, 로그 저장의 비밀을 파헤치다

VictoriaLogs는 로그 데이터를 행(Row) 단위가 아닌 필드(Field)별 컬럼(Column)으로 저장하는 컬럼 기반 아키텍처(Columnar Architecture)를 채택했습니다. 이는 쿼리 시 필요한 필드만 읽어오도록 하여 디스크 I/O(Disk I/O)를 획기적으로 줄여줍니다. 특히 로그에 많은 필드가 포함될수록 이러한 이점은 더욱 커지며, `fields` 파이프를 통한 필드 선택적 조회(Selective Field Retrieval)는 성능 향상에 크게 기여한다고 설명합니다.

로그는 스트림 필드(Stream Fields)에 따라 그룹화되어 단일 스트림으로 취급되며, 이는 데이터 격리 아키텍처(Data Isolation Architecture)의 핵심입니다. 동일한 스트림 필드를 가진 로그들은 디스크 상에서 함께 저장되어 높은 압축률(High Compression Ratio)을 달성합니다. 운영자는 스트림 필드를 안정적이고 낮은 카디널리티(Low Cardinality)로 유지하는 것이 중요하며, 이는 데이터 검색 성능(Data Retrieval Performance)과 저장 공간 효율성(Storage Efficiency) 모두에 긍정적인 영향을 미칩니다.

로그 데이터는 메모리 버퍼(Memory Buffer)에서 인메모리 파트(In-memory Part)로 플러시(Flush)된 후, 디스크로 내구성 있는 파트(Durable Parts)로 저장됩니다. 이 과정에서 인메모리 데이터 플러시 간격(-inmemoryDataFlushInterval) 설정은 실시간 쿼리 가능성과 데이터 안전성 사이의 균형을 맞춥니다. 파트는 불변(Immutable)하므로 스냅샷 및 백업이 용이하며, 작은 파트(Small Parts)와 큰 파트(Big Parts)의 병합 전략은 디스크 쓰기 횟수를 최소화합니다.

각 파트 내의 블록(Block)은 블룸 필터(Bloom Filter)를 사용하여 특정 키워드나 토큰(Token)의 존재 여부를 빠르게 판단합니다. 블룸 필터는 '아마도 존재할 수 있음' 또는 '절대 존재하지 않음'이라는 확률적 정보를 제공하여, 실제 데이터 블록을 읽기 전에 불필요한 검색 범위를 효과적으로 제거합니다. 이는 전문 검색(Full-Text Search) 성능을 크게 향상시키는 핵심 요소입니다.

커뮤니티에서는 VictoriaLogs의 빠른 쿼리 속도와 높은 처리량에 대한 긍정적인 경험이 공유되었습니다. 특히 Loki는 레이블(Label) 기반 필터링에 의존하며 메시지 자체를 토큰화하지 않아 쿼리 시 CPU 비용이 높다는 지적이 있었습니다. 반면 VictoriaLogs는 메시지 토큰화 및 컬럼 기반 저장으로 쿼리 측면에서의 비용 효율성(Cost-Effectiveness on Query Side)이 훨씬 높다는 의견이 지배적입니다. 저사양 하드웨어에서도 상당한 로그 처리량을 감당한다는 경험담도 있었습니다.