GUID/UUID 데이터베이스 키의 장단점

GUID/UUID 데이터베이스 키의 장단점

저는 과거에 여러 데이터베이스 시스템을 작업해 보았는데, 모든 데이터베이스 키가 GUID/UUID 값이었다면 데이터베이스 간 항목 이동이 훨씬 용이했을 것입니다.몇 번이나 이 길을 가는 것을 고려해 보았지만, 특히 성능과 전화로 읽을 수 없는 URL과 관련하여 항상 약간의 불확실성이 있습니다.

데이터베이스에서 GUID와 광범위하게 작업한 사람이 있습니까?그런 식으로 하면 어떤 이점을 얻을 수 있고, 어떤 함정이 생길 수 있습니까?

장점:

• 오프라인으로 생성할 수 있습니다.
• 복제를 사소한 것으로 만듭니다(int의 것과 달리 실제로는 어려워짐).
• ORM은 보통 그들을 좋아합니다.
• 애플리케이션 간에 고유합니다.따라서 앱(가이드)에서 CMS(가이드)의 PK를 사용할 수 있으며 절대 충돌이 발생하지 않을 것임을 알 수 있습니다.

단점:

• 공간 사용은 커지지만 공간은 저렴합니다(er)
• ID로 주문하여 삽입 주문을 받을 수 없습니다.
• URL에서 보기 흉할 수 있지만, 정말로 WTF는 URL에 REAL DB 키를 넣는 것입니까!? (아래 댓글에서 논란이 된 점)
• 수동 디버깅을 하기는 어렵지만 그렇게 어렵지는 않습니다.

개인적으로, 저는 그것들을 적당한 크기의 시스템에서 대부분의 PK에 사용하지만, 저는 곳곳에 복제된 시스템에 대해 "교육"을 받았기 때문에, 우리는 그것들을 가질 수 밖에 없었습니다.YMMV.

중복 데이터는 쓰레기라고 생각합니다. 아무리 해도 중복 데이터를 얻을 수 있습니다.대리 키는 보통 제가 어디서 일하던 간에 눈살을 찌푸립니다.WordPress와 유사한 시스템을 사용합니다.

• 행에 대한 고유 ID(GUID/아무것이나).사용자가 볼 수 없습니다.
• 공용 ID는 특정 필드에서 한 번 생성됩니다(예: 제목 - 기사 제목으로 만들기).

업데이트: 이 제품은 +1'을 많이 사용하므로 GUID PK: Clustered Index의 큰 단점을 지적해야겠다고 생각했습니다.

많은 레코드가 있고 GUID에 클러스터된 인덱스가 있는 경우 삽입 성능이 SUCK됩니다. 항목 목록의 마지막(즉, 빠른) 위치가 아니라 임의의 위치에 삽입되기 때문입니다.

따라서 삽입 성능이 필요한 경우 auto-inc INT를 사용하고 다른 사용자와 공유하려면 GUID를 생성합니다(예: URL로 사용자에게 표시).

왜 아무도 성능에 대해 언급하지 않습니까?여러 명의 가입자가 있을 때, 이 고약한 GUID를 기반으로 성능이 바닥을 통과하게 됩니다 :(

@맷 셰퍼드:

고객 테이블이 있다고 가정해 보겠습니다.물론 고객이 테이블에 한 번 이상 있는 것을 원치 않으실 것입니다. 그렇지 않으면 영업 및 물류 부서 전체에서 많은 혼란이 발생할 것입니다(특히 고객에 대한 여러 행에 서로 다른 정보가 포함되어 있는 경우).

따라서 고객을 고유하게 식별하는 고객 식별자가 있으며, 고객이 이 식별자를 알고 있는지(송장에) 확인하여 고객과 고객 서비스 담당자가 의사소통이 필요한 경우에 대해 공통된 참조사항을 갖게 됩니다.중복된 고객 기록이 없도록 하려면 고객 식별자의 기본 키를 사용하거나 고객 식별자 열에 NOT NULL + UNIULI 제약 조건을 사용하여 고유성 제약 조건을 테이블에 추가합니다.

다음으로, 어떤 이유로 (생각할 수 없는) 고객 테이블에 GUID 열을 추가하고 기본 키로 만들어야 합니다.고객 ID 열이 고유성 보장 없이 남아 있다면 GUID는 항상 고유하기 때문에 향후 조직 전반에 걸쳐 문제가 발생할 것을 요구하는 것입니다.

어떤 "건축가"가 "오, 하지만 우리는 우리의 앱 계층에서 진정한 고객 고유성 제약을 다루고 있습니다!"라고 말할지도 모릅니다.맞다.범용 프로그래밍 언어 및 (특히) 중간 계층 프레임워크와 관련된 패션은 항상 변하며 일반적으로 데이터베이스보다 오래가지 않습니다.그리고 어느 시점에서 현재 애플리케이션을 거치지 않고 데이터베이스에 액세스해야 할 가능성이 매우 높습니다.== 곤란합니다. (하지만 다행스럽게도, 당신과 "건축가"는 이미 떠났기 때문에, 당신은 그 지저분한 것들을 치우기 위해 그곳에 있지 않을 것입니다.)즉, 데이터베이스에 명백한 제약 조건(시간이 있는 경우 다른 계층에서도)을 유지합니다.

즉,테이블에 GUID 열을 추가해야 하는 데는 좋은 이유가 있겠지만, 실제(==비GUID) 정보 내에서 일관성에 대한 야망을 낮추려는 유혹에 빠지지 마십시오.

데이터베이스에 연결하지 않고도 고유 ID를 만들 수 있다는 것이 주요 장점입니다.ID는 전 세계적으로 고유하므로 서로 다른 데이터베이스의 데이터를 쉽게 결합할 수 있습니다.이것들은 작은 장점처럼 보이지만 과거에 저는 많은 일을 절약했습니다.

주된 단점은 스토리지가 조금 더 필요하다는 것입니다(현대 시스템에서는 문제가 되지 않습니다). ID는 실제로 사람이 읽을 수 있는 것이 아닙니다.디버깅할 때 이 문제가 발생할 수 있습니다.

인덱스 조각화와 같은 성능 문제가 있습니다.하지만 그것들은 쉽게 해결할 수 있습니다. (지미 닐슨의 콤비 가이드: http://www.informit.com/articles/article.aspx?p=25862 )

편집은 이 질문에 대한 나의 두 답변을 병합했습니다.

@Matt Sheppard 다른 GUID를 기본 키로 사용하여 행을 복제할 수 있다는 뜻인 것 같습니다.이것은 GUID뿐만 아니라 어떤 종류의 대리키와도 관련된 문제입니다. 그리고 그가 말했듯이 키가 아닌 열에 의미 있는 고유 제약 조건을 추가하면 쉽게 해결됩니다.그 대안은 자연 키를 사용하는 것이고 그것들은 진짜 문제가 있습니다.

GUID를 "단순화자"로 사용하여 중복된 데이터를 테이블로 가져올 경우 향후 많은 문제가 발생할 수 있습니다.GUID를 사용하려면 다른 열에 UNIUIC-제약 조건을 유지하는 것을 고려하십시오.

이 열을 클러스터 인덱스(비교적 일반적인 방법)로 사용하는 경우 GUIDS를 기본 키로 사용할 때 고려해야 할 또 다른 작은 문제가 있습니다.guid의 특성상 순차적으로 시작하지 않기 때문에 삽입할 때 적중하므로 삽입할 때 페이지 분할 등이 발생합니다.시스템에 높은 IO가 적용될 경우 고려해야 할 사항입니다.

기본 키-ids- versus-가이드

기본 키로서의 GUID 비용(SQL Server 2000)

신화, GUID vs. 자동 증가(MySQL 5)

이것이 당신이 원하는 것입니다.

UUID 프로

• 모든 테이블, 모든 데이터베이스, 모든 서버에서 고유
• 여러 데이터베이스의 레코드를 쉽게 병합할 수 있습니다.
• 여러 서버에 걸쳐 데이터베이스를 쉽게 배포할 수 있습니다.
• 데이터베이스에 왕복할 필요 없이 어디서나 ID를 생성할 수 있습니다.
• 대부분의 복제 시나리오에서는 어쨌든 GUID 열이 필요합니다.

GUID 단점

• 기존의 4바이트 인덱스 값보다 무려 4배나 큰 값입니다. 이 값은 신중하지 않으면 성능과 스토리지에 심각한 영향을 미칠 수 있습니다.
• 디버깅하기 번거롭습니다(여기서 userid='{B).AE7DF4-DDF-3RG-5TY3E3RF456AS10}).
• 생성된 GUID는 최상의 성능(예: SQL 2005의 newsequentialid())과 클러스터 인덱스를 사용할 수 있도록 부분적으로 순차적이어야 함

실제로 해결되지 않은 한 가지가 있는데, 즉 랜덤(UUIDv4) ID를 기본 키로 사용하면 기본 키 인덱스의 성능이 저하됩니다.테이블이 키를 중심으로 군집화되든 그렇지 않든 간에 발생합니다.

RDBM은 대개 분기 인자가 큰 검색 트리(이진 검색 트리는 분기 인자가 2)인 BTree라는 구조에서 기본 키의 고유성을 보장하고 키별 검색을 보장합니다.순차적인 정수 ID를 사용하면 대부분의 리프 노드가 손상되지 않은 채로 트리의 한 면에만 삽입이 발생합니다.임의 UUID를 추가하면 삽입이 인덱스 전체에서 리프 노드를 분할하게 됩니다.

마찬가지로, 저장된 데이터가 대부분 시간적인 것이라면, 대부분의 데이터에 액세스하여 결합해야 하는 경우가 많습니다.랜덤 UUID를 사용하면 패턴은 이점을 얻지 못하고 더 많은 인덱스 행을 칠 수 있으므로 메모리에 더 많은 인덱스 페이지가 필요합니다.가장 최근의 데이터가 필요한 경우 순차 ID를 사용하면 핫 인덱스 페이지는 RAM이 덜 필요합니다.

장점:

• UUID 값은 테이블과 데이터베이스 간에 고유합니다.그렇기 때문에 두 데이터베이스 또는 분산 데이터베이스 간 행 병합이 가능합니다.
• UUID는 정수형 데이터보다 URL을 통과하는 것이 더 안전합니다.UUID 하나가 url을 통과하면 공격자는 다음 ID를 추측할 수 없습니다.그러나 만약 우리가 10과 같은 Integer 타입을 통과한다면, 공격자들은 다음 ID를 11, 12 등으로 추측할 수 있습니다.
• UUID는 오프라인에서 생성할 수 있습니다.

지금까지 언급하지 않은 한 가지: UUID는 데이터 프로파일링을 훨씬 더 어렵게 만듭니다.

웹 url ID 입니다와가 있는 입니다.stackoverflow.com/questions/45399이면 둘 다 ID가 정수이면 둘 다

• 질문 수에 대한 정보를 제공합니다. (즉, 2008년 9월 5일 45,399번째 질문을 받았습니다.)
• 질문을 통해 반복할 수 있는 레버리지 포인트를 제공합니다(1씩 증가하면 어떻게 됩니까?다음 질문을 엽니다.)

첫 번째 시점부터 질문의 타임스탬프와 숫자를 결합하여 질문의 빈도와 시간에 따라 어떻게 변하는지 프로파일링할 수 있습니다.이는 공개적으로 사용 가능한 정보가 있는 스택 오버플로와 같은 사이트에서는 덜 중요하지만 상황에 따라 민감한 정보가 노출될 수 있습니다.

예를 들어, 저는 고객에게 권한 게이트 포털을 제공하는 회사입니다.그 주소는portal.com/profile/{customerId}. ID가 정수인 경우, 고객 정보를 볼 수 있는지 여부에 관계없이 고객의 수를 조회할 수 있습니다.lastKnownCustomerCount + 1정기적으로, 그리고 결과가 다음과 같은지 확인합니다.404 - NotFound(고객이 존재하지 않음) 또는403 - Forbidden(고객이 존재하지만 보기에 대한 액세스 권한은 없습니다.)

순차적이지 않은 UUID는 이러한 문제를 완화합니다.이것은 프로파일링을 막기 위해 웅얼거리는 것이 아니라 시작입니다.

언급URL : https://stackoverflow.com/questions/45399/advantages-and-disadvantages-of-guid-uuid-database-keys