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

caution
아래에서 답변되지 않은 질문이 있으면 이 이슈를 확인하고 추가해 주세요. @gitlab-org/database-team/triage 태그를 달고 우리는 가능한 빨리 답변드리겠습니다. Slack에서 답변을 받았다면, 해당 내용을 문서에 기록하여 향후에도 이 문서를 업데이트할 수 있도록 해 주세요. 테이블 파티셔닝은 강력한 데이터베이스 기능으로, 테이블의 데이터를 단일 대규모 테이블처럼 작동하는 작은 물리적 테이블로 분할할 수 있습니다. 응용 프로그램이 파티셔닝을 고려하여 설계된 경우에는 여러 가지 이점이 있을 수 있습니다.
  • 데이터베이스가 검색 공간에서 많은 데이터를 싸게 제거하면서도 완전한 SQL 기능을 제공하기 때문에 조회 성능을 크게 향상시킬 수 있습니다.
  • 보존 기간을 벗어난 데이터를 주기적으로 삭제해야 하는 기능에 대해 전체 파티션을 삭제함으로써 데이터베이스에 미미한 영향을 미칠 수 있습니다.
  • VACUUM 및 인덱스 다시 작성과 같은 관리 작업은 단일 대규모 테이블 전체가 아닌 개별 파티션에서 작동할 수 있습니다.

안타깝게도 모든 모델이 파티셔닝 체계에 적합한 것은 아니며, 잘못 구현된 경우 중대한 단점이 있을 수 있습니다. 게다가, 테이블은 생성 시에만 파티셔닝 될 수 있으며, 파티셔닝을 바쁜 데이터베이스에 적용하는 것은 비단순한 과정입니다. 백엔드 개발자가 기존 테이블을 파티셔닝하도록 하려면 여러 단계로 이뤄진 무거운 마이그레이션 과정을 거치도록 하는 여러 마이그레이션 도구가 있지만, 파티셔닝 및 관련 마이그레이션의 제약으로 이러한 기능을 활용하기 전에 파티셔닝이 사용 사례에 어떻게 맞는지 이해해야 합니다.

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

파티셔닝 사용 시기 결정

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

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

  • 데이터가 어떻게 분할되는지. 데이터베이스가 데이터를 파티션 간에 어떻게 분할하는지에 대한 전략은 range, hash, list가 있습니다.

적절한 파티셔닝 전략 결정

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