Hacker News 의견

• B-tree 친화적인 기본 키로 bigserial을 사용하고, 외부 레코드 로케이터 옵션으로 문자열로 인코딩된 UUID를 고려할 것을 권장함

  • 비기술적인 사용자가 인용할 경우, PNR 스타일 로케이터와 같은 간단한 옵션을 먼저 고려할 것
  • 서비스나 애플리케이션의 스키마 내에서 PK 유형을 혼합하지 말 것
  • 고유 식별자로 UUIDv7을 사용할 때는 타임코드가 내재된 데이터에만 사용할 것
  • hashids를 사용하지 말 것; 암호화 품질이 없고 일상적인 사람들에게 친숙하지 않음
  • 인코딩 시 base64나 하이픈이 포함된 알파벳을 사용하지 말 것

• 데이터베이스 스키마 설계 시 관심사의 분리와 기계적 동조의 원칙을 염두에 둘 것

• Stripe의 타이핑된 랜덤 ID는 실제로 랜덤이 아님

  • 메타데이터, 포함된 타임스탬프, 샤드 및 참조 키, 버전 정보 등이 포함됨
  • 개인적으로 base58로 인코딩된 AES 암호화 bigserial+HMAC 로케이터를 선호함

• Postgres에서 랜덤 UUID는 큰 문제가 아님

  • UUID(16바이트)는 serial(4바이트)이나 bigserial(8바이트)보다 크지만, 전체 테이블 수준에서는 큰 문제가 아님

• Postgres에서 serial vs. random UUID vs. ordered UUID를 고려하기 전에 다른 많은 것들을 걱정해야 함

• 최근 Postgres PK로 ULID를 선택했으며, 이 기사에서 많은 도움을 받았음: https://brandur.org/nanoglyphs/026-ids

• ULID를 선호하는 이유는 UUID 유형과 호환되며, 타임스탬프가 내장되어 있어 ID로 정렬하면 타임스탬프 순으로 정렬됨

• 비교에 'int64'도 포함되면 UUID와 전통적인 접근 방식의 오버헤드를 비교할 수 있어 좋을 것임

• 삽입 성능은 성능을 평가하는 나쁜 방법임

  • B-Tree 성능은 삽입 시 더 좋지만, 대규모 트랜잭션에서는 어떨지 의문임

• SQLite에서 UUID4가 선호되는 이유는 트랜잭션 잠금 동안 페이지 캐시 충돌 가능성이 적기 때문임

  • Postgres 시스템에서도 비슷하게 적용될 수 있음

• 정수 자동 증가 기본 키를 선호함

  • 이해하기 쉽고 정렬하기 간단함
  • 대규모 배치 프로젝트에서 마지막 기본 키를 저장하고 그보다 큰 모든 것을 가져올 수 있음

• UUIDv7 삽입 시간 벤치마크는 UUID 생성 시간을 포함함

  • 단순히 인덱스 업데이트 비용을 분리해서 보고 싶음

• PostgreSQL 17에서 UUIDv7 지원이 포함될 가능성이 낮음

  • 최근 작업에서 커미터가 제거되었고, 버전 17은 이미 기능 동결 상태임

• python-ulid를 사용하기 시작했으며, ULID가 UUID보다 우수함

• UUID v7 표준 링크가 오래되었으므로, RFC 9562를 참조할 것: https://datatracker.ietf.org/doc/html/rfc9562