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