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

경고:
아래에 답변되지 않은 질문이 있는 경우, 이 문제를 확인하고 추가하세요.
@gitlab-org/database-team/triage 태그를 붙이면 최대한 빨리 답변해 드리겠습니다. Slack에서 답변을 받으면, 이 문서를 업데이트할 수 있도록 문제에 문서화해 주세요.

테이블 파티셔닝은 테이블의 데이터를 하나의 큰 테이블처럼 작동하는 더 작은 물리적 테이블로 분할할 수 있게 해주는 강력한 데이터베이스 기능입니다. 애플리케이션이 파티셔닝을 염두에 두고 설계된 경우, 여러 가지 장점이 있을 수 있습니다.

  • 데이터베이스가 검색 공간의 많은 데이터를 저렴하게 제거할 수 있기 때문에 쿼리 성능이 크게 향상될 수 있으며, 여전히 전체 SQL 기능을 제공합니다.

  • 전체 파티션을 삭제함으로써 데이터베이스에 미치는 영향을 최소화하여 대량 삭제를 수행할 수 있습니다. 이는 보존 기간을 초과한 데이터를 주기적으로 삭제해야 하는 기능에 자연스럽게 적합합니다.

  • VACUUM과 인덱스 재구성 같은 관리 작업은 단일 대규모 테이블이 아닌 개별 파티션에서 작업할 수 있습니다.

불행히도 모든 모델이 파티셔닝 계획에 적합하지 않으며, 잘못 구현할 경우 상당한 단점이 있습니다. 또한, 테이블은 생성 시에만 파티셔닝할 수 있으며, 바쁜 데이터베이스에 파티셔닝 적용하는 것은 간단하지 않습니다. 기존 테이블을 파티셔닝할 수 있도록 백엔드 개발자를 위한 일련의 마이그레이션 도구가 제공되지만, 마이그레이션 과정은 꽤 무거워 여러 릴리스에 걸쳐 여러 단계로 나뉘어져 진행되어야 합니다. 파티셔닝의 한계와 관련된 마이그레이션 때문에, 이 기능을 활용하기 전에 파티셔닝이 귀하의 사용 사례에 어떻게 적합한지 이해해야 합니다.

파티셔닝 마이그레이션 헬퍼는 원본 테이블의 파티셔닝된 복제본을 생성하고 데이터 복사를 위한 트리거 및 배경 마이그레이션의 조합을 사용하여 작동합니다. 원본 테이블 스키마에 대한 변경은 파티셔닝 마이그레이션과 병행하여 수행할 수 있지만, 마이그레이션을 작동하게 하는 기본 메커니즘을 깨뜨리지 않도록 주의해야 합니다. 예를 들어, 파티셔닝되는 테이블에 열을 추가하는 경우, 파티셔닝된 테이블과 트리거 정의 모두 업데이트해야 합니다.

파티셔닝 사용 시점 결정

파티셔닝이 제대로 적용되면 매우 유용할 수 있지만, 테이블의 데이터와 작업이 자연스럽게 파티셔닝 계획에 적합한지 식별하는 것이 중요합니다. 다음 몇 가지 세부 정보를 이해하여 파티셔닝이 특정 문제에 적합한지 결정하세요.

  • 테이블 파티셔닝. 테이블은 파티션 키를 기준으로 파티셔닝되며, 이는 데이터가 파티션에 어떻게 분할되는지를 결정하는 열 또는 열 집합입니다. 데이터베이스는 데이터를 읽거나 쓸 때 어느 파티션에 접근해야 하는지 결정하기 위해 파티션 키를 사용합니다. 파티션 키는 거의 모든 쿼리에서 해당 테이블에 대한 WHERE 절에 포함될 열이어야 합니다.

  • 데이터 분할 방식. 데이터베이스는 데이터를 파티션 간에 어떻게 분할합니까?

적절한 파티셔닝 전략 결정

사용 가능한 파티셔닝 전략 선택지는 date range, int range, hash, 및 list입니다.