Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
proposed | - |
이 문서는 작업 중인 것으로, Cells 디자인의 매우 초기 상태를 대표합니다. 중요한 측면 중 일부는 문서화되지 않았지만, 향후 추가할 예정입니다. 이는 Cells를 위한 하나의 가능한 아키텍처이며, 우리는 구현할 방법을 결정하기 전에 대안과 대조할 것을 의도하고 있습니다. 이 접근 방식을 선택하지 않기로 결정하더라도 이 문서는 유지될 것이며, 이를 통해 이러한 방식을 선택하지 않은 이유를 문서화할 수 있습니다.
Cells: Database Sequences
GitLab은 오늘날 각 데이터베이스 행 생성 시 고유 ID가 있어 알려진 전역 ID로 Merge Request, CI 작업 또는 프로젝트에 액세스할 수 있도록 보장합니다. Cells는 많은 별개이며 서로 연결되지 않은 데이터베이스를 사용할 것이며, 대부분의 엔티티에 대해 별도의 ID를 갖게 될 것입니다. 적어도 Cell과 공유 스키마 간에 참조된 모든 ID는 모호한 참조를 피하기 위해 클러스터 전체에서 고유해야 할 것입니다. 필요한 전역 ID에 추가로, 앞으로 Cells 간에 리소스를 이동할 수 있도록 모든 데이터베이스 행에 대해 전역적으로 고유한 ID를 유지하는 것도 바람직할 수 있습니다.
1. 정의
2. 데이터 흐름
3. 제안
시스템 전체에서 고유한 ID를 유지하는 몇 가지 초기 아이디어입니다.
3.1. UUID
증가하는 시퀀스 대신 데이터베이스에 저장된 128비트 UUID를 사용합니다.
- 기존 ID를 손상시킬 수 있으며, 모든 기존 테이블에 UUID 열을 추가해야 합니다.
- 이로 인해 모든 색인이 증가하여 색인에 32/64비트가 아닌 128비트를 저장해야 합니다.
3.2. ID로 셀 인덱스 사용
상당수 테이블이 이미 64비트 ID 번호를 사용하고 있기 때문에 MSB를 사용하여 셀 ID를 인코딩할 수 있습니다.
- 이는 시스템에 활성화될 수 있는 셀의 양을 제한할 수 있으므로 결정 사항으로 1024개의 가능한 셀 번호만 할당하기로 결정할 수 있습니다.
- 이를 통해 셀 간에 ID를 마이그레이션하는 것이 가능해집니다. 따라서 셀 1의 엔터티가 셀 100으로 이동하더라도 해당 ID는 여전히 고유할 것입니다.
- 리소스가 마이그레이션되면 ID 자체만으로 셀 번호를 디코딩하기에는 충분하지 않으며, 룩업 테이블이 필요할 것입니다.
- 모든 ID를 32비트로 업데이트해야 합니다.
3.3. 중앙 위치에서 일련의 범위 할당
중앙에서 관리되는 위치에서 각 셀은 소비되는 대로 일련의 시퀀스를 받을 수 있습니다. 한 셀이 주어진 테이블에 할당된 모든 ID를 사용하면 보충되며, 다음 범위가 할당될 것입니다. 범위는 필요한 경우 빠른 룩업 테이블을 제공하기 위해 추적될 것입니다.
- 셀 간에 ID가 이동할 수 있도록 할 수 있습니다. 따라서 셀 1의 엔터티가 셀 100으로 이동하더라도 해당 ID는 여전히 고유할 것입니다.
- 리소스가 마이그레이션되면 ID 자체만으로 셀 번호를 디코딩하기에는 충분하지 않으며, 이전에 할당된 일련의 범위를 파괴할 수 있기 때문에 훨씬 더 견고한 룩업 테이블이 필요할 것입니다.
- 모든 ID를 64비트로 업데이트할 필요는 없습니다.
- 이는 PostgreSQL의 모든
INSERT
문에 일부 성능 상의 페널티를 부여하거나 적어도 Rails에서 그래프의 경우에는 ID 서버로부터의 범위 갱신을 기다려야 할 수 있기 때문에 성능에 약간의 페널티를 추가합니다. - 사용 가능한 범위는 동시 트랜잭션이 동일한 값을 얻을 수 없도록 중앙 위치에 저장하고 증가시켜야 할 것입니다.
3.4. 고유한 ID가 필요한 일부 테이블만 정의
일부 테이블에만 전역 고유 ID가 있어도 괜찮을 수 있습니다. 프로젝트, 그룹 및 기타 최상위 엔터티일 수 있습니다.
merge_requests
같은 모든 기타 테이블은 셀 로컬 ID만 제공하며, 외부에서 참조될 때는 프로젝트 ID와 함께 IID(특정 리소스의 컨텍스트에서 단조롭게 증가하는 ID)를 사용하는 경우도 있습니다.
- 이로 인해
merge_requests
의 ID 10000은 모든 Cells에 존재하게 되므로, 때로는 리소스의 고유성에 대해 혼란스러울 수 있습니다. - 이것은 ID에 의한 무작위 액세스가
project_id+merge_request_id
와 같은 복합 키를 사용하지 않는 이상 어렵게 만들 수 있습니다. - 이것은 다른 셀로 레코드를 마이그레이션해야 하는 경우 새로운 ID의 변환/생성을 구현해야 하므로, 이러한 ID는 이동되는 다른 레코드의 외부 키로 사용되는 경우 매우 어려운 마이그레이션 프로세스로 이어질 수 있습니다.
- 셀 간 이동할 경우 ID가 변경되어야 한다면, 이는
project_id
를 포함해도 이러한 링크들이 더 이상 작동하지 않게됨을 의미하며, 고유 제약 조건이 복합 키를 기반으로 수정될 것이기에 외래 키 참조를 모두 복합 키를 기반으로 업데이트해야 할 것입니다.