궁금점

지금까지의 경험에 따르면 저는 PK선택을 항상 Auto Incremnet로 했어요. 자료 검색을 하다 우연히 발견했던 것 "UUID vs Auto Increment 중 PK 선택하기"

거의 모든 프로젝트들은 Auto Incremnet 방식을 선택하는데, 그 이유는 무엇이고 UUID의 장점과 사용 이유가 궁금해졌어요.

Auto Incremnet

장점

• 숫자로만 되어 있기에 가독성이 좋아요.
• MYSQL의 경우 PK가 Cluster Index인데, PK가 순서대로(인접하게) 저장되기에 INSERT가 빠를 거에요.

단점

• PK값이 노출되면 API(/uses/{pk}/와 같은 URL 패턴)를 통해 정보 노출이 될 수 있어요.

UUID

장점

• UUID는 데이터에 대한 노출이 없기에 보안상 안전해요.
• UUID는 독립적으로 개발되는 시스템에도 유일성을 갖는 식별자로 데이터베이스가 여러개가 있다 하더라도 하나의 UUID는 고유성을 갖고 있어요.

단점

• Auto Increment보다 더 많은 공간이 필요해져요.(UUID-128bits)
• 테이블을 정렬하려 할 때, String을 정렬하는 것이기에 정렬이 힘들다.
• 테이블과 인덱스의 크기가 커지고, DB의 메모리와 디스크가 커질거에요.
• 버퍼에 메모리가 빨리 쌓이기에 랜덤 I/O 빈도가 늘어나 성능이 저하될 수 있어요.

주의할점

UUID를 BINARY(255), VARCHAR(36) 등 다른 타입으로 지정할 경우 발생하는 문제점이 있어요.
하이버네이트는 UUID를 저장할 때 binary로 저장하는 것을 기본으로 해요. BINARY(255) 등 16바이트인 UUID 보다 큰 값으로 지정하면 MySQL은 패딩값을 넣어서 채워요.

그래서 UUID에 해당하는 컬럼을 BINARY(16)으로 지정해주어야 해요.

(출처 : Hirberante ORM 5.4.33.Final User Guide)

결론

많은 자료들을 보면 다음과 같이 정리해요.

애플리케이션 내부용 키로는 자동증가 pk, 외부에 공개할 키로는 uuid를 사용하는 것을 권장힌다.

각 방식의 장점을 잘 활용하는 정리 같아요.

오늘도 큰 결론은 똑같은거 같아요.

모든 기술은 trade-off를 갖고 있으며, 상황에 따라 적절히 사용할 수 있는 능력을 키워야 한다.

참고자료

Best practices on primary key, auto-increment, and UUID in SQL databases
JPA 덕분에 DB에서 삽질한 이야기