dev.to

Valkey 9.2's new rdbcompression lz4 setting cuts a 1M-row RDB from 178MB to 35MB

Valkey 9.2의 RDB LZ4 압축, 100만 건 파일을 178MB에서 35MB로 줄여

Valkey 9.2.0-rc1에서 전체 RDB 스트림을 LZ4로 압축하자 반복 구조가 있는 데이터의 파일 크기가 약 80% 줄었습니다. 다만 데이터 종류에 따라 효과가 달랐고, 복제 압축 설정과 릴리스 노트 해석은 작성자가 댓글에서 정정·재검증하기로 했습니다.

에디터 노트

반복되는 값이 많은 데이터에서 파일 크기가 크게 줄었다는 측정은 구체적입니다. JSON과 로그에서 약 80% 감소한 결과와 토큰 데이터에서 4.7%만 줄고 SAVE 시간이 늘어난 결과가 함께 있어, LZ4의 이득을 데이터 특성에 따라 판단해야 한다는 설명도 뒷받침합니다. 다만 SAVE 시간은 CPU 사용량 측정이 아니며 작성자도 댓글에서 52%를 CPU 비용으로 해석한 표현을 바로잡았습니다. 복제 설정에 관한 본문의 단정은 현재 제시된 실험만으로 확정하기 어렵습니다. 댓글에서 작성자는 릴리스 노트에 rdbcompression 설정으로 전체 동기화를 압축한다는 조건이 적혀 있다고 확인했고, 자신의 시험에서 압축되지 않은 원인은 복제본의 지원 협상일 수 있다고 밝혔습니다. 따라서 복제에서 두 설정이 언제 각각 필요한지는 재시험 결과가 나와야 판단할 수 있습니다. 혼합 버전 복제본에서 BGSAVE가 두 번 실행됐다는 관찰과 압축 적용 여부를 INFO에서 확인하지 못했다는 관찰은 운영 시 확인할 비용과 가시성 문제로 남습니다.

AI 요약

Valkey 9.2.0-rc1의 RDB 압축 설정을 데이터 유형별로 측정하고 복제 동작까지 확인한 실험입니다. 작성자는 LZ4가 반복되는 구조를 가진 데이터에서는 파일 크기를 크게 줄이지만, 무작위 값에는 효과가 작고 저장 시간만 늘 수 있다고 보고합니다. 댓글에서 작성자는 복제 설정에 관한 일부 설명이 불확실하다고 정정했습니다.

RDB 파일 압축 측정

작성자는 사용자 프로필 형태의 JSON 문자열 100만 개를 넣고 각 설정에서 SAVE를 세 번 실행했습니다. 압축을 끈 파일은 180.3MB, 기본값인 문자열별 LZF 압축은 177.6MB였습니다. 전체 스트림에 LZ4를 적용하자 35.4MB로 줄었습니다. 최고 기록 기준 SAVE 시간은 각각 0.80초, 1.10초, 1.16초였습니다. LZ4 파일은 기본 LZF보다 80.1% 작았고, LZF보다 SAVE 시간이 약 5% 더 걸렸습니다.

공통 형식을 가진 합성 로그 20만 줄에서도 비슷한 차이를 보였습니다. 압축을 끄거나 LZF를 쓴 파일은 31.47MB였고 LZ4 파일은 5.91MB로 81.2% 줄었습니다. 작성자는 각 JSON 값 안의 반복은 적지만 레코드 사이에 필드명과 값이 반복되므로, 파일 전체를 살피는 LZ4가 압축할 패턴을 찾는다고 설명합니다. 반면 LZF는 각 문자열 값 안에서만 중복을 찾습니다.

무작위 32바이트 16진수 토큰 20만 개에서는 결과가 달랐습니다. 파일 크기는 압축 안 함과 LZF가 모두 15.49MB였고 LZ4는 14.76MB로 4.7% 줄었습니다. SAVE 시간은 각각 0.186초, 0.211초, 0.283초였습니다. 이 데이터에서는 LZ4가 LZF보다 약 35%, 압축을 끈 경우보다 약 52% 더 오래 걸렸습니다. 작성자는 이 수치가 CPU 시간이 아니라 벽시계 기준 시간이라고 댓글에서 바로잡았습니다.

복제 설정과 전체 동기화

작성자는 처음에 기본 동기화에서 복제본이 받은 바이트 수를 비교했지만 설정별 차이를 찾지 못했습니다. 로컬 SAVE에서는 압축 효과가 나타났고, 기본 전체 동기화 로그에는 압축이 표시되지 않았습니다. 이에 따라 본문에서는 RDB 파일용 rdbcompression과 복제 스트림용 repl-compression을 별도 설정으로 설명합니다. repl-compression lz4를 설정한 뒤에는 복제본이 받은 데이터가 17,627,802바이트에서 3,435,304바이트로 80.5% 감소했다고 기록했습니다.

다만 댓글에서 작성자는 릴리스 노트를 다시 확인한 뒤 설명을 일부 거둬들였습니다. 9.2.0-rc1 노트에는 repl-compression이 상시 복제용 LZ4 기능으로 기재되어 있고, 별도 항목에는 모든 접속 복제본이 지원을 알리면 rdbcompression lz4로 전체 동기화 RDB도 압축한다고 적혀 있다는 설명입니다. 작성자는 자신의 실험에서 압축이 적용되지 않은 이유가 RC의 동작 문제인지 복제본의 지원 협상 문제인지 확인하지 못했으며, rdbcompression만 설정하고 9.2 복제본 하나로 다시 시험하겠다고 했습니다.

작성자는 Valkey 8.1과 9.2.0-rc1 복제본을 함께 연결했을 때 두 차례의 BGSAVE가 각각 실행됐다고 보고합니다. 8.1 복제본에는 압축하지 않은 diskless 전송을, 9.2 복제본에는 디스크 기반 LZ4 전송을 사용했습니다. 또 INFO persistence와 INFO replication에서는 실제로 적용된 압축 알고리즘을 찾지 못했고, 복제본이 압축을 협상한 경우에만 주 서버 로그에 알고리즘이 나타났다고 적었습니다.

dev.to 반응

  • @mrsaynothing — 무작위 토큰에서 4.7% 줄어든 결과를 앞세워야 합니다. 압축 효과는 알고리즘보다 데이터의 특성에 달렸습니다. 두 설정이 나뉜 점도 가장 크게 알려야 합니다. 릴리스 노트는 rdbcompression을 언급하지만 복제 경로는 repl-compression을 설정해야 바뀌고, 하나만 설정했을 때 경고도 없습니다. 릴리스 노트가 사실을 말하면서도 전체 설명은 담지 못한 사례입니다. 매일 밤 복제본을 다시 동기화하는 환경에서 전체 동기화 바이트가 80% 줄면 실질적인 효과가 있습니다. 토큰 저장소에서 52% 더 오래 걸리면서 4.7% 줄어드는 것은 손해입니다. 둘 다 측정하고 필요한 쪽만 유지해야 합니다.
    • @alexgeorgiev17 — 토큰 표에 동의합니다. JSON 데이터보다 덜 놀랐지만 더 유용한 경고입니다. 다만 두 설정에 관한 글의 일부는 거둬들여야 합니다. 댓글을 보고 릴리스 노트를 다시 읽었는데 9.2.0-rc1 노트에는 Cluster and Replication 항목에 상시 복제용 LZ4 압축(#3853)이 있습니다. 저는 rdbcompression 항목만 읽고 놓쳤으므로 릴리스 노트에 없다는 말은 틀렸습니다. 더 애매한 점은 바로 옆 항목(#4075)에 모든 접속 복제본이 지원을 알리면 rdbcompression lz4 설정으로 전체 동기화 RDB를 압축한다고 적혀 있다는 것입니다. 제가 압축되지 않은 바이트 수와 압축 로그가 없는 상황을 본 이유가 RC가 설명대로 작동하지 않아서인지, 제 환경에서 주 서버가 복제본을 지원 대상으로 인식하지 않아서인지는 모르겠습니다. '모든 접속 복제본'이라는 조건을 보면 두 번째 가능성이 의심됩니다. rdbcompression lz4만 설정하고 9.2 복제본 하나를 붙여 다시 시험하기 전까지 두 설정이 모두 필요하다는 결론을 지지할 수 없습니다. 수치에 관한 작은 정정도 있습니다. 52%는 CPU 시간이 아니라 SAVE 벽시계 시간이며 CPU는 따로 측정하지 않았습니다. 동기화 시험을 다시 하고 글도 수정하겠습니다.

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗