샤딩 가이드라인

GitLab 데이터베이스 테이블을 Organization에 연결하는 샤딩 키 설계 원칙, 구현 절차, 크로스 스키마 참조 규칙을 설명합니다.

샤딩 이니셔티브는 대부분의 GitLab 데이터베이스 테이블이 직접 또는 간접적으로 Organization 에 연결될 수 있도록 보장하는 장기 프로젝트입니다. 이 작업에는 테이블에 organization_id , namespace_id 또는 project_id 칼럼을 추가하고, NOT NULL 폴백 데이터를 백필(backfill)하는 것이 포함됩니다. 이 작업은 Cells와 Organizations 제공을 위해 중요합니다. 자세한 내용은 Organizations의 설계 목표 를 참조하세요. 샤딩 원칙 # 다음 gitlab_schema 를 가진 모든 테이블은 organization 레벨로 간주됩니다: gitlab_main_org gitlab_ci gitlab_sec gitlab_main_user 새로 생성된 organization 레벨 테이블은 모두 해당 테이블의 db/docs/ 파일에 sharding_key 가 정의되어 있어야 합니다. 샤딩 키의 목적은 Organization isolation blueprint 에 문서화되어 있지만, 간략히 말하면 이 칼럼은 데이터베이스의 특정 행이 어느 Organization에 속하는지 표준적인 방법으로 결정하는 데 사용됩니다. 올바른 샤딩 키 선택 # 모든 행은 정확히 1개의 샤딩 키를 가져야 하며, 가능한 한 구체적이어야 합니다. 대형 테이블에서는 예외를 둘 수 없습니다. 외래 키의 실제 이름은 무엇이든 될 수 있지만 projects 또는 namespaces 의 행을 참조해야 합니다. 다음은 유효한 샤딩 키의 예시입니다: 테이블 항목이 특정 프로젝트에만 속하는 경우: sharding_key: project_id: projects 테이블 항목이 프로젝트에 속하고 외래 키가 target_project_id 인 경우: sharding_key: target_project_id: projects 테이블 항목이 네임스페이스/그룹에만 속하는 경우: sharding_key: namespace_id: namespaces 테이블 항목이 네임스페이스/그룹에만 속하고 외래 키가 group_id 인 경우: sharding_key: group_id: namespaces ( gitlab_main_user 에만 해당) 테이블 항목이 사용자에만 속하는 경우: sharding_key: user_id: users 샤딩 키는 null이 아니어야 합니다 # 선택한 sharding_key 는 null이 아니어야 합니다. 각 행을 organization에 일관되게 귀속시킬 수 있어야 하며, organization을 다른 cell로 마이그레이션한 후에도 데이터를 잃지 않아야 합니다. 또한 Org Mover를 위한 행 필터링을 설정하려면 샤딩 키 칼럼을 포함하는 REPLICA IDENTITY 가 필요합니다. 이 REPLICA IDENTITY 는 null이 아닌 칼럼만 포함해야 합니다. 복수 샤딩 키 칼럼 # 테이블이 여러 다른 부모 엔티티(예: 프로젝트와 네임스페이스 모두)에 속할 수 있는 드문 경우에는 sharding_key 를 여러 칼럼으로