| 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
증가하는 시퀀스 대신 데이터베이스에 저장된 UUID(128비트)를 사용합니다.
- 기존 ID를 깨뜨릴 수 있으며 모든 기존 테이블에 UUID 열을 추가해야 합니다.
- 이로 인해 모든 인덱스가 증가하며, 인덱스에 32/64비트 대신 128비트를 저장해야 합니다.
3.2. ID에 인코딩된 Cell 인덱스 사용
상당수의 테이블이 이미 64비트 ID 번호를 사용하고 있기 때문에 MSB를 사용하여 Cell ID를 인코딩할 수 있습니다.
- 시스템에 활성화할 수 있는 Cell 번호를 1024개로 제한할 수 있기 때문에 이는 시스템에서 활성화될 수 있는 Cell의 양을 제한할 수 있습니다.
- 이렇게 하면 Cell 1의 엔티티가 Cell 100으로 이동되더라도 이 ID는 여전히 고유할 것입니다.
- 리소스가 이동되면 ID 자체만으로 Cell 번호를 해독할 수 없으며, 우리는 참조 테이블이 필요할 것입니다.
- 모든 ID를 32비트로 업데이트해야 합니다.
3.3. 중앙 위치에서 일련의 범위 할당
각 Cell은 중앙에서 관리하는 위치로부터 소비되는 일련의 시퀀스를 받을 수 있습니다. 한 Cell이 주어진 테이블에 할당된 모든 ID를 소비하면 보충될 것이며, 다음 범위가 할당될 것입니다. 범위는 빠른 참조 테이블을 제공하기 위해 추적되어야 할 것입니다.
- 엔티티가 Cell 1에서 Cell 100으로 이동하더라도 이 ID는 여전히 고유하기 때문에 Cell 간에 ID를 이동할 수 있을 수 있습니다.
- 리소스가 이동되면 ID 자체만으로 Cell 번호를 해독할 수 없으며, 이전에 할당된 시퀀스 범위를 깨뜨릴 수 있기 때문에 이를 더 견고하게 추적하는 참조 테이블이 필요할 것입니다.
- 모든 ID를 64비트로 업데이트할 필요가 없습니다.
- Postgres의 모든
INSERT문 또는 적어도 Rails로부터 모든INSERT문에 성능 페널티가 추가될 것입니다. 이는 시퀀스 번호를 확인하고 범위가 ID 서버에서 새로 고쳐지길 기다리는 상황이기 때문입니다. - 사용 가능한 범위는 동시 트랜잭션이 동일한 값이 될 수 없도록 중앙 위치에 저장 및 증가시켜야 할 것입니다.
3.4. 고유 ID 필요로 하는 테이블만 정의
일부 테이블만 전역 고유 ID를 가지고 있는 것이 허용되는지도 모릅니다. 프로젝트, 그룹 및 기타 최상위 엔티티가 될 수 있습니다.
merge_requests와 같은 모든 다른 테이블은 Cell 지역 ID만 제공할 수 있지만 외부에서 참조될 때는 프로젝트와 같은 I(ID), 리소스의 context에서 단조롭게 증가하는 ID를 사용할 수 있습니다.
- Cell들 사이에서 ID 10000이 모두 사용될 수 있으므로 때로는 리소스의 고유성과 관련해서 혼란스러울 수 있습니다.
- 이것은 ID에 기반한 임의 액세스를 (필요한 경우) 사용하려면
project_id+merge_request_id와 같은 복합 키를 사용하지 않으면 불가능하게 할 수 있습니다. - Cell간에 레코드를 이동해야 할 필요가 있을 경우 ID가 바뀌게 하려면 새로운 ID의 변환/생성을 구현해야 할 것입니다. 이 경우 이들 ID가 다른 레코드의 외래 키로 사용될 때 매우 어려운 마이그레이션 과정으로 이어질 수 있습니다.
- Cell들 간에 이동할 때 ID가 변경되어야 한다면, 이 링크들이
project_id를 포함하더라도 이 링크들이 더 이상 작동하지 않을 것입니다. - 만약 이들 ID가 고유하지 않도록 허용하고 고유 제약을 복합 키에 기반하도록 변경할 계획이라면 외래 키 참조를 모두 복합 키에 기반하도록 업데이트해야 할 것입니다.