GitLab은 GitLab과 고객 모두의 관리 편의성을 높이기 위해 대형 데이터베이스 테이블의 스키마 변경에 일부 제한을 적용합니다. 이러한 제한이 적용되는 테이블 목록은 rubocop/rubocop-migrations.yml에 정의되어 있습니다.

테이블 크기 제한#

다음 제한 사항이 GitLab.com의 테이블 스키마 변경에 적용됩니다:

이러한 제한은 향상된 안정성 및 성능을 위해 모든 테이블을 100 GB 미만으로 유지한다는 목표와 일치합니다.

예외#

크기 제한에 대한 예외는 다음 경우에 한해서만 허용됩니다:

• 테이블 칼럼을 int4에서 int8로 마이그레이션하는 경우

• Cells를 지원하기 위해 샤딩 키를 추가하는 경우

• 파티셔닝 또는 데이터 보존 작업을 지원하기 위해 테이블을 수정하는 경우

• 더 나은 쿼리 성능을 제공하기 위해 기존 인덱스를 교체하는 경우

예외 요청#

이러한 제한에 대한 예외를 요청하려면:

• Database Team Tasks 템플릿을 사용하여 새 이슈를 생성합니다

• schema_change_exception 템플릿을 선택합니다

• 해당 케이스에 예외가 필요한 이유에 대한 자세한 근거를 제공합니다

• 진행하기 전에 Database 팀의 검토 및 승인을 기다립니다

• 마이그레이션에서 cop을 비활성화할 때 승인 이슈를 링크합니다

테이블 크기를 줄이기 위한 기법#

예외를 요청하기 전에 테이블 크기를 관리하기 위한 다음 접근 방식을 고려하세요:

데이터 아카이빙#

• 오래되고 자주 접근하지 않는 데이터를 아카이브 테이블로 이동합니다

• 자동화된 데이터 마이그레이션을 위한 아카이빙 워커를 구현합니다

• 아카이빙을 용이하게 하기 위해 날짜별 파티셔닝 사용을 고려합니다. 날짜 범위 파티셔닝을 참조하세요

데이터 보존#

• 오래된 데이터를 제거하는 보존 정책을 구현합니다

• 만료된 데이터에 대한 자동화된 정리 job을 구성합니다. 오래된 파이프라인 삭제를 참조하세요

테이블 파티셔닝#

• 날짜별로 대형 테이블을 파티셔닝하거나 ID 범위 또는 기타 기준으로 파티셔닝합니다

• 접근 패턴에 따라 범위 또는 목록 파티셔닝을 고려합니다

칼럼 최적화#

• 적절한 데이터 타입을 사용합니다 (예: 가능한 경우 integer 대신 smallint)

• 사용하지 않거나 중복된 인덱스를 제거합니다

• 빈 문자열이나 0 대신 NULL 사용을 고려합니다

• 저장소 오버헤드를 방지하기 위해 varchar 대신 text를 사용합니다

정규화#

• 대형 테이블을 관련된 소규모 테이블로 분리합니다

• 자주 사용하지 않는 칼럼을 별도의 테이블로 이동합니다

• 다대다 관계에는 junction 테이블을 사용합니다

• 와이드 테이블에는 수직 파티셔닝을 고려합니다

외부 스토리지#

• 대용량 텍스트 또는 바이너리 데이터를 오브젝트 스토리지로 이동합니다

• 데이터베이스에는 메타데이터만 저장합니다

• 검색 전용 데이터에는 Elasticsearch를 사용합니다

• 임시 데이터나 캐시된 데이터에는 Redis 사용을 고려합니다

테이블 수정의 대안#

대형 테이블을 다룰 때 다음 대안을 고려하세요:

• 새 칼럼을 위해 별도의 테이블을 생성합니다. 특히 칼럼이 모든 행에 존재하지 않는 경우에 유용합니다. 새 테이블은 외래 키를 통해 원래 테이블을 참조합니다.

• Global Search 팀과 협력하여 향상된 필터/검색 기능을 위해 데이터를 Elasticsearch에 추가합니다.

• 필터링/정렬 옵션을 단순화합니다 (예: 정렬에 created_at 대신 id 사용).

테이블 크기 제한의 이점#

테이블 크기 제한은 다음과 같은 여러 이점을 제공합니다:

• 서로 다른 빈도로 별도의 vacuum 작업을 수행할 수 있습니다

• 칼럼 업데이트 시 Write-Ahead Log(WAL) 데이터 생성량을 줄입니다

• 행 업데이트 중 불필요한 데이터 복사를 방지합니다

데이터 모델 트레이드오프에 대한 자세한 내용은 데이터베이스 문서를 참조하세요.

has_one 관계 사용#

테이블이 새 칼럼을 추가하기에 너무 커진 경우 has_one 관계를 사용하여 새 테이블을 생성합니다. 예를 들어, 머지 리퀘스트 !170371에서는 이슈의 총 가중치 수를 별도의 테이블에서 추적합니다.

이 접근 방식의 이점:

• 기본 테이블을 더 좁게 유지하여 PostgreSQL에서의 데이터 로드를 줄입니다

• 특정 쿼리를 위한 효율적인 좁은 테이블을 생성합니다

• 필요에 따라 새 테이블을 선택적으로 채울 수 있습니다

이 접근 방식은 다음과 같은 경우에 특히 효과적입니다:

• 새 칼럼이 기본 테이블의 일부 행에만 적용되는 경우

• 특정 쿼리만 새 데이터를 필요로 하는 경우

단점

• 테이블이 많아지면 더 많은 "join"이 발생하여 쿼리가 복잡해질 수 있습니다

• 여러 join이 있는 쿼리는 최적화하기 어려울 수 있습니다

관련 링크#

• 데이터베이스 크기 제한

• 데이터베이스 인덱스 추가

• 데이터베이스 레이아웃 및 접근 패턴

• 기능 개발을 위한 데이터 보존 가이드라인