데이터베이스 테이블 파티셔닝
@gitlab-org/database-team/triage
태그를 달고 최대한 빨리 답변을 받을 수 있도록 합니다. 만약 슬랙에서 답변을 받았다면, 해당 답변을 문서에 기록하여 우리가 향후에 이 문서를 업데이트할 수 있도록 해주세요.테이블 파티셔닝은 테이블의 데이터를 단일 대규모 테이블로 작용하는 작은 물리적 테이블로 분할할 수 있는 강력한 데이터베이스 기능입니다. 응용 프로그램이 파티셔닝을 고려하여 설계된 경우 여러 이점이 있을 수 있습니다.
-
데이터베이스는 비용 저렴하게 검색 공간의 많은 일부를 제거할 수 있지만 여전히 완전한 SQL 기능을 제공할 수 있기 때문에 쿼리 성능이 크게 향상될 수 있습니다.
-
전체 파티션을 삭제함으로써 데이터베이스에 미미한 영향을 미치면서 대량 삭제를 달성할 수 있습니다. 이는 주기적으로 보존 기간을 벗어나는 데이터를 삭제해야 하는 기능에 적합합니다.
-
관리 작업인
VACUUM
및 인덱스 다시 작성은 단일 대규모 테이블 전체가 아닌 개별 파티션에서 수행할 수 있습니다.
안타깝게도, 모든 모델이 파티셔닝 체계에 적합한 것은 아니며, 부적절하게 구현된 경우 중대한 단점이 있습니다. 게다가, 테이블은 생성 시에만 파티션화될 수 있으며, 복잡한 데이터베이스에 파티션화를 적용하는 것은 어려운 문제입니다. 기존 테이블을 파티션화하려면 백엔드 개발자가 사용할 수 있는 일련의 마이그레이션 도구가 있지만, 마이그레이션 과정은 여러 단계에 걸쳐 여러 릴리스로 분할되므로 상당히 복잡합니다. 파티셔닝의 제한 사항 및 관련 마이그레이션으로 인해 이 기능이 사용 사례에 어떻게 맞는지 알아보기 전에 매우 신중하게 고려해야 합니다.
파티션 마이그레이션 도우미는 원본 테이블의 파티션화된 복제본을 만들고 트리거와 백그라운드 마이그레이션을 결합하여 데이터를 새 테이블로 복사합니다. 원본 테이블 스키마의 변경사항은 파티션 마이그레이션과 병행하여 수행할 수 있지만, 마이그레이션이 작동하는 기본 메커니즘을 손상시키지 않도록 주의해야 합니다. 예를 들어, 테이블에 열이 추가되는 경우 파티션된 테이블과 트리거 정의를 모두 업데이트하여 일치해야 합니다.
파티셔닝 사용 시기 결정
파티셔닝이 적절하게 적용될 때 매우 유용할 수 있지만, 테이블의 데이터 및 워크로드가 파티셔닝 체계와 자연스럽게 일치하는지 여부를 식별하는 것이 중요합니다. 파티셔닝이 특별한 문제에 적합한지 결정하기 위해 몇 가지 세부 사항을 이해하세요:
-
테이블 파티셔닝. 테이블은 데이터가 파티션 간에 어떻게 분할되는지 결정하는 파티션 키(열 또는 열 집합)에 의해 파티셔닝됩니다. 데이터베이스는 데이터를 읽거나 쓸 때 파티션이 어떤지 결정하는 데 파티션 키를 사용하여 테이블에 액세스해야 하는지 결정합니다. 파티션 키는 해당 테이블에 액세스하는 거의 모든 쿼리에서
WHERE
절에 포함될 수 있는 열이어야 합니다. -
데이터가 어떻게 분할되는지. 데이터베이스는 데이터를 파티션 간에 어떻게 분할하는지 어떤 전략을 사용합니까? 사용 가능한 선택 사항은
range
,hash
,list
입니다.
적절한 파티셔닝 전략 결정
사용 가능한 파티셔닝 전략 옵션은 date range
, int range
, hash
, list
입니다.