기본 키로 UUID 또는 GUID를 사용하는 경우의 단점은 무엇입니까?

분산 시스템을 구축하고 싶습니다. 데이터베이스에 데이터를 저장해야하며 UUID 또는 GUID 를 일부 테이블의 기본 키로 사용하면 도움이됩니다 . UUID / GUID가 상당히 크고 거의 임의이기 때문에이 디자인의 단점이라고 생각합니다. 대안은 자동 증분 INT 또는 LONG을 사용하는 것입니다.

내 테이블의 기본 키로 UUID 또는 GUID를 사용하는 데 따른 단점은 무엇입니까?

아마도 Derby / JavaDB (클라이언트)와 PostgreSQL (서버)을 DBMS로 사용할 것입니다.

최종 테이블의 생성 함수 및 크기에 따라 다릅니다.

GUID는 전역 적으로 고유 한 식별자로 사용됩니다. Postgres 8.3 설명서 에서 논의한 것처럼 이러한 식별자를 생성하는 데 보편적으로 적합한 방법론은 없지만 postgreSQL에는 몇 가지 유용한 후보가 제공됩니다.

문제의 범위와 오프라인 쓰기 의 필요성 에서 GUID 이외의 것을 사용하여 깔끔하게 상자를 만들었으므로 다른 체계의 보상 이점이 없습니다.

기능적인 관점에서 키 길이는 일반적으로 테이블 수에 따라 읽기 수와 크기에 따라 모든 종류의 최신 시스템에서 문제가되지 않습니다. 대안 방법으로 오프라인 클라이언트 는 기본 키 없이 새 레코드 를 일괄 처리 하고 다시 연결할 때 간단히 레코드 를 삽입 할 수 있습니다. postgreSQL은 "Serial"데이터 유형을 제공하므로 클라이언트는 데이터베이스에 간단한 쓰기를 수행 할 수있는 경우 ID를 결정할 필요가 없습니다.

한 가지 더 조언-GUID를 클러스터형 인덱스의 일부로 사용하지 마십시오. GUID는 순차적이지 않으므로 클러스터 된 인덱스의 일부인 경우 새 레코드를 삽입 할 때마다 int (bigint) 자동 증가의 경우 데이터베이스가 모든 메모리 페이지를 재정렬하여 삽입 할 적절한 위치를 찾아야합니다. 마지막 페이지 일 것입니다.

이제 DB 구현을 살펴보면 다음과 같습니다. 1.) MySQL-기본 키가 클러스터링되며 동작을 변경할 수있는 옵션이 없습니다. 권장 사항은 GUID를 전혀 사용하지 않는 것입니다. 2.) Postgres, MS-SQL-GUID를 다음과 같이 만들 수 있습니다. 기본 키가 클러스터되지 않은 상태에서 다른 필드를 클러스터 된 인덱스로 사용하십시오 (예 : autoincrement int).

따라 다릅니다.

진지하게, 당신이 지금까지했던 모든 것에 대해, 이것은 당신이 갈 수있는 한도입니다.

UUID를 사용하는 것이 왜 도움이됩니까? 왜 INT를 사용하지 않습니까? 나중에 UUID를 색인 할 수없는 이유는 무엇입니까? UUID 키를 사용하여 정렬 된 목록을 갖고 몇 백만 행 뒤에 임의의 (순차적이지 않은) UUID를 삽입하는 것이 무엇을 의미하는지 알고 있습니까?

어떤 플랫폼에서 실행됩니까? 디스크는 몇 개입니까? 얼마나 많은 사용자? 몇 개의 기록이 있습니까?