대형 테이블 제한 사항

GitLab 데이터베이스에서 대형 테이블에 대한 스키마 변경 제한 사항 및 테이블 크기를 줄이기 위한 기법을 설명합니다.

GitLab은 GitLab과 고객 모두의 관리 편의성을 높이기 위해 대형 데이터베이스 테이블의 스키마 변경에 일부 제한을 적용합니다. 이러한 제한이 적용되는 테이블 목록은 rubocop/rubocop-migrations.yml 에 정의되어 있습니다. 테이블 크기 제한 # 다음 제한 사항이 GitLab.com의 테이블 스키마 변경에 적용됩니다: 제한 사항 작업 후 최대 크기 (인덱스 및 칼럼 크기 포함) 인덱스 추가 불가 50 GB 외래 키가 있는 칼럼 추가 불가 50 GB 새 칼럼 추가 불가 100 GB 이러한 제한은 향상된 안정성 및 성능 을 위해 모든 테이블을 100 GB 미만으로 유지 한다는 목표와 일치합니다. 예외 # 크기 제한에 대한 예외는 다음 경우에 한해서만 허용됩니다: 테이블 칼럼을 int4 에서 int8 로 마이그레이션하는 경우 Cells를 지원하기 위해 샤딩 키를 추가하는 경우 파티셔닝 또는 데이터 보존 작업을 지원하기 위해 테이블을 수정하는 경우 더 나은 쿼리 성능을 제공하기 위해 기존 인덱스를 교체하는 경우 예외 요청 # 이러한 제한에 대한 예외를 요청하려면: Database Team Tasks 템플릿 을 사용하여 새 이슈를 생성합니다 schema_change_exception 템플릿을 선택합니다 해당 케이스에 예외가 필요한 이유에 대한 자세한 근거를 제공합니다 진행하기 전에 Database 팀의 검토 및 승인을 기다립니다 마이그레이션에서 cop을 비활성화할 때 승인 이슈를 링크합니다 테이블 크기를 줄이기 위한 기법 # 예외를 요청하기 전에 테이블 크기를 관리하기 위한 다음 접근 방식을 고려하세요: 데이터 아카이빙 # 오래되고 자주 접근하지 않는 데이터를 아카이브 테이블로 이동합니다 자동화된 데이터 마이그레이션을 위한 아카이빙 워커를 구현합니다 아카이빙을 용이하게 하기 위해 날짜별 파티셔닝 사용을 고려합니다. 날짜 범위 파티셔닝 을 참조하세요 데이터 보존 # 오래된 데이터를 제거하는 보존 정책을 구현합니다 만료된 데이터에 대한 자동화된 정리 job을 구성합니다. 오래된 파이프라인 삭제 를 참조하세요 테이블 파티셔닝 # 날짜별로 대형 테이블을 파티셔닝 하거나 ID 범위 또는 기타 기준으로 파티셔닝합니다 접근 패턴에 따라 범위 또는 목록 파티셔닝을 고려합니다 칼럼 최적화 # 적절한 데이터 타입을 사용합니다 (예: 가능한 경우 integer 대신 smallint ) 사용하지 않거나 중복된 인덱스를 제거합니다 빈 문자열이나 0 대신 NULL 사용을 고려합니다 저장소 오버헤드를 방지하기 위해 varchar 대신 text 를 사용합니다 정규화 # 대형 테이블을 관련된 소규모 테이블로 분리합니다 자주 사용하지 않는 칼럼을 별도의 테이블 로 이동합니다 다대다 관계에는 junction 테이블을 사용합니다 와이드 테이블 에는 수직 파티셔닝을 고려합니다 외부 스토리지 # 대용량 텍스트 또는 바이너리 데이터를 오브젝트 스토리지로 이동합니다 데이터베이스에는 메타데이터만 저장합니다 검색 전용 데이터에는 Elasticsearch 를 사용합니다