PK 를 UUID 로 지정하는건 안티 패턴 아닐까요?

Question

PK를 지정할 때 보통 숫자형의 auto_increment 를 사용하거나, 오라클의 경우 별도의 시퀀스 테이블 을 통해 관리하곤 합니다.그런데 자료를 찾다 보니 간혹 UUID를 PK로 지정하는 패턴이 종종 보입니다.개인적으로는 UUID를 PK로 사용하는 것이 인덱스 성능 관점에서 안티 패턴(Anti-pattern) 이 아닌가 생각합니다. 그 이유는 다음과 같습니다.첫째, MySQL(InnoDB)은 PK 지정 시 클러스터 인덱스가 자동 생성됩니다.인덱스 관리 측면에서 데이터의 중간 삽입, 삭제, 변경이 빈번한 컬럼은 PK로 지양해야 한다고 배웠습니다.둘째, MySQL은 B+Tree 형태로 인덱스를 관리합니다.auto_incrementㅠ는 순차적으로 값이 입력되므로 데이터 페이지(Page)가 가득 찰 경우 새로운 페이지를 생성하여 이어 쓰면 됩니다.하지만 UUID는 값이 랜덤하기 때문에, 입력 시마다 페이지 분할 과 인덱스 재정렬이 발생하게 됩니다.결과적으로 중간 삽입으로 인한 페이지 분할이 빈번해지면 성능 저하를 일으킬 수밖에 없으므로, UUID를 사용하는 패턴은 좋지 않아 보입니다.그럼에도 불구하고 UUID를 PK로 사용해야 하는 구체적인 상황이나 이유는 무엇인가요?

정규분포 · Accepted Answer

답변을 글로 올립니다. 도움 되시길.https://okky.kr/user/171142/articles/1548523

캐티 · Answer

UUID(Universally Unique Identifier) | 토스페이먼츠 개발자센터UUID - 나무위키이럼 nosql은 도큐먼트 아이디를 uuid로 하였는데 망한거 이나요.사실 유니크 아이디 제너레이터는 만들기 나름이어서 0 비트부터 순차적으로 기록하는 거로 바꺼보기도 하였어요.위에 거는 데이터베이스가 클러스터 상태이면 UUID 아님 대안을 멀로 하여야 하는지 모르겠쩌.솔 .. 멀티 패스로 아키이브를 구현하는 거이면 실시간 새로 생성하는 거는 UUID로 치고, 정리가 다된 거이면 BigInt PK로 다시 정리하여도 되겠쩌. DB단위에서 자동으로 해주는 경우는 없어서 프로그래머가 구현을 쳐야 하는데 결과적으로 자신있는 사람이 강한 거여요.

zepinos · Answer

주말 태블릿이라 짧게 적겠습니다.seq. 의 단점은 생성 주체가 dbms 로 한정되어지는 설계가 되기 쉽고 클러스터 구축에 좋지 않다는 것입니다.대안을 uuid v4 인가...도 요즘 잘 안쓰고 시간순서 지원하는 guid, uuid v7? 뭐 이런거 고민해서 씁니다.

코딩하는 두루미 · Answer

클러스터의 동시성 문제가 아닐까요 만약 DB 클러스터가 분산되어 여러개로 운영될때, key가 겹치는 경우가 생길 수 있을거예요 그렇기에 uuid로 unique한 key를 확보하는것으로 보입니다.

정규분포 · Answer

네. Incompetence죠. 어쩔 수 없음. 각자 비판적인 사고를 할 수 밖에.https://okky.kr/questions/1530744https://github.com/tvondra/sequential-uuidshttps://developer111.tistory.com/entry/uuid-%EC%83%9D%EC%84%B1-%EC%A0%84%EB%9E%B5-%EC%84%B1%EB%8A%A5%EC%B0%A8%EC%9D%B4-%ED%85%8C%EC%8A%A4%ED%8A%B8-sequential-uuid-jpa%EC%97%90%EC%84%9C-sequential-uuid

dw kim · Answer

저도 그 상황이 잘 상정이 안되어서 굳이 필요한가 싶네요

Archan · Answer

첫번째로 지적하신 PK가 클러스터드 인덱스가 되어서 중간 삽입, 삭제, 변경이 빈번한 컬럼이면 안 좋다 라고 하는데이 부분에 대해서 1. PK를 UUID로 해도 생성이 된 후 수정할 일이 생기나? 수정할 일이 생기는건 비즈니스적인 의미가 있는 값을 PK로 지정한다는것일텐데 UUID는 의미 없는 값이기 때문에 아닐 거 같습니다2. PK를 클러스터드 인덱스로 사용하는곳은 MySQL, MS-SQL을 포함해서 몇개 없습니다, 범위를 좁혀서 설명하시면 좋을 듯 합니다.두번째로 B+Tree 형태로 인덱스를 관리해서 입력 시마다 페이지 분할 과 인덱스 재정렬이 발생하게 됩니다.이 부분에 대해서는 대부분 실무에서 UUID를 써야하면 UUIDv7을 사용하기 때문에 버전에 따라서 차이가 발생할 것 같습니다.제가 생각하는 단일 인스턴스 환경에서 PK를 Auto Increment vs UUIDv7 를 비교했을 때 AutoIncrement는 BigInt (8), UUIDv7은 Binary(16) 를 사용합니다, 크기상 8바이트와 16바이트 이기 때문에 2배죠?하나의 인덱스 페이지에 담을 수 있는 레코드의 차이의 키가 두배가 차이 나기 때문에 버퍼풀 캐시 관점에서 1.3~1.5배 차이가 발생할 수 있구요마찬가지로 인덱스 페이지에 담을 수 있는 레코드 차이가 나기 때문에 B+Tree의 깊이가 깊어질 가능성이 있구요그 외의 ETL, 로깅등에서 모두 2배의 공간을 차지하게 되는 현상이 일어날 것 같습니다.

리오레오 · Answer

uuid를 쓰는 이유는 가장 중요한 것이 다음 번호를 추측하기 어렵게 하는 목적입니다. 단순한 계시판 같은 경우는 자동 증가를 사용해도 무방하지만, 예약 번호같은 경우 자동 증가 번호를 할당하면 다음 번호가 쉽게 예측이 됩니다. 이런 경우에는 외부의 공격에 쉽게 노출이 됩니다. 만약 보안이 허술할 경우에는 그대로 다음 번호가 공격 대상이 됩니다.

스토리 · Answer

UUIDv7를 사용하면 해결되기도 하구요.UUID를 외부에게 전달하는 값, 내부에서 사용하는 seq id를 쓰면, 보안에도 이점이 있습니다.

scissors hand · Answer

참고할만한 글입니다.https://news.hada.io/topic?id=25109

PK 를 UUID 로 지정하는건 안티 패턴 아닐까요?

10개의 답변

#pk 목록