좋음. rowid 테이블에서 정수 키가 단조 증가가 아니라 무작위일 때의 수치도 보면 흥미로울 듯함
글에서 빠진 중요한 점은 rowid 테이블의 기본 인덱스는 B+트리이고, without rowid 테이블은 B트리라는 점임
그래서 일반적으로 평균 레코드 크기가 어느 임계값을 넘으면 후자가 이상적이지 않음. 인덱스 내부 노드가 전체 레코드를 저장하기 때문이고, 기억하기로 SQLite 매뉴얼은 페이지 크기의 1/20을 경험칙으로 제시함

UUID 성능을 측정하는 데 그렇게 공을 들였는데 자연 키는 고려하지 않았음
정수든 UUID든 다른 형태든 대리 키는 복잡성을 더하고, 정보를 추가하지 않으며, 정규화 오류를 가림
글쓴이는 UUID를 쓰는 이유로 “중복 방지”를 들지만, 그건 이유가 아님. 모든 데이터베이스의 모든 테이블에서 모든 행은 그 행을 유일하게 식별하는 열 묶음인 키를 최소 하나 가져야 함
그런 키가 없는 데이터베이스는 중복 정보를 품고 논리적 불일치에 취약함. 그런 키가 이미 있는 데이터베이스에는 대리 키가 필요 없음. 자연 키가 이미 존재하고 강제되고 있다면 “성능 때문에 필요하다”는 주장은 추가 비용과 불필요한 복잡성을 뜻하므로 증명이 필요함

상상력이 부족한 걸 수도 있지만, 현실 세계에서 온 데이터를 다룰 때는 진짜 자연 키를 찾기가 대체로 어렵다 봄
겉보기엔 유일해 보이는 값이 기대만큼 유일하지 않거나, 불변이라고 예상한 값이 결국 바뀌어야 하는 일이 생김
반면 대리 키를 쓰면 다른 사람이 식별성을 어떻게 정의했는지, 혹은 보통 제대로 정의하지 않았는지에 기대지 않고 내 시스템 안에서 정체성을 정의할 수 있음
예외는 있음. 전체 모델을 내가 정의하고, 데이터가 이른바 현실 세계에서 오지 않는다면 자연 키가 더 말이 됨. 하지만 완전히 정규화된 적이 없을 법한 현실 데이터를 담는 스키마를 설계할 때는 대리 키가 유용한 경우가 많음

단조 증가하는 정수 대리 키에는 즉각적인 실용성이 꽤 있음
어떤 행이든 정수로 참조할 수 있어 접근이 크게 단순해지고, 사람이 기억하고 쿼리에 쓰기에도 쉬움
단조 증가한다면 그 자체로 정보도 담고 있음. 중복 정보이긴 하지만 사실임
조회 속도도 최적화됨. B트리, 비트맵 등으로 인덱싱하기에 최적에 가까운 경우임
사람들이 UUID를 주로 쓰는 건 대체로 혼란 때문이라고 봄. 보통 키를 난독화하고 추측 불가능하게 만들자는 논리인데, 왜 그 목적을 위한 별도 식별자가 아니라 기본 키에까지 강요해야 한다고 생각하는지는 이해를 포기했음

“중복 방지”라는 표현은 블로그 글에 나오지 않음. 사실 글에서는 UUID를 왜 쓰는지 자체를 전혀 말하지 않았음

UUID 버전 7은 앞부분에 48비트 타임스탬프가 있어서 이런 식으로 무작위 분포가 되지 않음. 그래서 과도한 페이징과 재균형도 줄어들 것임

맞음. 글에서 다루는 게 UUID7임

사람들이 정말 UUID를 기본 키로 쓰고 있나? UUID가 필요할 때 보조 키로 두는 대신 그렇게 하는 이점이 뭔지 궁금함

규모 확장 때문임. 많은 컴퓨터와 전 세계 여러 데이터센터에서 높은 속도로, 예를 들어 S3 업로드처럼 유일 ID를 분산 생성하려면 단일 증가 정수에 잠금을 걸고 싶지 않음. 잠금은 전 세계적으로 동기화하기 느림
GUID와 UUID는 구조적으로 이 문제를 해결함
v1과 v6은 기계 ID와 타임스탬프를 인코딩하므로, 각 기계별 이름공간을 가진 자동 증가 정수에 가까움
많은 사람이 UUID가 무작위라고 가정하는 데서 혼란이 생김. 그건 v4에만 해당하고, v4 선택에는 불행히도 비용이 있음
데이터를 정리해 주거나 성능·충돌 보장을 위해 v3, v5, v7처럼 어느 정도의 결정성이 필요한 때가 많음

무작위 UUID나 균등 분포의 임의 값을 보조 키에 두더라도 삽입은 여전히 느려짐. 클러스터드 인덱스는 아니어도 그 인덱스의 B트리에는 여전히 무작위 삽입이 일어나기 때문임