샤딩 가이드라인

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

샤딩 이니셔티브는 대부분의 GitLab 데이터베이스 테이블을 직접 또는 간접적으로 Organization 에 연결할 수 있도록 만드는 장기 프로젝트입니다. 이 작업에는 테이블에 organization_id , namespace_id , project_id 칼럼을 추가하고 NOT NULL 폴백 데이터를 백필하는 일이 포함됩니다. 이 작업은 Cells와 Organizations를 제공하는 데 중요합니다. 자세한 내용은 Organizations의 설계 목표 를 참고합니다. 샤딩 원칙 # 다음 gitlab_schema 를 가진 모든 테이블은 organization 레벨로 간주됩니다: gitlab_main_org gitlab_ci gitlab_sec gitlab_main_user gitlab_shared_org 그 외의 모든 테이블은 cell 로컬로 간주됩니다. cell 로컬 테이블의 데이터는 cell 사이에서 마이그레이션되지 않으므로 샤딩 키를 두면 안 됩니다. 새로 생성되는 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이 아닌 칼럼만