• DB auto_increment
• 유니크 문자열 또는 숫자
• 유니크 정렬 문자열
• 유니크 정렬 숫자

DB auto_increment

• 분산 데이터베이스 환경에서는 PK가 중복될 수 있기 때문에, 식별자의 유일성이 보장되지 않는다.

• 클라이언트 측에 노출하면 보안 문제
  user_id = 1000 라면 1,000명의 사용자가 있다는 사실을 유추

• 간단하기 때문에 다음 상황에서 유리할 수 있다.
  1.보안적인 문제를 크게 고려하지 않는 상황
  2.단일 DB를 사용하거나 애플리케이션에서 PK의 중복을 직접 구분하는 상황

• 보안 적인 문제가 염려된다면 PK는 데이터베이스 내에서의 식별자로만 사용하고, 애플리케이션에서의 식별자를 위해 별도 유니크 인덱스를 사용할 수도 있다.
  PK = id(DB auto_increment)
  unique index = article_id(UUID 등)
  Client는 article_id만 식별자로서 노출 및 사용

유니크 문자열 또는 숫자

• UUID 또는 난수를 생성하여 PK를 지정할 수 있다.
• 정렬 데이터가 아니라 랜덤 데이터를 삽입하는 것이다.
• 하지만, 랜덤 데이터로 인해 성능 저하가 발생할 수 있다.
  Clustered Index는 정렬된 상태를 유지한다.
  데이터 삽입 필요한 인덱스 페이지가 가득 찼다면, B+tree 재구성 및 페이지 분할로 디스크 I/O증가
  PK를 이용한 범위 조회가 필요하다면, 디스크에서 랜덤 I/O가 발생하기 때문에, 순차 I/O보다 성능 저하

유니크 정렬 문자열

• 분산 환경에 대한 PK 중복 문제 해결
• 보안 문제 해결
• 랜덤 데이터에 의한 성능 문제 해결
• UUID v7, ULID 등의 알고리즘
  일반적으로 알려진 알고리즘음 128비트를 사용한다.
• 데이터 크기에 따라 공간 및 성능 효율이 달라진다.
  Clustered Index는 PK를 기준으로 만들어지고, Secondary Index는 데이터에 접근할 수 있는 포인터를 가진다. 즉, PK를 가지고 있다.
  PK가 크면 클수록, 데이터는 더 많은 공간을 차지, 비교 연산에 의한 정렬/조회에 더 많은 비용 소모

유니크 정렬 숫자

• 분산 환경에 대한 PK 중복 문제 해결
• 보안 문제 해결
• 랜덤 데이터에 의한 성능 문제 해결
• Snowflake, TSID 등의 알고리즘
  64비트를 사용한다. (BIGINT)
  정렬을 위해 타임스탬프를 나타내는 비트 수의 제한으로, 키 생성을 위한 시간적인 한계가 있을 수있다. 문자열 알고리즘에서도 동일한 문제가 있으나 비트 수가 많을수록 제한이 덜할 수 있다.