데이터베이스 테이블 파티셔닝

GitLab에서 PostgreSQL 테이블 파티셔닝을 사용하는 방법과 전략, Rails 모델 설정, 그리고 파티셔닝 마이그레이션 도구를 설명합니다.

아래에서 답을 찾지 못한 질문이 있다면 이 이슈 를 확인하고 질문을 추가하세요. @gitlab-org/database-team/triage 태그를 달면 최대한 빨리 답변을 드립니다. Slack에서 답변을 받은 경우, 향후 이 문서를 업데이트할 수 있도록 이슈에도 내용을 기록해 두세요. 테이블 파티셔닝은 테이블 데이터를 하나의 큰 테이블처럼 동작하는 더 작은 물리적 테이블로 분할할 수 있는 강력한 데이터베이스 기능입니다. 파티셔닝을 염두에 두고 애플리케이션을 설계하면 다음과 같은 여러 이점을 얻을 수 있습니다: 데이터베이스가 모든 SQL 기능을 그대로 제공하면서도 검색 범위에서 많은 데이터를 저렴하게 제거할 수 있어 쿼리 성능이 크게 향상될 수 있습니다. 전체 파티션을 삭제하면 데이터베이스에 미치는 영향을 최소화하면서 대량 삭제를 수행할 수 있습니다. 이는 보존 기간을 벗어난 데이터를 주기적으로 삭제해야 하는 기능에 자연스럽게 맞습니다. VACUUM 및 인덱스 재구성과 같은 관리 작업을 하나의 대형 테이블 전체가 아닌 개별 파티션에 대해 실행할 수 있습니다. 안타깝게도 모든 모델이 파티셔닝 방식에 적합한 것은 아니며, 잘못 구현하면 심각한 문제가 발생할 수 있습니다. 또한 테이블은 생성 시에만 파티셔닝할 수 있어 사용 중인 데이터베이스에 파티셔닝을 적용하는 것은 간단하지 않습니다. 백엔드 개발자가 기존 테이블을 파티셔닝할 수 있도록 마이그레이션 도구 모음이 제공되지만, 마이그레이션 과정은 여러 릴리즈에 걸쳐 여러 단계로 나뉘어 상당히 복잡합니다. 파티셔닝의 제한 사항과 관련 마이그레이션의 특성상, 이 기능을 활용하기 전에 파티셔닝이 사용 사례에 적합한지 충분히 이해해야 합니다. 파티셔닝 마이그레이션 헬퍼는 원본 테이블의 파티셔닝된 복사본을 생성하고, 트리거와 백그라운드 마이그레이션의 조합을 사용하여 새 테이블로 데이터를 복사하는 방식으로 동작합니다. 원본 테이블 스키마 변경은 파티셔닝 마이그레이션과 병행하여 진행할 수 있지만, 마이그레이션이 작동하는 기반 메커니즘이 손상되지 않도록 주의해야 합니다. 예를 들어, 파티셔닝 중인 테이블에 칼럼이 추가되면 파티셔닝된 테이블과 트리거 정의 모두 그에 맞게 업데이트해야 합니다. 파티셔닝 사용 시점 결정 # 파티셔닝을 올바르게 적용하면 매우 유용할 수 있지만, 테이블의 데이터와 워크로드가 파티셔닝 방식에 자연스럽게 맞는지 먼저 파악하는 것이 중요합니다. 파티셔닝이 특정 문제에 적합한지 결정하기 위해 다음 사항을 파악하세요: 테이블 파티셔닝 . 테이블은 파티션 키를 기준으로 파티셔닝됩니다. 파티션 키는 파티션 간에 데이터를 어떻게 분할할지를 결정하는 칼럼 또는 칼럼 집합입니다. 데이터베이스는 데이터를 읽거나 쓸 때 파티션 키를 사용하여 어떤 파티션에 접근해야 하는지 결정합니다. 파티션 키는 해당 테이블에 접근하는 거의 모든 쿼리의 WHERE 절에 포함될 칼럼이어야 합니다. 데이터 분할 방식 . 데이터베이스가 파티션 간에 데이터를 분할하는 데 사용하는 전략은 무엇인가요? 복합 기본 키가 있는 파티셔닝된