This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
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를 포함해도 이러한 링크들이 더 이상 작동하지 않게됨을 의미하며, 고유 제약 조건이 복합 키를 기반으로 수정될 것이기에 외래 키 참조를 모두 복합 키를 기반으로 업데이트해야 할 것입니다.

4. 평가

4.1. 장점

4.2. 단점