가장 효율적인 UUID 열 유형

15

128 비트 UUID를 저장하기 위해 여러 가지 저장 옵션이 있습니다.

바이트 [16] 열
두 개의 bigint / long (64 비트) 열
CHAR (36) 열-32 개의 16 진수 + 4 개의 대시.
db가 지원하는 경우 UUID 데이터베이스 특정 열

인덱싱 관점에서 가장 효율적인 것은 무엇입니까? db가 전용 uuid 유형을 지원하지 않는 경우 1, 2, 3 중 가장 적합한 후보는 무엇입니까?

— 블라드 미할 세아
소스

1

이것은 너무 "의존적이다"-많은 구현 세부 사항들.

— Craig Ringer

2

나는 절대로 3을 선택하지 않을 것입니다. 16에서 수행 할 수있을 때 절대 36 바이트로 저장하지 마십시오 . raw(16)Oracle과 uuidPostgreSQL에서 사용합니다.

— Colin 't Hart

1

간단할수록 좋습니다.

— akuzminsky

uuid>> bytea>> text와 CHECK제약> varchar(36)>> char(36). dba.stackexchange.com/a/89433/3684 및 dba.stackexchange.com/a/115316/3684를 참조하십시오 .

— Erwin Brandstetter

15

전용 uuid유형이 PostgreSQL에 가장 적합한 방법입니다. 다른 DB와 말하기 어렵습니다-누군가가 uuid단순한 바이트 유형보다 덜 효율적으로 저장된 유형 을 암시하는 것은 불가능하지 않습니다 .

다시 PostgreSQL bytea에서 uuid유형 이없는 경우 UUID를 저장하는 합리적인 방법 입니다. 다른 DB의 경우 바이너리 데이터를 저장하는 방법에 따라 다릅니다.

가능한 경우 대시를 사용하는 16 진수를 사용하지 않는 것이 좋습니다. 비교, 정렬 및 저장이 덜 효율적입니다.

실제로 "(2) 또는 (3)"이 아닙니다. 이제까지. 지원되는 경우 (4), 그렇지 않은 경우 (1)을 사용하십시오.

— 크레이그 링거
소스

한 가지 주목할 점은 PostgreSQL UUID 유형이 기본적으로 배열에서 지원되지 않거나이 문제가 해결 되었습니까? postgresql.org/message-id/…

— Christophe Roussy

@ChristopheRoussy 2013 년이되었습니다. 사소한 감독이었습니다. SELECT ARRAY['ef1e0638-072e-4caa-88b3-97bfa5b2e8c3']::uuid[]

— Craig Ringer

3

기본 설정 순서 : 4,1,2,3 SQL Server를 사용하는 경우 UUID를 클러스터링 키로 사용하지 마십시오. 클러스터링 키는 클러스터되지 않은 모든 인덱스에 사용되며 클러스터링 키는 모든 비 클러스터형 인덱스에 사용됩니다. 각 인덱스 행. NEWSEQUENTIALID를 사용하면 조각화를 완화 할 수 있지만 일반적으로 다른 인덱스의 팽창을 방지하기 위해 GUID보다 클러스터링 키에 대한 Bingint ID를 선호합니다.

1에서 2를 선택하는 것의 차이점은 단일 열 고정 배열에서 데이터베이스가 기본 유형의 두 열을 얼마나 효율적으로 처리하는지에 달려 있습니다. 더미 데이터로 테스트하기에 충분히 쉬워야합니다. 쿼리 속도와 인덱스 및 데이터 크기를 확인하십시오. 작고 빠른 것이 최고입니다!

— GilesDMiddleton
소스

1

기본적으로 지원되는 모든 데이터 유형이 해당 제품의 클라이언트로 구성 할 수있는 것보다 제품에서 더 잘 최적화 될 것이라고 가정해야합니다. 그 후, 바이트 수가 가장 작은 것은 페이지 당 최대 행 수를 얻습니다.

— 마이클 그린
소스

사실이지만 바이트 크기 만 중요한가요? 유형이 색인 알고리즘에 영향을 미치지 않습니까?

— Vlad Mihalcea

@ Vlad SQL Server를 사용합니다. AFAIK 모든 데이터 형식은 B- 트리 (또는 메모리 내 2104의 해시 인덱스)를 구성 할 때 동일하게 처리됩니다. 있습니다 이유 가능한 좁은으로 이것을 유지하기는.

— Michael Green