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

경고: 아래에 답변되지 않은 질문이 있으면 이 이슈를 확인하고 추가하십시오. @gitlab-org/database-team/triage 태그를 달아주시면 빠른 시일 내에 회신해 드리겠습니다. 만약 Slack에서 답변을 받았다면 해당 문서에도 기록하여 향후 이 문서를 업데이트할 수 있도록 합니다.

테이블 파티셔닝은 테이블의 데이터를 단일 대형 테이블로 작용하는 작은 물리적 테이블로 분할할 수 있는 강력한 데이터베이스 기능입니다. 응용 프로그램이 파티셔닝을 염두에 두고 설계된 경우 여러 가지 이점이 있을 수 있습니다. 예를 들어:

  • 데이터베이스는 비용 효율적으로 많은 데이터를 검색 영역에서 제거할 수 있으면서도 완전한 SQL 기능을 제공하므로 쿼리 성능을 크게 향상시킬 수 있습니다.

  • 전체 파티션을 삭제하여 데이터베이스에 미미한 영향을 미치게 하는 대량 삭제가 가능합니다. 이는 주기적으로 유지 기간을 벗어나는 데이터를 삭제해야 하는 기능에 자연스러운 적합성을 가집니다.

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

안타깝게도 모든 모델이 파티셔닝 방식에 적합하지는 않으며, 잘못 구현된 경우 중대한 단점이 있습니다. 게다가, 테이블은 생성 시에만 파티셔닝할 수 있으며, 파티셔닝을 바쁜 데이터베이스에 적용하는 것이 비단순합니다. 기존 테이블을 파티셔닝하려면 백엔드 개발자가 지원하는 다양한 이주 도구가 있지만, 이주 프로세스는 상당히 복잡하여 여러 릴리스에 걸친 여러 단계로 이루어집니다. 파티셔닝 및 관련 마이그레이션의 제한으로 인해, 파티셔닝이 사용 사례에 어떻게 맞는지 이해한 후에 이 기능을 활용하려고 시도해야 합니다.

파티셔닝 마이그레이션 도우미는 원본 테이블의 파티셔닝된 복제본을 만들고 트리거 및 백그라운드 마이그레이션의 조합을 사용하여 데이터를 새 테이블로 복사합니다. 원본 테이블 스키마의 변경 사항은 파티셔닝 마이그레이션과 병렬로 이루어질 수 있지만, 마이그레이션을 작동시키는 기본 메커니즘을 손상시키지 않도록 주의해야 합니다. 예를 들어, 파티셔닝되는 테이블에 열이 추가된 경우, 파티셔닝된 테이블 및 트리거 정의가 모두 일치하도록 업데이트해야 합니다.

파티셔닝 사용 시기 결정

적절하게 적용될 때 파티셔닝은 매우 유용할 수 있지만, 테이블의 데이터와 작업 부하가 파티셔닝 방식과 자연스럽게 일치하는지 여부를 판단하는 것이 중요합니다. 파티셔닝이 특정 문제에 적합한지 결정하기 위해 몇 가지 세부 정보를 이해해야 합니다:

  • 테이블 파티셔닝. 테이블은 데이터가 어떻게 파티션에 나뉘는지를 결정하는 파티션 키(하나 이상의 열)로 파티셔닝됩니다. 데이터베이스는 데이터를 읽거나 쓸 때 파티션에 액세스해야 하는지 결정하기 위해 파티션 키를 사용합니다. 파티션 키는 해당 테이블에 액세스하는 거의 모든 쿼리의 WHERE 절에 포함될 열이어야 합니다.

  • 데이터가 어떻게 나뉘는지. 데이터베이스는 데이터를 파티션에 어떤 전략으로 나누는지가 중요합니다. 사용 가능한 선택 사항으로는 범위(range), 해시(hash), 리스트(list) 등이 있습니다.

적절한 파티셔닝 전략 결정

사용 가능한 파티셔닝 전략 선택 사항으로는 날짜 범위(date range), 정수 범위(int range), 해시(hash), 리스트(list)가 있습니다.