PostgreSQL 데이터베이스 확장 비용이 더 저렴해졌습니다. Timescale의 계층형 스토리지가 정식 출시되었습니다.

용 Amazon RDS와 같은 제품은 소규모 배포에는 적합하지만 PostgreSQL을 확장하는 것은 다른 이야기입니다. 프로젝트가 수 테라바이트로 성장하면 이러한 관리형 데이터베이스는 속도가 느려지고 비용이 많이 들기 때문에 데이터 관리가 훨씬 더 복잡해집니다. PostgreSQL 테이블이 수십억 개의 행에 도달하면 성능이 저하됩니다. , 데이터는 계속해서 증가할 것입니다. 적절한 데이터 관리가 없으면 개발자는 디스크(및 청구서) 크기가 증가하는 것을 지켜볼 수만 있습니다. 개선할 수 있는 방법이 있어요 하지만 더 이상은 아닙니다. 오늘 우리는 Timescale 플랫폼에서 시계열 및 분석 데이터베이스에 대한 무한하고 저렴한 확장성을 지원하도록 설계된 다중 계층 스토리지 아키텍처인 계층형 스토리지의 일반 가용성을 발표하게 되어 기쁘게 생각합니다. 이제 자주 액세스하는 데이터에 대한 성능 저하 없이 오래되고 자주 액세스하지 않는 데이터를 저렴한 스토리지 계층에 저장하는 동시에 계속 액세스할 수 있습니다. 새로운 다중 계층 스토리지 백엔드를 사용하여 Timescale 시계열 데이터베이스에 데이터를 삽입하면 다음과 같은 일이 발생합니다. 가장 최근 데이터는 빠른 쿼리와 높은 수집에 최적화된 에 기록됩니다. 고성능 스토리지 계층 해당 데이터에 자주 액세스하지 않으면 계층화 정책을 설정하여 자동으로 으로 계층화할 수 있습니다. 저렴한 스토리지 계층의 데이터는 데이터베이스 내에서 완전히 쿼리 가능한 상태로 유지되며 저장할 수 있는 데이터 양에는 제한이 없습니다(최대 수백 TB 이상). 저렴한 개체 스토리지 계층 저렴한 스토리지 계층의 데이터 요금은 GB당 월 0.021달러로 Amazon S3보다 저렴합니다. 개발자에게는 성능 저하 없이 에서 대규모 PostgreSQL 데이터베이스를 확장할 수 있는 저렴한 방법이 필요합니다. 개체 저장소는 놀랍도록 확장 가능하고 저렴하지만 가장 빠르지는 않으며 개발자는 애플리케이션에 대한 밀리초 쿼리 응답 얻어야 합니다. AWS 도 그러나 데이터가 오래되고 거의 액세스되지 않으면 실시간 성능이 그다지 중요하지 않은 경우가 많습니다. 개발자는 임시 쿼리, 데이터 분석 또는 규정 준수를 위해 여전히 이 기록 데이터에 액세스할 수 있어야 하지만 이러한 유형의 쿼리에 대해 약간의 대기 시간을 가정할 수 있습니다. 이제 개발자가 원하는 것은 이 기록 데이터를 최대한 저렴하고 효율적으로 저장할 수 있는 기능입니다. 이 새로운 계층형 스토리지 아키텍처를 통해 개발자는 실시간 애플리케이션에 대한 스토리지 비용과 성능 균형 사이에서 선택할 필요가 없습니다. 최근에 자주 액세스하는 데이터를 고성능 계층에 유지함으로써 Timescale의 밀리초 쿼리 속도와 수집 기능을 활용하고, 오래된 데이터를 계층화함으로써 PostgreSQL 데이터베이스에 필요한 만큼의 TB를 유지할 수 있습니다. 더 적은. 계층형 스토리지를 사용한 PostgreSQL 데이터 관리: 알아야 할 사항 Timescale의 계층형 스토리지 아키텍처는 PostgreSQL의 유연성을 활용하고 효과적인 데이터 관리를 위해 하이퍼테이블을 생성할 때 이제 두 스토리지 계층에 걸쳐 원활하게 확장할 수 있습니다. , Timescale은 응답을 생성하기 위해 액세스할 스토리지 계층을 원활하게 파악하여 최신 데이터의 성능을 향상시키고 오래된 데이터의 스토리지 비용을 낮춥니다. 쿼리 또는 데이터 읽기당 추가 비용이 없으며 숨겨진 비용도 없으므로 간단하고 비용 효율적인 데이터 관리가 가능합니다. 하이퍼테이블 쿼리를 실행할 때 또한 이 스토리지 아키텍처는 Timescale 서비스의 모든 스토리지 제한을 제거합니다. 저렴한 스토리지 계층은 무한하므로 원하는 만큼 많은 TB를 저장할 수 있습니다. 예를 들어, 우리는 Insights 제품을 지원하는 거대한 Timescale 데이터베이스를 저장하기 위해 내부적으로 계층형 스토리지를 활용하고 있습니다. 이 Insights 데이터베이스는 고객 전체의 쿼리 통계를 지속적으로 수집 및 분석하고 있으며 현재 350TB를 초과했으며 빠르게 성장하고 있습니다. 350TB 중 250TB는 저렴한 스토리지로 계층화됩니다. 수학을 해보자: 물론 압축이 활성화되어 있으며 압축률은 20배입니다. 즉, 원래 100TB였던 Postgres 데이터가 압축 덕분에 이제 5TB 디스크에 들어갑니다(!) 압축 후 고성능 스토리지 계층에 5TB를 저장합니다. 나머지 250TB의 데이터는 저가형 스토리지 계층에 저장됩니다. 이 계층화는 데이터가 특정 기간(현재 몇 주)에 도달하면 자동으로 발생합니다. 대규모 배포를 진행 중인 고객 역시 이미 계층형 스토리지를 활용하고 있습니다. "우리는 시장 데이터에 대해 많은 분석을 수행하는데, 저장해야 하는 데이터의 양이 너무 많아서 일반 디스크 기반 데이터베이스 솔루션을 실행 불가능하게 만듭니다(너무 비쌉니다). Timescale의 계층형 스토리지를 사용하면 대량의 데이터를 원활하게 다른 곳으로 이동할 수 있습니다. 객체 스토리지 계층입니다. 이는 대량의 기록 데이터를 저장하고 사후 분석을 수행하는 데 탁월한 솔루션입니다. 이것이 없었다면 우리는 사내에서 솔루션을 개발해야 했을 것입니다." - 디지털 자산 거래 회사의 최고 기술 책임자(CTO) 단순성은 계층형 스토리지의 핵심 기능입니다. 고성능 계층에서 저가 개체 계층으로 데이터를 이동하려면 다음을 사용하면 됩니다. 특정 하이퍼테이블에서 데이터가 오래됨에 따라 데이터를 계층화하는 정책을 정의합니다. 데이터 계층화 정책은 청크 단위로 작동합니다. 정책은 정책에 정의된 기간에 도달하면 전체 청크를 계층화합니다. ETL(추출-변환-로드) 프로세스나 인프라 변경이 필요하지 않습니다. 간단한 API 시간 척도 하이퍼테이블은 시간에 따라 자동으로 분할된 PostgreSQL 테이블입니다. 이러한 파티션을 청크라고 합니다. 청크는 Timescale의 사용자 정의 정책 단위입니다. 예를 들어 데이터 보존 정책을 정의하면 전체 파티션(청크)이 삭제되고, 스토리지 계층 간에 데이터를 이동하면 전체 청크가 이동됩니다. . 이는 리소스 활용도와 개발자 경험 관점에서 데이터를 관리하는 매우 편리한 방법입니다. 편집자 주: 예를 들어, 이 정책은 한 달이 넘은 모든 데이터를 하이퍼테이블의 객체 스토리지로 이동합니다. events SELECT add_tiering_policy('events', INTERVAL '1 month'); 그게 당신이 필요한 전부입니다! 해당 계층에서만 SQL 쿼리를 실행하는 지능형 쿼리 계획을 포함하여 다른 모든 작업은 자동으로 수행됩니다. 현재 저가형 스토리지 계층에 저장된 데이터를 삭제하려면 데이터 보존 정책을 정의하여 특정 기간(예: 5년 후) 후에 데이터가 자동으로 삭제되도록 할 수 있습니다. . 특정 청크를 수동으로 삭제할 수도 있습니다 또한, 저비용 스토리지 계층에서 고성능 계층으로 특정 청크를 "뒤로 이동"하려는 경우( ), 쉽게 "계층화"할 수 있습니다. 예를 들어 데이터를 백필하거나 업데이트해야 하는 경우 -- Untier a particular chunk CALL untier_chunk('_hyper_1_1_chunk'); Timescale 콘솔에서 계층화된 데이터의 양(및 월말 비용)을 추적할 수 있습니다. 그리고 청구 추정에 대해 말하면… 계층형 스토리지로 얼마나 절약할 수 있나요? 당사의 고성능 스토리지 계층의 실질 가격은 데이터 GB당 월 0.177달러입니다. (우리 회사 전체에서 볼 수 있는 예상 압축률을 고려) 이제 모든 클라우드 지역에서 동일한 가격으로 데이터 GB당 월 0.021달러의 정액 요금을 부과하는 저렴한 스토리지 레이어가 여기에 추가되었습니다. 압축 후 데이터를 계층화할 때 실행된 쿼리나 스캔한 데이터 양이 아닌 됩니다. 이는 실제로 균일한 가격입니다. 이 가격 책정 구조의 목표는 총 데이터 스토리지 비용을 계산할 수 있는 투명하고 명확하며 간단한 방법을 제공하여 데이터를 보다 쉽게 관리할 수 있도록 하는 것이었습니다. 저장한 데이터에 대해서만 비용을 지불하면 빠른 예로, 5.2TB의 스토리지를 갖춘 하이퍼테이블이 있고 최근 하이퍼테이블 청크와 기타 Postgres 테이블이 약 200GB를 차지하고 한 달보다 오래된 약 5TB의 하이퍼테이블 데이터를 차지한다고 가정해 보겠습니다. 이 오래된 데이터에 자주 액세스하거나 쿼리하지 않으므로 애플리케이션의 일상적인 작업에 필요하지 않습니다. 그럼에도 불구하고 임시 쿼리나 규정 준수 요구 사항을 위해 데이터베이스에서 해당 정보에 계속 액세스할 수 있기를 원합니다(저희 고객 중에서 이러한 사례를 많이 볼 수 있습니다). 비용 효과적인 데이터 관리 전략으로, 한 달이 넘은 모든 청크를 저비용 계층으로 계층화하고 5TB의 데이터 저장 비용을 월 약 $478에서 약 $105/월로 절감할 수 있습니다. ( 이는 78% 감소입니다. 저장 청구서에. 이 추정에서는 하이퍼테이블에 대해 압축을 활성화하고 모든 Timescale 서비스의 전체 압축 중앙값을 고려한다고 가정합니다.) 데이터와 함께 절감 효과도 커집니다. 여러 테라바이트를 이 저렴한 계층으로 이동하면 스토리지 비용이 수천 달러에서 수백 달러로 줄어듭니다. 다음 참조 표는 저비용 스토리지 계층이 실제로 얼마나 저렴한지 보여줍니다. 당신은 요점을 이해합니다! 계층형 스토리지의 절감 효과 배가 계층형 스토리지를 더욱 놀라운 기능으로 만드는 것이 한 가지 더 있습니다. 저비용 스토리지 계층에 데이터를 보관할 때 서비스에서 실행 중인 고가용성 복제본이나 읽기 복제본이 있는지 여부에 관계없이 이 데이터에 대한 비용은 한 번만 지불하면 됩니다. . 포크에도 동일하게 적용됩니다. Timescale에서는 테스트 실행이나 개발 환경 생성 등을 위해 UI에서 버튼 하나를 클릭하여 기본 데이터베이스(포크라고 함)의 복사본을 생성할 수 있습니다. 하나 이상의 포크를 생성할 때 . 기본에 없는 더 많은 데이터를 계층화하기로 결정한 경우 이를 저비용 계층에 저장하기 위해 비용을 지불하게 되지만, 포크의 고성능 계층에서 저렴한 계층으로 이동하면 상당한 비용 절감 혜택을 누릴 수 있습니다. . 저비용 스토리지의 기본 포크와 공유된 데이터에 대해서는 요금이 청구되지 않습니다 이를 명확하게 하기 위해 예를 들어 보겠습니다. 6.5TB의 데이터를 포함하는 기본 서비스가 있고 다음과 같이 설정했다고 가정해 보겠습니다. 장애로 인한 다운타임 및 데이터 손실 위험을 크게 줄이는 고가용성 복제본 읽기 쿼리를 제공하고 기본 데이터베이스가 쓰기에만 전념할 수 있도록 하는 읽기 전용 복제본 개발 및 테스트 목적으로 해당 서비스를 포크한 것 청구 관점에서 고성능 스토리지 계층의 기본 서비스에 6.5TB의 데이터를 보관했다면 두 개의 복제본, 포크 및 기본 서비스—총 26TB. 평균 압축률을 가정하면 비용이 많이 듭니다(약 $4,602/월). 하지만 애플리케이션이 최신 500GB 데이터에만 적극적으로 액세스해야 한다면 어떻게 될까요? 6TB를 저렴한 스토리지로 계층화하고 고성능 스토리지 계층에서는 500GB만 유지할 수 있습니다. 그리고 저비용 스토리지 계층의 데이터 비용은 한 번만 지불하므로 새로운 스토리지 청구서는 다음과 같습니다. [500GB x 4] = 고성능 스토리지의 경우 2TB(26TB 대신) 저비용 스토리지 계층의 [6TB x 1] 위의 보관 비용은 월 최대 약 $480입니다. 이것이 계층형 스토리지의 절감 효과입니다. 특히 복제본이나 포크를 실행하는 경우 저렴한 스토리지 계층을 활용하는 것이 좋습니다. 전체 청구서에서 확인할 수 있는 절감 효과는 매우 큽니다. 월 $4,000 이상을 절약하게 됩니다! 계층형 스토리지 여정 우리는 3월에 Early Access로 Timescale 플랫폼에서 계층형 스토리지 기능의 초기 버전을 출시했습니다. 많은 개선을 거쳐 이제 일반 공급(General Availability)에 도달했습니다. 첫 번째 출시 이후 우리는 계층형 스토리지를 안정적이고 안정적이며 빠르게 만들기 위해 열심히 노력해 왔습니다. 또한 우리는 가격 책정 모델에 대해 오랫동안 열심히 생각하여 저렴한 스토리지 계층의 가격을 책정하는 여러 방법을 지속적으로 반복했습니다. 마지막으로 우리는 가장 단순한 방식인 압축 전 데이터 볼륨에 대한 정액 요금을 선택했습니다. 우리는 간단하고 예측 가능한 가격 책정을 어떻게 중요하게 생각하는지 이미 언급했지만 GB/월당 가격을 가능한 한 낮게 제공하는 것도 중요했습니다. 가격은 0.021달러였습니다. 비교하자면 Amazon S3에 파일을 저장하는 데 드는 비용입니다. . GB당 $0.023/월 개인적으로 나(Yannis)는 팀을 이끌고 10년 넘게 클라우드 네이티브 솔루션을 구축한 후에도 여전히 돌아가서 때때로 다양한 클라우드 가격 페이지에서 여러 요금표를 다시 확인해야 하며, 특히 추가 요금을 찾을 때마다 다시 확인해야 한다는 점을 인정해야 합니다. 우리 서비스의 총 비용을 정확하게 계산하고 싶습니다. Timescale에서는 데이터베이스 서비스를 실행하거나 스토리지 계층에 대해 정보에 근거한 선택을 하기 위해 복잡한 스프레드시트를 작성할 필요가 없다고 믿습니다. 개발자의 삶을 더 쉽게 만들기 위한 우리의 노력으로 GB당 월 0.021달러의 정액 요금을 달성했습니다. 추측이나 숨겨진 비용, 쿼리 또는 데이터 읽기당 요금이 없습니다. 시간 단위 압축을 적용하기 전의 데이터 볼륨을 의미합니다. 예를 들어 시간 척도 압축으로 인해 고성능 스토리지 계층의 500GB 볼륨을 압축하면 50GB의 디스크 공간만 필요할 수 있습니다. 이 데이터를 저비용 스토리지로 계층화하기로 결정한 경우 청구서는 월별 [500GB * $0.021]와 같이 원래 500GB 볼륨에 대해 계산됩니다. 데이터 볼륨 사전 압축은 계층형 스토리지 작동 방식: 비하인드 스토리 Timescale에 삽입된 모든 데이터는 처음에 고성능 스토리지 계층에 기록됩니다. 가장 최근 데이터에 더 빠른 디스크를 사용하면 가장 최근 값에 대한 최고의 삽입 및 쿼리 성능을 얻을 수 있으며, 이는 데이터 집약적인 애플리케이션의 요구 사항에 맞는 사용 패턴입니다. 반대로 저비용 스토리지 계층은 Amazon S3를 기반으로 구축된 객체 저장소입니다. 하지만 이 객체 저장소는 데이터를 보관하는 외부 버킷 그 이상입니다. 이는 데이터베이스의 필수적인 부분입니다. 데이터를 이 개체 스토리지 계층으로 이동하면 데이터베이스는 모든 의미 체계와 메타데이터를 완전히 인식하고 표준 SQL을 사용하여 평소처럼 계속 쿼리할 수 있습니다(성능은 느리지만). 그 뒤에서는 압축된 열 형식(구체적으로 )으로 데이터를 저장하고 있습니다. 데이터가 계층화되면 청크는 Timescale의 기본 내부 데이터베이스 형식(일반적으로 당사의 )은 Parquet 형식으로 비동기적으로 변환되어 기본 S3 객체에 저장됩니다. 계층화된 청크를 고성능 계층에서 트랜잭션 방식으로 제거하기 전에 저비용 스토리지 계층에 안정적으로 저장되도록 하는 여러 메커니즘을 구축했습니다. Apache Parquet 기본 기둥형 압축 SQL 쿼리를 실행하면 필요에 따라 고성능 스토리지 계층, 개체 스토리지 계층 또는 둘 다에서 데이터를 투명하게 가져옵니다. 투명하다는 것은 투명성을 의미합니다. Timescale은 복잡한 조건자, JOIN, CTE, 창 작업, 하이퍼함수 등을 포함하여 표준 및 계층형 데이터 전반에 걸쳐 임의로 복잡한 쿼리를 지원합니다. 아래 예제 쿼리( 절 포함)에서는 데이터베이스가 개체 스토리지 계층의 데이터에 액세스할 때 쿼리 계획에 포함되는 방식을 확인할 수 있습니다. 이 예에서 와 표준 Postgres 테이블(고성능 스토리지에만 상주함)이고 두 스토리지 계층에 걸쳐 확장되는 하이퍼테이블입니다. 하이퍼테이블에 대해 이 쿼리를 실행할 때 해당 청크 중 3개를 표준 스토리지에서 읽었고, 5개 청크를 객체 스토리지에서 읽었습니다. EXPLAIN Foreign Scan devices sites metrics metrics EXPLAIN SELECT time_bucket('1 day', ts) as day, max(value) as max_reading, device_id FROM metrics JOIN devices ON metrics.device_id = devices.id JOIN sites ON devices.site_id = sites.id WHERE sites.name = 'DC-1b' GROUP BY day, device_id ORDER BY day; QUERY PLAN ---------------------------------------------------------- GroupAggregate Group Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Sort Sort Key: (time_bucket('1 day'::interval, _hyper_5666_706386_chunk.ts)), _hyper_5666_706386_chunk.device_id -> Hash Join Hash Cond: (_hyper_5666_706386_chunk.device_id = devices.id) -> Append -> Seq Scan on _hyper_5666_706386_chunk -> Seq Scan on _hyper_5666_706387_chunk -> Seq Scan on _hyper_5666_706388_chunk -> Foreign Scan on osm_chunk_3334 -> Hash -> Hash Join Hash Cond: (devices.site_id = sites.id) -> Seq Scan on devices -> Hash -> Seq Scan on sites Filter: (name = 'DC-1b'::text) 위의 쿼리 계획에서 바닥이 없는 개체 스토리지 계층에서 데이터를 가져오는 것에 해당합니다. Foreign Scan on osm_chunk_3334 쿼리 시간 범위를 벗어나는 청크 처리를 방지하기 위해 쿼리를 만족시키는 데 필요한 청크만 건드리도록 청크 제외를 수행합니다. 데이터베이스는 다양한 형태의 메타데이터를 저장하여 객체 스토리지 내에서 행 그룹 및 열 형식 오프셋의 "맵"을 구축합니다. 또한 쿼리가 실행될 때 읽는 데이터에 대해 더욱 선택적입니다. 쿼리가 행 범위와 몇 개의 열에만 적용되는 경우 저비용 스토리지 계층 뒤의 S3 객체에서 해당 데이터 하위 집합만 읽습니다. 예를 들어 위의 경우 개체 스토리지 계층에서 및 열만 읽습니다. 추가 시간 기반 필터가 포함된 경우 데이터베이스는 먼저 해당 메타데이터(고성능 저장소에 저장되고 메모리에 캐시됨)를 사용하여 쿼리를 실행하기 위해 읽어야 하는 Parquet 파일 및 행 그룹을 더욱 줄입니다. PostgreSQL을 통해 투명하게 이 무한한 스토리지에 액세스하는 경우에도 쿼리 대기 시간을 줄이기 위한 것입니다. device_id value WHERE 계층형 스토리지를 사용해 보세요 기록 데이터에 대한 스토리지 결정은 비용이 많이 들 필요가 없습니다. Timescale에서는 이제 애플리케이션 성능을 저하시키지 않고 저렴한 가격으로 데이터베이스 스토리지를 확장할 수 있는 가격 문제가 없는 저비용의 무한 스토리지 계층에 액세스할 수 있습니다. 이것이 귀하의 사용 사례에 적합한 솔루션인지 궁금하시다면, 보다 실용적인 관점을 찾고 있다면 다음을 실험해 볼 수도 있습니다. . 자세한 내용과 사용 사례에 맞는 내용은 문서를 확인하세요. 무료 평가판을 통해 Timescale 플랫폼에서 무료로 계층형 스토리지를 직접 사용할 수 있습니다(신용 카드 필요 없음). - Yannis Roussos, Carlota Soto 및 Ana Tavares가 작성했습니다. 여기에도 게시되었습니다 .