이 글은 AWS Database Blog에 게시된 Speed up time series data ingestion by partitioning tables on Amazon RDS for PostgreSQL by Vinicius Schmidt and Andy Katz을 한국어 번역 및 편집하였습니다. 지난 포스트 (Amazon RDS for PostgreSQL에서 고성능 시계열 데이터 테이블 설계)에서는 시계열 데이터를 처리할 때 성능을 향상시키는 전략으로 파티션된 테이블(partitioned tables)을 사용하는 방법을 설명했습니다. 이번 […] ||
이 글은 AWS Database Blog에 게시된 Speed up time series data ingestion by partitioning tables on Amazon RDS for PostgreSQL by Vinicius Schmidt and Andy Katz을 한국어 번역 및 편집하였습니다.
지난 포스트 (Amazon RDS for PostgreSQL에서 고성능 시계열 데이터 테이블 설계)에서는 시계열 데이터를 처리할 때 성능을 향상시키는 전략으로 파티션된 테이블(partitioned tables)을 사용하는 방법을 설명했습니다. 이번 포스트에서는 데이터 수집(data ingestion)에 초점을 맞춰 파티션된 테이블이 데이터 수집에 어떻게 도움이 되는지 살펴보겠습니다.
PostgreSQL은 이미 오래전부터 테이블 파티셔닝 기능을 제공해왔습니다. PostgreSQL 10 이전에는 트리거와 테이블 상속을 사용하여 파티션을 생성할 수 있었으며, 이를 통해 파티션 작동 방식을 사용자 정의할 수 있었습니다. 하지만 이 방법은 복잡하고 유지 관리가 어려웠습니다. PostgreSQL 10에서는 선언적 파티션(declarative partitions)이 도입되었습니다. 선언적 파티션(네이티브 파티션)은 테이블 스캔 중에 옵티마이저가 불필요한 파티션을 제외하도록 하는 체크 제약 조건(check constraints) 정의하는 번거로움을 없애주었습니다. 이를 파티션 프루닝(partition pruning)이라고도 합니다. 선언적 파티셔닝은 각 파티션으로 쓰기를 리디렉션하기 위해 부모 테이블에 트리거를 배치할 필요가 없습니다.
2017년 PostgreSQL 10이 출시된 이후, PostgreSQL 커뮤니티에 의해 많은 개선사항이 만들어졌고 계속해서 개선되고 있습니다. 이러한 개선사항에는 성능 향상, foreign data wrapper와 같은 다른 엔진 구성 요소와의 향상된 통합, 논리적 복제(logical replication) 지원 등 다양한 기능이 포함됩니다.
파티셔닝의 아이디어는 데이터베이스 엔진이 단일 대형 테이블을 처리하는 것과 비교하여 작은 데이터 청크(객체 또는 파티션)를 처리할 때 더 나은 성능을 발휘한다는 것입니다. 이는 테이블을 읽어야 할 때뿐만 아니라 새로운 데이터 행을 수집할 때도 마찬가지입니다. 이 포스트는 파티션된 테이블이 데이터 수집에 도움이 되는 이유에 초점을 맞춥니다.첫 번째 포스트를 읽지 않으셨다면, 이 글을 더 잘 이해하는 데 도움이 될 것이므로 먼저 읽어보시기를 강력히 권장합니다.
성능 요인
테이블에 행을 삽입(또는 수집)하는 작업의 성능에 영향을 미치는 여러 요인이 있습니다. 데이터베이스를 요구사항에 맞게 더 잘 최적화하기 위해서는 이러한 각 요인을 이해하는 것이 중요합니다. 이 포스트에서는 다음 사항들을 다룹니다:
테이블 크기
인덱스
수집 방법
체크포인트
가용 영역
테이블 크기
테이블 크기는 행 수와 디스크에서 소비하는 공간을 의미합니다. 데이터 수집에 대해서만 보자면, 테이블 크기 자체는 수집 성능에 큰 영향을 미치지 않습니다. 대부분의 경우 큰 테이블은 읽기 작업도 수행해야 합니다. 테이블이 클수록 읽기 속도는 느려집니다. 읽기 속도를 높이기 위해 인덱스를 생성하지만, 여기에는 함정이 있습니다. 대형 테이블에 인덱스가 많을수록 데이터 수집이 느려집니다.
인덱스
테이블 크기와 관련이 있지만