VictoriaLogs vs Elasticsearch — 로그 한 줄이 저장되는 모양과 자원 차이

VictoriaLogs 문서는 Elasticsearch보다 RAM을 최대 30배, 디스크를 최대 15배 적게 쓴다고 말합니다. 이 글은 그 말을 믿을지 정하기보다, 두 엔진이 로그 한 줄을 저장하는 모양을 나란히 놓고 차이가 어디서 생기는지를 따라갑니다. 쿼리 언어와 에코시스템의 비교는 범위 밖입니다.

조사 기준일은 2026-11-09이고, 버전은 VictoriaLogs v1.53.0(2026-10-01 릴리스)과 Elasticsearch 9.5.6(2026-11-02 릴리스)입니다. Elasticsearch는 9.0부터 logs-*-* 데이터 스트림에 logsdb 모드가 기본으로 켜져서, 8.x 시절의 기본 설정과는 비교 대상이 다릅니다. VictoriaLogs의 데이터 모델은 로그 한 줄의 저장 경로에서 먼저 다뤘습니다.

Elasticsearch가 로그 한 줄을 저장하는 모양

Elasticsearch에서 인덱스는 샤드로 나뉘고, 샤드 하나가 곧 Lucene 인덱스입니다. 샤드 안의 데이터는 한 번 쓰면 바뀌지 않는 세그먼트에 쌓이고, 작은 세그먼트는 백그라운드에서 큰 세그먼트로 병합됩니다.

기본(standard) 모드에서는 같은 값이 세그먼트 안에 세 번 들어갑니다. 필드마다 term에서 문서 목록으로 가는 역색인이 있고, 정렬과 집계를 위한 컬럼 구조인 doc_values가 있으며, 받은 JSON을 그대로 보관하는 _source가 있습니다. 세그먼트의 메타데이터와 매핑 필드 정보 일부는 JVM 힙에 올라가고, 데이터 파일은 힙 바깥의 파일시스템 캐시가 맡습니다.

VictoriaLogs가 로그 한 줄을 저장하는 모양

VictoriaLogs는 로그를 UTC 하루 단위 파티션에 넣습니다. 파티션 안에서 datadb는 불변 part를 모아 두고, indexdb는 그날 어떤 스트림이 있는지를 적은 카탈로그입니다. part 안의 블록은 한 스트림의 행만 담고, 블록은 필드별 컬럼 파일로 갈라집니다. 컬럼마다 블룸 필터가 짝을 이루어, 검색어가 없다고 확실한 블록은 열지 않습니다. 스트림과 파티션 배정은 1편에서 다뤘습니다.

원본 JSON은 따로 두지 않고 평탄화한 필드 컬럼만 저장합니다. 메모리에 상주하는 것은 블록의 위치를 찾는 metaindex 정도이고, 나머지 데이터와 블룸 파일은 운영체제의 페이지 캐시에 맡깁니다. 아래 도식은 앞 도식과 같은 열과 행에 같은 역할을 놓았습니다. 달라진 곳은 indexdb가 생긴 자리와, 원본 문서 자리가 비어 있는 점입니다.

구조 대응표

자원 차이가 생기는 지점

차이가 생기는 곳은 다섯 군데입니다. 근거 열의 “공식 문서"는 양쪽 공식 문서가 구조를 서술한다는 뜻이고, “구조상 추정"은 구조에서 따라 나오지만 크기를 비교한 공식 수치는 없다는 뜻입니다.

압축률 항목은 VictoriaLogs의 고유한 장점이라기보다 Elasticsearch의 standard 모드와 견줄 때 보이는 차이입니다. logsdb는 host.name과 @timestamp로 정렬하고 ZSTD를 기본으로 써서 같은 방향의 최적화를 합니다. 원본 중복도 마찬가지여서, 유료 구독의 synthetic _source를 쓰면 _source를 따로 저장하지 않아도 됩니다.

쿼리가 데이터를 읽지 않고 건너뛰는 경로도 구조의 일부입니다. 인덱스가 작은 대신 읽기 전에 후보를 줄이는 단계가 여럿 있습니다.

벤치마크의 수치와 조건

배수를 비교하기 전에 측정한 쪽과 조건부터 봐야 합니다. 아래 수치는 모두 표에 적은 시점의 버전과 설정에서 나온 값입니다.

첫 줄의 배수는 메모리 약 31배, 디스크 약 13배이며 문서가 말하는 30배와 15배는 이 측정이 출처입니다. 이 측정에는 logsdb가 없었고, 메모리 지표가 페이지 캐시를 포함하는지도 확인하지 못했습니다. JSONBench의 배수는 3.2배와 1.9배로 훨씬 작은데, 로그가 아닌 이벤트 JSON이고 VictoriaLogs는 구조를 보존하지 않으며 Elasticsearch logsdb는 쓰지 않았다는 한계가 있습니다. VictoriaLogs와 Elasticsearch logsdb를 직접 견준 공개 벤치마크는 찾지 못했습니다. 2023년의 15배와 30배가 9.x 기준으로 다시 측정된 적은 없다는 뜻입니다.

Elasticsearch가 앞서는 곳과 VictoriaLogs의 한계

VictoriaLogs에서 고가용성이 필요하면 vlagent로 독립된 클러스터 두 벌에 이중 전송하고 vmauth로 라우팅하는 방법이 문서에 있습니다. 오브젝트 스토리지가 없는 동안의 대안은 스냅샷을 rclone으로 S3에 백업하거나, NVMe 인스턴스에서 HDD 인스턴스로 오래된 파티션을 옮기는 것입니다.

조건별 선택

로그를 주로 시간 범위와 스트림으로 좁혀서 읽고, 보존 기간 안의 데이터를 로컬 디스크에 둘 수 있다면 VictoriaLogs의 구조가 자원 면에서 유리하게 작동합니다. 이 판단은 구조에서 나오며, 크기는 여러 측정에서 방향이 일치하지만 배수는 조건에 따라 2배 안팎부터 30배까지 갈립니다.

반대로 검색 결과에 점수를 매기거나 Kibana와 보안 기능을 쓰고 있다면 역색인과 에코시스템을 포기하는 비용이 자원 절감보다 클 수 있습니다. 오래된 로그를 오브젝트 스토리지에 두는 구성이나 클러스터 내부 복제가 요구 조건이라면 지금은 Elasticsearch 쪽만 문서화된 길이 있습니다.

이미 Elasticsearch 9.x의 logsdb를 쓰고 있다면 이전의 이득은 이 글의 배수보다 작을 수 있습니다. 이전을 검토할 때는 자신의 로그를 같은 조건으로 두 엔진에 흘려 보내 측정하는 것이 이 글의 어떤 수치보다 신뢰할 만합니다.