| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
이 문서는 진행 중인 작업이며 Cells 디자인의 매우 초기 상태를 나타냅니다. 중요한 측면들이 문서화되지 않았지만, 향후 추가할 것으로 예상됩니다. 이것은 Cells를 위한 하나의 가능한 아키텍처이며, 우리는 구현할 접근 방법을 결정하기 전에 대안과 대조할 계획입니다. 이 문서는 우리가 이 접근 방법을 선택하지 않기로 결정해도 그 이유를 문서화할 수 있도록 유지될 것입니다.
Cells: 데이터베이스 시퀀스
현재 GitLab은 각 데이터베이스 행이 고유 ID를 가지도록하여 알려진 글로벌 ID로 병합 요청, CI 작업 또는 프로젝트에 액세스할 수 있도록 보장합니다. Cells는 많은 별개이며 연결되지 않은 데이터베이스를 사용하며, 대부분의 엔터티에 대해 별도의 ID를 갖습니다. 셀과 공유 스키마 사이에서 언급되는 모든 ID는 클러스터 전체에서 고유해야 모호한 참조를 피하기 위해 필요합니다. 필요한 글로벌 ID에 추가로, 앞으로 셀 간에 리소스를 이관할 수 있도록 모든 데이터베이스 행에 대해 전역적으로 고유한 ID를 유지하는 것도 바람직할 수 있습니다.
1. 정의
2. 데이터 흐름
3. 제안
이것은 시스템 전체에서 고유한 ID를 유지할 수 있는 몇 가지 초기 아이디어입니다.
3.1. UUID
증가하는 시퀀스 대신 데이터베이스에 저장되는 128bit UUID를 사용합니다.
- 이로 인해 기존 ID가 손상될 수 있고 모든 기존 테이블에 UUID 열을 추가해야 합니다.
- 인덱스가 모두 128bit를 저장해야 하기 때문에 모든 인덱스가 더 커집니다.
3.2. ID에 인코딩된 셀 인덱스 사용
64bit ID 번호를 이미 사용하는 테이블이 상당수이므로 MSB를 사용하여 셀 ID를 인코딩할 수 있습니다.
- 이로 인해 시스템에 활성화될 수 있는 셀의 수가 제한될 수 있습니다. 셀 번호를 1024개로만 할당하기로 결정할 수 있습니다.
- 이는 셀 간에 ID를 이관할 수 있도록 만들어주므로, Cell 1의 엔터티가 Cell 100으로 이관되더라도 해당 ID는 여전히 고유합니다.
- 리소스가 이관되면 ID 자체만으로는 셀 번호를 해독하는 데 충분하지 않으며, 우리는 조회 테이블이 필요합니다.
- 모든 ID를 32bit로 업데이트해야 합니다.
3.3. 중앙 위치에서 일련의 범위 할당
각 셀은 중앙에서 관리되는 곳에서 사용되는대로 시퀀스 범위를 받을 수 있습니다. 한 셀이 주어진 테이블에 대해 할당된 모든 ID를 소모하면 보충될 것이고 다음 범위가 할당될 것입니다. 범위는 임의 접근 패턴이 필요한 경우 빠른 조회 테이블을 제공하기 위해 추적될 것입니다.
- Cell 간에 ID를 이관할 수 있게 해주는데, Cell 1의 엔터티가 Cell 100으로 이관되더라도 해당 ID는 여전히 고유합니다.
- 리소스가 이관되면 ID 자체만으로 셀 번호를 해독하는 데 충분하지 않으며, 이전에 할당된 시퀀스 범위를 깨뜨릴 수 있으므로 훨씬 견고한 조회 테이블이 필요합니다.
- 모든 ID를 64bit로 업데이트할 필요가 없습니다.
- 이는 Postgres에서 모든
INSERT문에 성능 페널티를 추가하거나 적어도 Rails에서는 성능 페널티를 추가하는데, ID 서버에서 일련 번호를 확인하고 범위가 새로 고칠 때까지 기다려야 하기 때문입니다. - 사용 가능한 범위는 중앙에 저장 및 증가되어야 하므로 동시 트랜잭션이 동일한 값을 가져갈 수 없도록 해야 합니다.
3.4. 고유한 ID가 필요한 테이블만 정의
어떤 테이블에 대해 전역적으로 고유한 ID만 있어도 상관할 수 있습니다. 프로젝트, 그룹 및 기타 최상위 엔터티들에 대해서만 허용될 수 있습니다. 병합 요청과 같은 모든 다른 테이블은 셀 지역 ID만 제공할 수 있지만 외부에서 참조될 때는 프로젝트 ID와 병합 요청 ID와 같이 IID(특정 리소스의 맥락에서 단조롭게 증가하는 ID)를 사용할 수 있습니다.
- ID 10000이 모든 Cells에 존재하게 될 것이므로, 때로는 리소스의 고유성에 대해 혼란스러울 수 있습니다.
- ID로 무작위로 액세스하는 것(필요한 경우)이 복잡한 키(composite key)를 사용하지 않는 한 불가능할 수 있습니다. 예:
project_id+merge_request_id. - 리코스를 다른 Cell로 이관해야 하는 경우 새로운 ID의 변환/생성을 구현해야 하며, 이는 이동 중인 기록들의 외래 키로 사용되었을 때 매우 어려운 마이그레이션 프로세스로 이어질 수 있습니다.
- Cell이 변경될 때 ID가 변경되어야 한다면, 해당 링크는 프로젝트 ID를 포함하더라도 더 이상 작동하지 않을 것입니다.
- 이러한 ID가 고유하지 않도록 허용하고 고유한 제약 조건을 복합 키를 기반으로 변경하는 것을 계획한다면 외래 키 참조를 모두 복합 키를 기반으로 업데이트해야 합니다.