ZIP 대 7Z 대 ZSTD: 실제 데이터와의 확실한 비교

ZIP, 7Z, ZSTD 중에서 어떤 압축 형식을 선택할지는 애플리케이션 배포, 일일 백업 전송, 스토리지 및 대역폭 비용 절감 ( 파일 압축 및 압축 해제 방법 참조 )과 같은 상황에서는 사소한 문제처럼 보일 수 있습니다. 실제로는 이러한 선택이 배포 시간, CPU/RAM 사용량, 심지어 타사 도구 및 시스템과의 호환성에도 영향을 미칩니다.

실제 데이터와 매우 다양한 환경( 배포용 5,4GB .NET 데이터셋 부터 1GB 위키피디아 텍스트 코퍼스 , 컨테이너 이미지, 28,7GB 바이너리 까지)을 사용한 여러 벤치마크를 검토한 결과, 압축률을 우선시해야 하는 경우, 압축 해제 속도 가 중요한 경우 , 그리고 호환성(기존 ZIP, ZSTD를 사용한 ZIP, LZMA2 또는 다른 코덱을 사용한 7Z 등)이 미치는 영향은 무엇인지 전체적인 그림을 파악할 수 있었습니다.

우리가 비교하는 것과 그것이 중요한 이유

본 연구에서는 가장 일반적으로 사용되는 압축 포맷인 ZIP(Deflate) , 7Z(LZMA/LZMA2) , ZSTD를 분석했습니다 . Brotli, XZ, bzip2, zpaq, LZ4 또한 실제 환경에서는 직접적인 비교가 어려운 경우가 많기 때문에 논의에 포함했습니다. 예를 들어, .NET 배포 환경에서는 대용량 백업이나 배포 패키지 패키징과는 달리 호환성, 처리량, 속도 간의 균형이 중요하게 고려되는 요소가 다릅니다.

상황에 따라 적합한 솔루션이 다릅니다. 배포 시간을 최소화 하고 어디에서나 지원을 받을 수 있는 솔루션을 찾는 경우와 15개의 백업 파일 저장 공간을 최소화하고 ( 압축 파일 분할 포함) 데이터 전송 비용을 최적화 하려는 경우에는 선택지가 달라집니다. 다행히 이제는 비교 가능한 수치와 명확한 패턴을 통해 정보에 기반한 결정을 내릴 수 있습니다.

각 형식의 작동 방식(그리고 실제로 의미하는 바)

• ZIP (수축) LZ77과 허프만을 결합한 제품으로, 베테랑급에 널리 쓰이며 완벽하게 호환됩니다. 최신 옵션에 비해 압축률이나 속도 면에서 우위를 점하는 것은 아니지만, 어디서나 열립니다 (어떻게 보는지 브라우저 확장 프로그램 관리) 구현 방식이 안정적이고 잘 알려져 있습니다. 기존 ZIP(방법 8)은 역사적으로 한계가 있었지만, 최신 압축 프로그램은 이러한 제약을 많이 극복했습니다.
• 7Z 그것은 주로 ~에 의존합니다 LZMA/LZMA2매우 좋은 비율과 성숙한 도구를 갖추고 있습니다. 또한, 7-Zip은 병렬 처리가 잘 되며 "합리적인 기본값» 민첩함을 느끼게 해줍니다. 사실상의 표준 데스크톱 및 개발 환경에서 광범위한 지원 제공 Windows, Linux 그리고 macOS(때로는 외부 유틸리티를 사용함).
• Z표준(ZSTD)만든 사람 : Facebook (2015)는 다음과 같은 점에서 두드러집니다. 매우 빠른 감압 매우 광범위한 레벨 팔레트(1~22)를 제공합니다. Deflate와 동등하거나 더 나은 성능을 제공하고, LZMA에 근접하는 비율을 달성하는 것이 목표이며, 일반적으로 실행 속도가 더 빠릅니다. BSD/Linux 커널에 통합된 것을 볼 수 있습니다. 패킷 압축 (예: Arch Linux는 zstd 레벨 20을 사용하여 XZ보다 14배 빠르게 압축을 풀고 크기는 +0,8%에 불과함) CI/CD 파이프라인에서 점점 더 많이 사용되고 있습니다.

알아두면 좋은 다른 배우들

• 브로 틀리웹용으로 설계된 이 압축 방식은 텍스트 콘텐츠에서 gzip보다 압축률이 뛰어나고 다음과 같은 이점을 제공합니다. 콘텐츠 인코딩 브라우저의 경우 압축 벤치마크가 단일 스레드로 되어 있어 시간 비교가 왜곡됩니다. 진짜 벽시계 멀티스레드 코덱을 사용하는 경우 병렬 구현이 있습니다. 서버 환경에서는 전력 소비가 총 CPU(사용자+시스템) 벽시계보다 더 관련성이 높습니다.
• XZ LZMA를 개선하고 비용을 절감하여 뛰어난 비율을 제공합니다. 높은 압축 시간대용량 바이너리의 경우 경쟁력이 있을 수 있지만 압축 해제 속도는 종종 ZSTD 및 7Z보다 떨어집니다. 멀티스레드 동시성 및 매개변수 -e (극단) 그것들은 기적을 일으키지는 않지만, 사진의 품질을 어느 정도 향상시킵니다.
• bzip2/pbzip2 그들은 보드의 중간에서 비율과 CPU의 균형을 맞춥니다. pbzip2 병렬성이 확보됩니다. 그러나 많은 현대 사례에서 ZSTD와 7Z가 더 나은 성능을 제공합니다. 절충점 글로벌
• 지팍 그는 "최대 비율을 갖춘 전지형 차량» 저널링 유형 증분 압축을 사용합니다. 바이트 압축에 중점을 두고 기꺼이 희생합니다. 감압 속도콜드 백업의 경우 좋은 생각일 수 있지만, 일반적인 용도로는 그렇지 않습니다.

데이터를 사용한 벤치마크: 텍스트, 대용량 바이너리 및 배포

1) 텍스트 데이터 세트(Wikipedia 1GB)

1GB의 위키피디아 텍스트를 대상으로 ZIP(7zip 사용), 7zip, XZ, Brotli, Zstandard, zpaq 압축 방식을 비교하고 각 방식별 시간 대비 용량 그래프를 작성했습니다 . 저자는 이 테스트가 비과학적인 방식이며, Brotli의 단일 스레드 참조 방식이 실제 사용 환경에서의 시간 성능을 반영하지 못한다고 지적합니다. 사용자 및 시스템 부하가 있는 컴퓨팅 환경에서는 Brotli의 성능이 향상되며, ZSTD는 매우 경쟁력 있는 성능을 보여주며, 부하가 심한 상황에서도 XZ/7zip과 유사한 압축률과 빠른 압축 해제 속도를 달성합니다.

주요 결과: ZIP은 압축률과 시간 면에서 뒤처집니다 . 7zip은 더욱 정교한 도구와 멀티스레딩을 통해 발전했습니다. XZ는 압축률은 향상되었지만 압축 해제 속도는 ZSTD보다 느립니다 . ZSTD는 압축 작업량을 늘릴수록 성능 균형이 매우 뛰어납니다. zpaq는 특히 압축 해제에 상당한 시간이 소요되지만 최고의 압축률을 달성합니다.

2) PeaZip "최대 압축" 테스트(Windows, i7-8565U)

PeaZip/WinRAR을 사용하여 입력 파일 크기를 303,0MB로 설정하고 테스트당 5회 반복했을 때의 평균값은 다음과 같습니다 (크기: MB, 시간: 초).

체재	타마	비율	압축	추출
RAR 최고(WinRar)	78,1	25,78%	28,5	1,8
7Z 울트라(LZMA2)	71,2	23,50%	137,0	3,4
7Z 울트라 브로틀리	75,1	24,79%	208,0	0,8
7Z 울트라 Zstd	75,3	24,85%	300,0	1,2
7Z 울트라 BZip2	80,6	26,60%	81,0	7,1
ZPAQ 울트라	57,6	19,01%	359,0	358,0

결론: ZPAQ는 순수 압축률 면에서는 우수하지만 압축 해제 시에도 매우 느립니다. 7Z(LZMA2)는 적절한 압축률과 압축 해제 속도를 제공합니다. 7Z 내에서 Brotli/ZSTD를 사용하면 압축 해제 속도가 매우 빨라지지만 (Brotli를 사용하면 더욱 빠름), LZMA2의 최고 설정보다 압축 시간이 더 오래 걸립니다. RAR은 압축률을 다소 희생하면서 압축 속도를 우선시하며, 보안이 필요한 경우 압축 파일에 암호를 설정하는 방법을 알아볼 수 있습니다.

3) 28,7GB의 거대한 바이너리(Linux, Ryzen 5 5600G)

28,65~28,7GB 크기의 파일을 최대한 압축하고 xz, pbzip2, 7z, zstd 등 의 압축 프로그램을 사용하여 압축률과 시간을 비교하는 것이 목표였습니다.

• xz -9e -T12: ~15m49s에 12,6GiB(≈ 44,0%)
• pbzip2 -9: ~4m29s에 13,07GiB(≈ 44,55%)
• 7z -mx=9: ~16m43s에 12,9GiB(≈ 43,98%)
• zstd –울트라 -22 -T12: ~19m48s에 12,48GiB(≈ 43,57%)

"최대 압축"에서 ZSTD는 크기 면에서는 근소한 차이로 앞섰지만 , 압축 시간이 더 오래 걸렸습니다. pbzip2는 예상외로 빠른 속도를 보여주며 비슷한 비율을 달성했습니다. 이 사례는 매우 큰 바이너리 파일의 경우, GB 단위의 절대적인 차이가 분 단위의 CPU 사용 시간 차이만큼이나 중요하며, 두 가지 모두를 정량화하는 것이 중요하다는 것을 보여줍니다.

4) 게임 ZIP(EU4) 및 ZSTD를 사용하여 tar+brotli에서 ZIP으로 변환

실제 사례: EU4 저장 파일은 압축률이 낮은 ZIP 파일로 제공됩니다. 압축 해제 후 재압축을 테스트한 결과, 재 압축 시 약 17%의 용량 절감 효과가 있었습니다. ZIP 파일 내의 코덱을 변경한 결과, 레벨별로 다음과 같은 용량 개선 효과가 나타났습니다.

방법	절감	시간(ms)
zstd(3)	40%	463
zstd(5)	45%	755
zstd(7)	50%	1256
브로틀리(4)	32%	1481
브로틀리(9)	54%	4210

또한, Wasm 트랜스코딩 페이로드 크기는 ZSTD가 약 215kB(인코더만 사용할 경우 136kB), Brotli가 약 683kB 입니다. 파싱 과정에서 캐시에서 가져오는 시간(브라우저의 Brotli 콘텐츠 인코딩은 비용이 발생함) 을 고려하면 ZSTD와 Brotli는 매우 유사한 성능을 보였습니다. Brotli는 사용자 공간으로 압축 해제를 하지 않기 때문에 파싱 속도가 약간 더 빠릅니다. ZSTD는 콘텐츠 인코딩을 건드리지 않고 디스크에서 더 효율적으로 읽어들이는 장점이 있습니다.

업로드 속도가 30Mb/s일 때, 일반적인 7,7MB ZIP 파일에 트랜스코딩과 전송을 통합하면 다음 과 같은 결과가 나타납니다. 원본 2,05초, ZSTD-3 1,70초, ZSTD-5 1,88초, ZSTD-7 2,28초. 실제 사용 환경에서는 스토리지 비용 절감(버킷 사용료 지불 시)을 위해 ZSTD 레벨 7을 권장하지만 , 지연 시간이 최우선이라면 레벨 3도 매력적인 선택입니다.

5) .NET 배포(5,4GB 게시)

5,4GB에 달하는 출력 파일(자체 포함 파일과 프레임워크 종속 파일 혼합)을 가진 .NET 애플리케이션을 배포하는 경우, 실용적인 지침은 명확합니다. 목표에 따라 적절한 압축 방식을 선택하십시오 . 범용 호환성을 목표로 한다면 기존 ZIP 압축 방식을 사용하는 것이 좋고 , 압축 해제 속도가 병목 현상의 원인이라면 ZSTD가 강력한 선택지입니다. 안정적인 CLI 및 도구를 활용하여 높은 처리량을 원한다면 LZMA2 코덱을 사용하는 7Z가 여전히 최적의 선택입니다.

감압: 경험에서 가장 눈에 띄는 요소

여러 독립적인 테스트 결과, ZSTD는 압축 해제에 있어 독보적인 성능을 보여줍니다. 텍스트 벤치마크에서 user+sys 부분을 살펴보면 ZSTD가 파일 시스템 압축( 자동 압축 비활성화 방법 참조 ) 및 패키지 래핑에 최적화된 이유가 명확해집니다. 읽기 속도가 빠르고 CPU 사용량이 낮기 때문입니다. 7-Zip은 매우 훌륭한 사용자 경험을 제공하며, XZ와의 차이는 코덱 자체의 성능 차이보다는 유틸리티와 멀티스레딩 덕분이라고 할 수 있습니다.

ZIP은 사용자 및 시스템 압축 해제 성능 지표에서 예상보다 뛰어난 결과를 보여주며 모두를 놀라게 했습니다. 대상 고객이 사양이 낮은 컴퓨터를 사용 하거나 빠른 압축 해제가 매우 중요한 워크플로우를 사용하는 경우, 테스트 없이 ZIP을 고려해볼 만합니다. 반면 ZPAQ는 놀라운 효율성을 자랑하지만 압축 해제 시간이 매우 오래 걸린다 는 한계를 보여주며 , 초기 백업(콜드 백업)에 적합합니다.

사용 사례: 데이터(RAM, 시간, 비율, 비용)를 사용하여 결정하는 방법

매일 30~100개의 컨테이너를 백업 해야 하는 컨테이너 플랫폼 환경에서는 운영 예산이 매우 중요합니다. 이에 실용적인 점수 시스템이 제안되었습니다.

• 램: 5점을 받으려면 200MB 압축, 100MB 압축 해제를 목표로 합니다. 50MB 이상일 경우 1점을 뺍니다.
• 시간: 모든 것을 압축하는 데 매일 3시간이 걸립니다. 컨테이너당 6~1,8분. 120초 초과 시 0점, -20초마다 1점이 추가됩니다. <10초는 5점입니다 감압 중.
• 비율: ~1,6GB 객체(예: MariaDB+PHP+WordPress)와 Backblaze/E2 유형 백엔드에서 ~$6/TB 스토리지를 사용하는 경우, ≥4:1을 목표로 하면 결과를 낮추는 데 도움이 됩니다. 탈출 비용 (AWS의 경우 발신 요금이 GB당 $0,09이므로 주의하세요).

테스트 결과, ZSTD 레벨 3은 207MB RAM에서 약 3초 만에 약 3,5:1의 비율을 달성했고, Brotli 레벨 6은 적절한 RAM 프로파일에서 약 30초 만에 약 4,3:1의 비율을 달성했습니다. ZSTD의 튜닝 (전략, 검색 로그, 목표 길이, 최소 일치)을 조정해도 시간이나 메모리 사용량 증가 없이 성능을 충분히 향상시킬 수 없었으며, 이 특정 분석에서는 Brotli 레벨 6이 가장 우수한 것으로 나타났습니다. 흥미롭게도 Brotli 레벨 4는 레벨 3 및 5보다 더 많은 메모리를 사용했지만, 레벨 5와 동일한 비율을 절반의 시간 내에 달성했습니다. 추가 13MB의 저장 공간이 허용된다면 매우 매력적인 옵션입니다.

목표가 바뀌면(예: 빠른 배포 또는 집중적인 읽기) 가중치가 달라지는데, ZSTD는 매우 빠른 압축 해제 속도 와 중간 수준에서의 적절한 비율 덕분에 가장 균형 잡힌 선택이 되는 경향이 있습니다 .

호환성, 지원 및 ZSTD와 ZIP의 역할

핵심은 ZIP 표준이 6.3.8(2020) 규격부터 ZSTD(방법 93)를 통합했다는 점입니다. 이를 통해 최신 코덱을 사용하는 " 기존 방식의 ZIP 압축 "이 가능해졌습니다. 그렇다면 생태계는 이를 얼마나 잘 지원하고 있을까요? 현재 Windows Explorer는 ZSTD를 사용하여 ZIP 파일을 생성하거나 압축을 풀지 않습니다. 주류 소프트웨어인 7-Zip은 ZSTD를 통합하는 중이며, 이미 작동하는 포크 ​​버전도 존재합니다. Linux에서는 p7zip의 포크 버전이 있습니다. 상황은 개선되고 있지만 여전히 몇 가지 문제점이 남아 있습니다.

사용하는 경우 총 사령관, ZSTD를 교체하여 7z 판독을 활성화할 수 있습니다. TCLZMA64.DLL 호환 버전(예: 7-Zip ZS의 TotalCmd.7z 패키지)을 사용합니다. TC 내에서 ZSTD로 7z 파일을 생성하려는 경우, 이전 플러그인은 선택한 코덱을 항상 준수하지 않고 LZMA로 대체합니다. 따라서 다음 방법을 사용하는 것이 좋습니다. 7-Zip ZS 완료 또는 코덱 플러그인 기존 7-Zip 설치에서. 7-Zip ZS를 사용하면 압축/다운로드가 가능합니다. 브로틀리, LZ4, 리자드, ZSTD 7z 컨테이너 내부 및 취급 우편번호+ZSTD. 확인 7z i 어떤 코덱이 활성화되어 있나요?

웹 브라우저와 파이프라인에서 Brotli의 콘텐츠 인코딩은 "완전히 무료" 솔루션처럼 보이지만, 몇 가지 미묘한 차이가 있습니다. 미들웨어, 프록시, 프레임워크(예: Next.js의 디버그/프로덕션 모드 간의 차이)는 압축을 다시 수행 하거나 지연 시간을 추가할 수 있습니다. 사전 압축된 파일을 제공하는 것 또한 항상 간단한 것은 아닙니다(Cloudflare Pages는 기본적으로 지원하지 않습니다). 여러 실제 사례에서 스트림을 ZIP 형식의 ZSTD 로 대체하고 사용자 공간에서 압축을 해제하는 방식이 환경 종속성을 줄이면서도 동등하거나 더 나은 결과를 보여주었습니다 .

유용한 매개변수 및 권장 수준

ZSTD 에서 레벨 3, 5, 7은 최적의 작동 지점을 제공합니다. 30Mb/s의 속도로 트랜스코딩과 전송을 비교한 연구에 따르면 레벨 3이 엔드투엔드에서 가장 빠른 속도를 보였지만, 레벨 7은 스토리지 사용량을 절감하는 효과를 나타냈습니다(EU4 환경에서 레벨 5보다 12,5%, 레벨 3보다 25% 절감). AWS Athena 문서에서는 레벨 3이 기본적으로 사용되지 않을 경우 레벨 6~9를 선호한다고 명시하고 있는데 , 이는 본 연구 결과와 일치합니다.

장거리 매칭을 활성화하고 싶은 유혹은 크지만, 주의해야 할 점이 있습니다. 이를 위해서는 압축 해제 프로그램이 압축 프로그램과 동일한 메모리 용량을 가져야 합니다 . 실제 배포 환경이나 클라이언트 앱 에서는 이러한 요구 사항을 충족하는 것이 비현실적일 수 있습니다. 윈도우와 테이블의 메모리 용량을 적절한 수준으로 유지하는 것이 좋습니다 .

Brotli 에서 핵심적인 조정 사항은 일반적으로 레벨 입니다 . 이미 높은 레벨에 도달한 경우 lgwin을 변경하면 메모리 용량이 증가하지만 성능 향상은 미미할 수 있습니다. 레벨 4 가 레벨 5와 동일한 비율을 절반의 시간 안에 달성한다는 점(약간의 RAM 증가만 필요함)은 메모리 크기를 크게 늘리지 않고 지연 시간을 줄이려는 경우에 매우 유용합니다.

XZ 의 경우 , -e 플래그는 프리셋의 느린 변형을 적용하여 약간 더 높은 압축률을 목표로 합니다. 매뉴얼 표를 보면 압축기의 메모리 사용량은 증가하지만 압축 해제기 의 메모리 사용량은 동일하게 유지된다는 것을 알 수 있습니다. 그럼에도 불구하고 ZSTD와 비교했을 때, XZ는 고속으로 패킷을 해제해야 하는 경우 압축 해제 성능이 떨어지는 경우가 많습니다 .

기존 ZIP 방식을 사용하면서도 Deflate의 최대 속도를 원한다면, libdeflate 와 같은 라이브러리를 사용 하면 zlib에 비해 처리량이 크게 향상됩니다. Rust 생태계에서 zip-rs는 아직 ZIP 생성 시 백엔드 전환을 지원하지 않으므로, 추가 작업 없이는 이 방법을 사용할 수 없을 수도 있습니다.