클라우드 관계형 데이터베이스는 계산과 공유 저장소를 분리해 읽기 전용 노드와 용량을 독립적으로 확장합니다. 압축은 지배적인 플래시 비용을 줄여야 하지만 데이터베이스 입출력은 성격이 다릅니다. Redo 레코드는 트랜잭션 커밋 지연에 놓이고 페이지 읽기는 질의 지연에 놓이며, 백그라운드 페이지 쓰기는 더 많은 작업을 허용할 수 있습니다. 하나의 코덱과 블록 크기를 세 경로에 같이 적용하면 용량이나 시간 중 하나를 낭비합니다.
소프트웨어 압축은 알고리즘 선택과 데이터베이스 문맥을 사용할 수 있지만 호스트 CPU를 소비하고 논리 오프셋을 가변 길이 페이로드에 연결하는 인덱스가 필요합니다. 계산형 저장장치는 플래시 옆에서 압축하고 블록 인터페이스 뒤에 매핑을 숨기지만 고정 하드웨어가 데이터와 작업 변화에 적응하기 어렵습니다. PolarStore는 두 계층을 직렬로 배치한 뒤, 압축의 한계 이득보다 지연이 큰 경로에서는 기능을 제거합니다.
배포 규모도 결과의 일부입니다. Alibaba는 PolarDB 저장 서버 수천 대, 관리 데이터 100PB 이상, 1세대 계산형 저장장치 6,000개, 2세대 장치 14,400개 이상을 보고합니다. 이 논문은 코덱 설계만큼 압축 하드웨어를 운영 가능하게 만든 과정에 관한 보고입니다.
입도와 유연성을 나누는 두 압축 계층
PolarCSD는 저장장치 안에서 데이터를 압축합니다. 논리 주소 공간은 실제 플래시보다 크고 내부 변환 계층이 4KB 논리 블록을 압축된 바이트 범위에 매핑합니다. 하드웨어 오프로딩은 압축 계산과 가변 길이 배치를 데이터베이스 CPU에서 분리합니다. 장치는 최악의 논리 용량이 아니라 예상 압축률을 기준으로 물리 용량을 구성합니다.
소프트웨어 계층은 16KB 데이터베이스 페이지에서 작동합니다. 압축하기 쉬운 차가운 페이지에는 강한 코덱을, 뜨거운 페이지에는 낮은 지연 코덱을 선택할 수 있습니다. 그 결과가 다시 하드웨어 계층으로 들어가면 소프트웨어 정렬, 메타데이터, 압축하지 않은 입출력에 남은 중복을 처리합니다. 두 계층의 압축률을 독립적으로 곱할 수는 없으며 실제 종단 압축률이 구매 판단 값입니다.
가변 길이 하드웨어 데이터에는 바이트 단위 인덱스와 장애 일관성이 있는 매핑이 필요합니다. PolarCSD 1.0은 전용 내장 자원에서 플래시 변환 작업을 실행했지만 대규모에서 CPU와 메모리 경합이 발생했습니다. PolarCSD 2.0은 관리 스레드를 호스트로 옮기고 하드웨어 자원과 인터페이스를 바꿨습니다. 호스트 실행은 격리가 약해 보일 수 있으나 더 강한 프로세서와 명시적인 스케줄링이 제약된 내장 자원을 대신하면서 장치 내부 경합에 따른 느린 입출력을 제거했습니다.
압축보다 내구성이 중요한 redo 바이트
Redo 쓰기는 작고 자주 재사용되며 트랜잭션 커밋과 동기화됩니다. 소프트웨어 계층에서 압축하면 영구 용량 이득은 작지만 복제 내구성 작업을 매번 늦춥니다. 요소 제거 시험에서 하드웨어 압축 위에 Zstd 소프트웨어 압축을 추가하면 데이터셋별 압축률이 21.7%에서 50.3% 높아졌지만 하드웨어 전용보다 처리량이 19.6% 줄었습니다. 복제본 세 개의 평균 redo 지연은 59마이크로초에서 79마이크로초로 늘었습니다.
PolarStore는 redo에 두 압축 계층을 적용하지 않고 Intel Optane 성능 계층에 둡니다. 사용자 페이지는 계속 압축합니다. 이 변경으로 사용자 데이터 압축률을 사실상 유지하면서 하드웨어 전용 대비 처리량 차이를 8.9%로 줄였습니다. 일반 블록 압축기가 알 수 없는 데이터베이스별 판단입니다.
우회 구조는 목표를 명확히 합니다. 수분 동안만 남는 바이트와 수년 동안 남는 페이지에 같은 최적화 예산을 써서는 안 됩니다. 비용 모델은 절감한 물리 바이트에 체류 시간을 곱하고 해당 작업의 추가 지연으로 나눠야 합니다. Redo는 쓰기 속도가 높아도 정상 상태 점유 용량은 작을 수 있습니다.
절감 입출력과 압축 해제 시간을 비교하는 코덱 선택
Zstd는 보통 더 작은 페이지를 만들지만 LZ4보다 계산량이 많습니다. 압축형 계산 저장장치에서는 더 작은 출력이 저장장치 읽기 시간도 줄여 느린 압축 해제를 상쇄할 수 있습니다. PolarStore는 두 페이지 크기를 4KB 장치 단위로 반올림하고 압축 해제 지연을 측정한 뒤, 추가 마이크로초당 절감 바이트가 300B/µs를 넘으면 Zstd를 선택합니다. 호스트 CPU 사용률이 20%를 넘거나 페이지의 30%보다 많이 바뀌면 바로 LZ4를 고릅니다.
선택은 백그라운드 쓰기 경로에서 다시 계산합니다. 보고된 최악 조건에서는 모든 갱신이 선택을 촉발해 페이지 쓰기 지연이 늘었지만 전경 작업은 기다리지 않았습니다. Zstd만 사용한 소프트웨어 압축과 비교하면 적응형 선택이 평균 페이지 읽기 지연을 약 9마이크로초 줄였고, 데이터베이스 처리량은 압축하지 않은 P5510 기준보다 2.1% 낮은 수준까지 회복됐습니다.
빠른 페이지를 선택하며 잃은 용량은 작았습니다. 운영 데이터셋 네 개에서 Zstd만 선택할 때보다 공간이 0.7%에서 2.6% 늘었습니다. 금융, 식음료, 위키, 항공, 운송 데이터의 코덱 분포가 서로 달랐으므로 클러스터 전체가 아니라 페이지별 판단이 필요합니다.
여러 복구 읽기를 한 번으로 바꾸는 페이지 로그
읽기 전용 데이터베이스 노드는 redo를 재생해 로컬 체크포인트보다 새로운 페이지를 구성합니다. 필요한 로그 레코드가 캐시에서 밀려났다면 페이지 하나를 만들 때 저장소의 여러 위치를 읽습니다. 압축은 각 접근을 더 길게 만들어 꼬리 지연을 키울 수 있습니다. PolarStore는 페이지별 로그를 유지해 필요한 레코드를 한 번에 읽습니다.
평가는 로그 캐시 압력을 유지하기 위해 읽기 전용 노드를 읽기·쓰기 노드보다 약 1초 늦췄습니다. 읽기 스레드가 128개 미만일 때 페이지 로그는 p95 지연을 28.9%에서 39.5% 줄였습니다. 128개를 넘으면 읽기 전용 노드가 CPU 병목에 도달하고 소프트웨어 큐 지연이 지배해 입출력 수 감소가 결과를 좌우하지 못했습니다.
이 경계는 입출력 최적화가 계산 포화를 고칠 수 없음을 보여 줍니다. 운영자는 페이지 로그 적중률, 피한 분산 읽기 수, 페이지 재구성 CPU, 실행 큐 지연을 함께 측정해야 합니다. 이미 CPU 병목인 노드에서는 메타데이터만 늘고 질의가 빨라지지 않을 수 있습니다.
장치 가격 프리미엄을 포함한 운영 비용
1세대 압축 클러스터의 압축률은 2.35였습니다. PolarCSD 하드웨어 가격은 정규화한 P4510 기준의 1.45배였지만 압축 후 논리 GB당 유효 비용은 1.00이 아니라 0.62였습니다. 성능은 약 10% 낮았고 경합을 피하려고 소프트웨어 압축과 데이터베이스 최적화 두 개를 껐습니다.
2세대는 상대 장치 비용을 1.45에서 1.32로 낮추고 이중 압축 전체를 켰습니다. 운영 압축률 3.55를 달성해 논리 GB당 정규화 비용은 동시대 P5510 클러스터의 0.91과 비교해 0.37이 됐습니다. 논문은 이를 저장 비용 약 60% 절감으로 설명합니다. 480GB 데이터베이스, 저장 노드 여덟 개, 8코어·32GB 계산 인스턴스, 16스레드 클라이언트의 Sysbench에서는 2세대 압축 및 비압축 클러스터의 성능이 같았습니다.
모든 데이터셋이 3.55배로 압축된다는 뜻은 아니며, 네 데이터셋의 하드웨어 전용 압축률은 2.12에서 3.84였습니다. 테넌트별 압축률이 다르면 논리 용량도 불균형해집니다. PolarStore는 논리 사용률과 측정 압축률을 함께 보고 청크를 옮겼고, 인용된 운영 시험에서는 2.2에서 2.7의 압축률과 목표 균형 영역에 있는 노드 87.7%를 달성했습니다.
클러스터 관리 문제로 확장되는 압축 하드웨어
논리 주소 공간 과할당은 압축률을 가정합니다. 암호화하거나 이미 압축했거나 엔트로피가 높은 데이터를 저장하는 테넌트는 가정을 깨뜨릴 수 있습니다. 입장 제어는 보수적인 데이터셋별 추정으로 물리 용량을 예약해야 하며, 제어 평면은 실제 플래시가 가득 차기 전에 반응해야 합니다. 논리 여유 공간 지표만으로는 안전하지 않습니다.
인덱스와 변환 계층은 내구성에 중요한 메타데이터입니다. 전원 장애 뒤에 커밋된 논리 페이지가 정확히 하나의 압축 물리 범위를 가리킨다는 사실을 복구 과정이 증명해야 합니다. 펌웨어 갱신, 호스트 변환 서비스 재시작, 부분 복제본 장애를 결함 주입으로 시험해야 합니다. 데이터베이스의 복구 목표 안에서 매핑을 다시 만들 수 없다면 높은 압축률도 의미가 없습니다.
꼬리 동작은 코덱, 압축률 구간, 작업 종류, 장치 세대별로 관찰해야 합니다. 2세대 운영 분포에서 4밀리초를 넘는 읽기는 7.91×10^-7, 쓰기는 1.05×10^-6뿐이었고 1세대보다 크게 개선됐습니다. 수백만 IOPS에서는 이처럼 드문 사건도 계속 나타나므로 낮은 비율보다 실제 건수와 작업 영향이 중요합니다.
긴급도가 아니라 체류 시간을 압축하는 설계
PolarStore의 가장 강한 기여는 임계 경로를 구분한 점입니다. 오래 남는 페이지에는 하드웨어와 선택적 소프트웨어 압축을 적용합니다. 커밋에 중요한 redo는 우회하고, 페이지 읽기는 절감 입출력과 압축 해제 시간을 비교해 코덱을 고릅니다. 복구 꼬리 지연에는 데이터베이스 페이지 중심의 배치를 적용하며, 클러스터 배치는 테넌트별 압축률을 보정합니다.
압축률 3.55와 정규화 논리 GB 비용 0.37은 100PB 규모에서 전용 장치가 비용을 회수할 수 있음을 보여 줍니다. 1세대 결과는 오프로딩이 자동으로 격리를 보장하지 않는다는 점도 보여 줍니다. 장치 안의 제한된 계산 및 메모리 자원이 호스트 CPU에서 피할 수 있는 꼬리 지연을 만들었습니다. 구매자는 전체 압축률 분포, 장치 가격을 포함한 논리 비용, 데이터베이스 처리량, p95 및 드문 느린 입출력, 복구 시간, 압축 불가능 테넌트의 동작을 요구해야 합니다.
압축은 계층뿐 아니라 시간에 따른 배치 문제입니다. 바이트가 충분히 오래 남아 계산 비용을 회수할 수 있는 곳에 자원을 쓰고, 추가 마이크로초가 커밋을 늦추는 곳에서는 비켜 가야 합니다. PolarStore가 성능 동등성을 얻은 것은 이러한 예외를 명시한 뒤입니다.
출처와 저작권 안내
이 글은 Silicon & Systems의 편집 분석입니다. 구조, 운영 측정값, 한계를 자체 문장으로 재구성했습니다. 원문의 문장, 표, 도판을 복제하지 않았으며 본문 도판은 이 글을 위해 새로 만들었습니다. 논문은 USENIX FAST 2026 발표 페이지에서 확인할 수 있습니다. 저작권은 저자에게 있으며 연도는 2026년입니다.