PostgreSQL의 데이터베이스 크기 감소 전략: 사용량 기반 접근 방식

데이터베이스 가격 모델은 어렵습니다. 관리형 데이터베이스를 찾고 있는 개발자로서 검색 프로세스에서 가장 짜증나지만 중요한 측면 중 하나는 데이터베이스 크기에 대한 솔루션의 초기 가격뿐만 아니라 가격 책정 방식과 확장성도 평가하는 것입니다. . 데이터베이스 가격을 평가할 때 미묘한 차이(예: "데이터가 증가함에 따라 청구 금액이 얼마나 증가합니까?", "쓰기 또는 읽기당 비용이 청구됩니까?", "백업당 더 많은 비용을 지불해야 합니까?") ), 개발자는 한 가지 측면을 간과하는 경향이 있습니다. 즉, 데이터베이스의 가격 책정 모델이 구성되는 방식은 데이터를 관리하고 Postgres 데이터베이스 크기를 평가하는 방법에 영향을 미칩니다. 가격 모델에 따라 PostgreSQL 실행에 대한 접근 방식도 달라집니다. 예를 들어 대용량 디스크에 묶여 있는 경우 데이터베이스 크기를 줄이는 것이 우선순위가 아닐 수 있습니다. 데이터 읽기당 요금이 부과되는 경우 특정 쿼리 실행에 대해 다시 생각해 볼 수 있으며, 데이터 수신당 요금이 부과되는 경우 새로 수집되는 데이터의 빈도와 양에 주의할 수 있습니다. 각 가격 책정 요소는 결국 채택하게 될 전략과 행동에 미묘하게 영향을 미치며, 비용 효율성과 최적의 성능을 모두 보장하기 위해 데이터베이스를 관리하고 상호 작용하는 특정 방식을 지향하게 됩니다. , 훌륭한 고객 피드백을 받았습니다. 이 블로그 게시물에서는 사용량 기반 모델에서 PostgreSQL 스토리지를 최적으로 관리하는 방법에 대한 전술과 함께 이 모델로 전환한 이후 고객이 관찰한 운영상의 이점을 살펴보겠습니다. Timescale에서는 몇 달 전에 사용량 기반 스토리지 모델로 전환했습니다. 사용량 기반 스토리지 모델은 데이터베이스 세계에서 점점 인기를 얻고 있습니다. 누가 사용하지 않는 디스크 공간에 대해 비용을 지불하고 싶겠습니까? 하지만 사용량 기반 모델에는 결과가 따르기 때문에 이를 효과적으로 탐색하려면 몇 가지 모범 사례를 고려해야 합니다. PostgreSQL 스토리지 모델에 대한 빠른 요약 사용량 기반 모델에서 데이터베이스 크기를 관리하는 방법에 대한 논의의 공통 기반을 마련하기 위해 PostgreSQL 플랫폼에서 가격이 책정되는 방식을 빠르게 살펴보겠습니다( ) 및 Amazon RDS for PostgreSQL 및 Amazon Aurora와 같은 다른 관리형 PostgreSQL 제품과 비교하는 방법입니다. 기간 어제(🔥)부터 Timescale 플랫폼에서 두 가지 유형의 데이터베이스 서비스를 제공합니다. , 개발자는 동적 컴퓨팅을 통해 PostgreSQL 데이터베이스를 생성하여 성능 저하 없이 비용을 절감할 수 있습니다. 동적 PostgreSQL 서비스 개발자가 하이퍼테이블, 열 형식 압축, , 계층형 스토리지를 제공합니다. 연속 집계 플랫폼에서 스토리지 가격을 책정하는 방법에 중점을 두겠습니다. 이 두 서비스 모두 사용량 기반 스토리지 모델과 함께 제공됩니다. 이는 다음을 의미합니다. 개발자는 최소 데이터베이스 크기나 최소 확장 단계 없이 소규모 인쇄 없이 사용하는 볼륨에 대해 비용을 청구합니다. 월말까지 128GB를 사용한 경우 해당 금액에 대한 요금이 청구됩니다. 1GB부터 시작하여 TB까지 늘릴 수 있습니다. 작성된 데이터, 데이터 전송 또는 쿼리 실행을 기준으로 요금이 부과되지 않습니다. 데이터베이스를 생성하거나 확장할 때 스토리지를 할당할 필요가 없습니다. 수동으로 디스크 크기를 줄일 필요가 없습니다. 이를 이해하기 위해 이 모델, Amazon RDS PostgreSQL 및 Amazon Aurora 간의 차이점을 살펴보겠습니다. 요약하자면, 비교에서 세 가지 주요 내용은 다음과 같습니다. Timescale과 Aurora는 모두 실제 데이터베이스 크기에 따라 요금을 청구합니다. 이와 대조적으로 RDS PostgreSQL은 프로비저닝된 스토리지에 대해 요금을 청구합니다. RDS에서는 볼륨 크기를 줄일 수 없습니다. Timescale은 작성된 데이터, 데이터 전송 또는 쿼리 작업에 대해 비용을 청구하지 않습니다. RDS와 Aurora는 모두 데이터 전송당 추가 백업 스토리지 요금을 부과하며, 선택한 스토리지 유형에 따라 추가 I/O 요금이 발생할 수 있습니다. Timescale에는 최소 조정 단계가 없지만 Aurora는 10GB로 시작한 후 10GB 단위로 확장됩니다. 보시다시피 Timescale의 모델은 , Timescale에는 데이터 전송과 같은 작업에 대한 확장 단계와 추가 비용이 없다는 차이점이 있습니다. 대조적으로, RDS는 할당 기반 모델을 잘 표현합니다. 전통적으로 이 모델을 운영하는 데이터베이스 공급업체에서 발견되었습니다. Aurora I/O 최적화 RDS에는 "스토리지 계층"이 없습니다. 사용량 기반 가격이 PostgreSQL 스토리지 관리를 개선하는 방법 이전에 소개한 것처럼 다양한 가격 책정 모델은 다양한 데이터베이스 경험을 의미합니다. 할당 기반 모델에서 사용량 기반 모델로 전환했을 때 고객은 세 가지 운영 영역에서 즉각적인 개선을 보았다고 말했습니다. 데이터베이스를 시작할 때 스토리지를 미리 프로비저닝할 필요가 없었기 때문에 과잉 프로비저닝 실수가 줄어들고 스토리지 비용도 절감되었습니다. 확장하는 동안 스토리지에 대해 생각할 필요가 없었습니다. 규모를 축소할 수 있습니다. 예를 들어 데이터를 삭제하면 이에 대한 비용 지불이 중단됩니다. 사용량 기반 모델은 스토리지 과잉 프로비저닝 문제를 제거합니다. 기존 할당 기반 모델에서는 개발자가 스토리지 요구 사항을 예측하는 경우가 많으며, 이는 스토리지 과잉 프로비저닝으로 이어지는 경우가 많습니다. Timescale이 사용량 기반 모델을 운영했을 때 전체 제품에서 이러한 현상이 관찰되었습니다. 대부분의 고객은 전체 디스크 용량을 사용하지 않았습니다. 이는 본질적으로 아직 사용하지 않은 스토리지 공간에 대해 비용을 지불하고 있음을 의미합니다. 사용량 기반 모델은 이러한 추측 게임과 잘못된 추측의 결과를 제거합니다. 확장하는 동안 스토리지에 대해 생각할 필요가 없습니다. “Timescale의 사용량 기반 스토리지는 더 이상 디스크 크기에 대해 생각할 필요가 없다는 것을 의미합니다. 스토리지 비용이 30% 감소했고 아무것도 할 필요가 없었습니다!" 아담 맥크레아, (기간 고객) 유도급 사용량 기반 모델에서는 데이터베이스가 증가함에 따라 스토리지가 원활하게 확장됩니다. 기존 할당 기반 모델의 주요 스트레스 원인은 디스크 공간이 부족할 위험이 있으며, 이로 인해 애플리케이션 가동 중지 시간과 트랜잭션 손실, 최악의 시나리오에서 데이터 손상에 이르기까지 수많은 문제가 발생할 수 있습니다. 사용량 기반 모델을 사용하면 개발자는 더 이상 스토리지 벽에 부딪히지 않도록 스토리지를 주의 깊게 모니터링할 필요가 없습니다. 동시에 과도한 자동 확장 단계나 계층 점프에 대해 걱정할 필요가 없습니다. 축소할 수 있습니다(삭제한 데이터에 대한 비용 지불 중지). 마지막으로 사용량 기반 모델을 사용하면 "규모 축소"가 가능합니다. 데이터를 삭제하면(또는 데이터베이스 크기를 상당히 줄일 수 있다면) 스토리지당 비용이 줄어들기 시작하는데, 이는 공평하게 들립니다. 다음 섹션에서 살펴보겠지만 Timescale에는 고객이 PostgreSQL 데이터베이스 크기를 줄이는 데 도움이 되는 몇 가지 기능이 있습니다. 사용량 기반 모델을 채택함으로써 고객은 디스크 사용량을 줄임으로써 비용 절감을 즉시 실현할 수 있었고, 이는 데이터베이스를 간결하게 유지할 수 있는 동기를 부여했습니다. 사용량 기반 모델을 효과적으로 탐색하는 방법: Postgres 데이터베이스 크기를 줄이는 팁 방금 언급한 이점은 스토리지 작업에 대한 개발자 경험을 크게 향상시키며, 이것이 바로 사용량 기반 모델이 인기를 얻고 있는 이유입니다. 그러나 사용량 기반 가격 책정에는 분명하면서도 심오한 결과가 따릅니다. 개발자는 PostgreSQL 데이터베이스 크기를 최대한 줄이기 위해 좋은 데이터 관행을 채택해야 합니다. 스토리지 비용이 실제로 사용 중인 디스크 크기와 직접적으로 연관되어 있다는 사실을 알게 되면 데이터 스토리지에 대해 더욱 신중해야 하는 새로운 인센티브가 있습니다. 사용량 기반 스토리지 모델을 운영하는 경우 데이터를 효율적으로 저장하는 것은 귀하의 책임입니다. 어떤 면에서 이는 사용량 기반 모델의 "단점"으로 간주될 수 있으며 약간의 작업이 필요하지만 실제로는 이것이 축복입니다. 기존 할당 기반 모델에서는 비용이 고정되어 있기 때문에 데이터 위생이 다소 간과될 수 있습니다. RDS에서 500GB 디스크에 잠겨 있고 데이터베이스가 200GB인 경우에는 큰 인센티브가 없는 것 같습니다. 스토리지 활용을 효율적으로 만듭니다. 하지만 중요한 점은 좋은 데이터 관행은 단지 비용 절감에 관한 것이 아니라는 것입니다. PostgreSQL 데이터베이스를 확장하려면 최적화된 상태를 유지하는 것이 필수적입니다. 좋은 PostgreSQL 데이터 관리 방식을 채택하면 성능이 향상될 뿐만 아니라 데이터베이스 관리자로서의 삶도 훨씬 쉬워질 것입니다. 이를 염두에 두고 스토리지에 대한 사용량 기반 모델을 최대한 효과적으로 탐색하여 PostgreSQL 데이터베이스 크기를 체계적인 방식으로 줄이는 데 도움이 되는 몇 가지 사례를 실행해 보겠습니다. Timescale의 특별한 경우에는 특별히 유용한 기능이 몇 가지 있는데, 이 기능도 다룰 것입니다. PostgreSQL 데이터베이스의 팽창을 줄입니다. 사용량 기반 모델에서 가장 먼저 해야 할 일은 PostgreSQL 스토리지 작동 방식의 세부 사항에 주의를 기울이는 것입니다. 즉, 정기적으로 팽창을 줄여야 합니다. 이는 데이터베이스 크기뿐만 아니라 I/O 요구 사항에도 도움이 됩니다. 이 섹션에서는 몇 가지 기본 사항을 알려드리겠습니다. , 그리고 우리는 또한 썼습니다 . 하지만 이 HN 스레드에는 몇 가지 훌륭한 조언이 있습니다. PostgreSQL의 테이블 팽창에 대한 블로그 게시물 PostgreSQL 스토리지 최적화를 위한 사전 예방적 접근 방식은 데드 튜플을 면밀히 관찰하는 것부터 시작됩니다. 데드 튜플을 선택하지 않은 채로 두면 누적되어 불필요한 스토리지 오버헤드가 발생할 수 있습니다. 확장은 테이블이 이러한 튜플을 관리하는 방법을 이해하는 데 큰 도움이 될 수 있습니다. 데드 튜플을 모니터링합니다. pgstattuple() 테이블 팽창을 효과적으로 방지하기 위해 autovacuum이 더 자주 실행되도록 구성할 수 있습니다. postgresql.conf에서 autovacuum 설정을 전체적으로 조정하는 것보다 테이블별로 이러한 설정을 미세 조정하는 것이 더 정확합니다. 이는 서로 다른 테이블이 데드 튜플을 축적하는 경향이 다양할 수 있다는 사실을 반영합니다. Autovacuum 작업을 방해할 수 있는 장기 실행 트랜잭션을 모니터링하는 것도 중요합니다. 진공청소기를 자주 청소하세요. autovacuum 및 Vacuum 주소 데드 튜플이 있는 반면, 사용되지 않은 페이지를 회수하려면 다른 접근 방식이 필요합니다. VACUUM FULL을 이러한 목적으로 활용할 수 있지만 전체 테이블을 잠그는 본질적인 한계가 있습니다. 이것에 대해 당신을 도울 수 있습니다. 사용하지 않은 페이지를 회수합니다. Pg_repack PostgreSQL 미세 조정 수행 PostgreSQL 데이터베이스 크기를 체계적으로 줄이는 것은 PostgreSQL 데이터베이스를 효과적으로 확장할 수 있는 것과 밀접한 관련이 있습니다. 즉, 점점 더 많은 데이터를 추가하는 동안 빠르고 민첩한 상태를 유지하는 것입니다. 일부 주요 PostgreSQL 매개변수를 주시하고 조정하는 것이 도움이 될 수 있습니다. . 고려해야 할 몇 가지 측면은 다음과 같습니다. 이 기사에서는 가장 중요한 성능 매개변수를 검토합니다. : PostgreSQL의 페이지 캐시에 사용되는 메모리를 제어하며 일반적으로 시스템 전체 RAM의 25%로 설정됩니다. shared_buffers : 쿼리 내 작업당 할당되는 메모리를 설정합니다. Timescale에서 권장 설정은 입니다. work_mem (25 % of RAM) / max_connections : 데이터베이스에 허용되는 최대 동시 연결 수를 설정합니다. 연결 풀러는 많은 단기 연결을 관리하는 데 도움이 될 수 있습니다. max_connections : PostgreSQL이 시작할 수 있는 최대 작업자 프로세스 수를 결정합니다. Timescale을 사용하는 경우 이 매개변수를 설정하는 공식은 입니다. max_worker_processes max_worker_processes = 3 + timescaledb.max_background_workers + max_parallel_workers : 병렬 쿼리를 지원하는 최대 작업자 수를 지정합니다. 기본값은 사용 가능한 CPU 수와 동일하게 설정하는 것입니다. max_parallel_workers : 동시 autovacuum 프로세스의 최대 수를 결정합니다. Timescale에서는 기본적으로 10으로 설정되어 있습니다. autovacuum_max_workers 인덱싱 위생 실천 인덱스를 정기적으로 최적화하면 특히 데이터베이스 규모가 확장될 때 PostgreSQL의 효율성을 유지하는 데 도움이 됩니다. 인덱스를 현명하게 사용하면 쿼리 성능을 향상시키는 데 도움이 될 수 있지만, 인덱스가 너무 많으면 대규모 PostgreSQL 배포에서 문제가 발생할 수 있습니다. 과도한 인덱싱의 가장 분명한 결과는 스토리지 소비 증가입니다. 모든 인덱스에는 별도의 스토리지가 필요하고 이는 테이블 크기에 비례하여 증가하기 때문입니다. 이 오버헤드는 Timescale의 하이퍼테이블처럼 테이블이 분할될 때 더욱 중요해질 수 있습니다. 불필요한 인덱스는 쓰기 작업을 개선하는 데 역효과를 낳을 수도 있습니다. 각각의 새로운 데이터 입력이나 수정은 동시 인덱스 업데이트를 암시하여 더 많은 I/O 작업과 잠재적인 테이블 팽창을 초래하기 때문입니다. 인덱스를 모니터링하면 더 이상 사용되지 않는 인덱스를 식별하고 간결하게 유지하는 데 도움이 됩니다. 이를 수행하는 한 가지 방법은 사용하는 것입니다. pg_stat_user_indexes -- Retrieve indexes that might not be used or are infrequently used SELECT schemaname, relname AS table_name, indexrelname AS index_name, idx_scan AS times_used FROM pg_stat_user_indexes WHERE idx_scan = 0 OR idx_scan < some_low_threshold -- replace 'some_low_threshold' with a value that makes sense for your context ORDER BY idx_scan ASC, schemaname, relname; idx_scan 열의 인덱스 값이 0이면 통계가 마지막으로 재설정된 이후 사용되지 않았음을 의미하며 이는 최적화 후보가 될 수 있음을 의미합니다. 에 대한 낮은 임계값을 설정하면 자주 사용되지 않는 인덱스도 식별할 수 있습니다. idx_scan 시간 척도 압축을 통해 대규모 테이블 축소 Timescale의 뛰어난 기능 중 하나는 쿼리 성능을 저하시키지 않으면서 대규모 테이블에서 사용하는 디스크 공간을 대폭 줄일 수 있는 열 형식 압축에 대한 기본 지원입니다. 압축은 많은 쿼리의 성능을 향상시킵니다. Timescale의 압축은 일반 행 기반 데이터를 보다 간결한 열 형식으로 변환하여 작동합니다. 이 프로세스는 많은 열에 반복 값이 포함될 수 있는 시계열 데이터에 특히 효과적입니다. 각 데이터 유형에 따라 서로 다른 압축 알고리즘을 적용하여 인상적인 압축률(+90%)을 달성할 수 있습니다. 이는 대규모 테이블을 최대 10배까지 축소할 수 있음을 의미합니다. Timescale에서는 시간 기반 압축 정책을 통해 테이블 단위로 압축이 활성화됩니다. 예를 들어 다음 코드는 특정 하이퍼테이블에서 압축을 활성화하고 2주가 지난 데이터를 자동으로 압축합니다. -- Enable compression on the hypertable ALTER TABLE your_hypertable SET ( timescaledb.compress, timescaledb.compress_segmentby = 'some_column' ); -- Set a compression policy to compress data older than two weeks SELECT add_compression_policy('your_hypertable', INTERVAL '2 weeks'); 압축에 대해 자세히 알아보려면 . 우리 문서를 확인해 보세요 데이터 관리 전략 수립: 오래된 데이터를 저렴한 스토리지로 옮기고, 더 이상 필요하지 않은 데이터는 삭제하세요. 이전 전술은 데이터베이스 크기를 줄이는 데 매우 유용하지만 Timescale에서 스토리지를 효과적으로 확장하기 위해 활용할 수 있는 또 다른 방법이 있습니다. 바로 계층형 스토리지입니다. 간단한 계층화 정책을 생성하면 오래되고 액세스 빈도가 낮은 데이터를 바닥이 없는 개체 스토리지 계층으로 이동할 수 있습니다. -- This policy moves all data older than one month to object storage SELECT add_tiering_policy('example', INTERVAL '1 month); 이 객체 저장소에는 다음과 같은 특징이 있습니다. 당사의 고성능 스토리지보다 가격이 저렴하므로 훨씬 적은 비용으로 많은 TB의 데이터를 저장할 수 있습니다. 이는 무한하므로 원하는 만큼 많은 데이터를 저장할 수 있습니다. 이 계층형 스토리지 아키텍처는 Timescale의 백엔드에 뿌리내려 있습니다. 객체 스토리지는 데이터베이스에서 분리된 "버킷"이 아니라 데이터베이스의 필수적인 부분입니다. 쿼리는 별도의 조치 없이 두 스토리지 계층에 투명하게 액세스합니다. 동일한 스키마에 대해 표준 SQL을 계속 사용할 수 있습니다. 계층화 정책이 설정되면 더 이상 고려할 것이 없습니다! 성능 비용이 발생하기 때문에(객체 저장소는 일반 저장소만큼 빠르지 않음) 애플리케이션에서 자주 액세스하지 않는 경우 데이터를 저렴한 저장소 계층으로 이동하는 것이 좋습니다. 그러나 이 데이터에 대해 임시 쿼리를 편안하게 계속 실행할 수 있습니다(예: 고객의 사용자 경험에 중요하지 않고 최고의 성능이 필수적이지 않은 쿼리). 편집자 주: 계층형 스토리지에 대한 흥미로운 소식을 곧 공유하겠습니다. 🎉 계속 지켜봐주세요! 저렴한 스토리지 계층을 제공하는 것 외에도 Timescale을 사용하면 더 이상 필요하지 않은 데이터를 삭제하기 위한 데이터 보존 정책을 쉽게 설정할 수 있습니다. -- Set a data retention policy to drop data older than 10 months SELECT add_retention_policy('your_hypertable', INTERVAL '10 months'); 위와 같은 데이터 보존 정책을 연속 집계와 결합하여 데이터 세트를 효과적으로 다운샘플링할 수 있습니다. 예를 들어 세분성을 1초에서 1분으로 줄이고, 1초 값을 삭제하지만 1분 집계를 유지합니다. . 이 블로그 게시물을 읽고 이를 수행하고 장기 데이터를 사전에 관리하는 방법에 대한 예를 확인하세요. 사용량 기반 모델과 데이터 관리 패러다임 사용량 기반 모델은 표면적으로는 가격 변화에 지나지 않는 것처럼 보일 수 있지만 개발자가 데이터베이스 크기에 대해 생각하는 방식과 데이터를 인식하고 처리하는 방식에 패러다임 변화를 가져옵니다. 사용량 기반 모델은 단순한 스토리지 관리에서 데이터베이스 상태 및 효율성으로 초점이 이동하는 지속적인 개선 문화를 촉진합니다. 처음에는 어느 정도 규율이 필요하지만 일단 사고방식이 바뀌고 몇 가지 기술을 배우면 PostgreSQL 데이터베이스를 효율적이고 효과적으로 확장할 수 있는 가장 좋은 위치에 있게 될 것입니다. Timescale에는 압축, 계층형 스토리지, 데이터 보존 정책 등 PostgreSQL 데이터베이스 크기를 체계적으로 줄이는 데 도움이 되는 유용한 도구가 있습니다. 이를 통해 사용량 기반 모델에서 PostgreSQL 데이터베이스를 효과적으로 확장할 수 있습니다. . 직접 경험해 보려면 Timescale에 가입하세요. 처음 30일 동안 무료로 사용할 수 있습니다. - 작성. Carlota Sota 여기에도 게시되었습니다 .