UUID vs CharField의 max_length

'ZARA' 사이트를 막 클론코딩하기 시작했을 때인데 모델링하던 중에 주문 앱에서 고유한 값이어야 하는 '주문번호'가 있었습니다. 그런데 이 부분을 CharField로 했어서 중복되지 않는 임의의 문자로 바꿔야 했습니다.

그래서 아래처럼 CharField(max_length=20)로 할 경우와 UUID 중 더 효율적인 방법에 대해 고민하고 찾아봤습니다. 

 

사실 이런 질문을 하신 이유에 대해서 어렴풋이만 그 의도를 짐작할 수 있었어서 다시 한번 여쭤보고 진행을 했습니다.

멘토님께서 조언을 주신 덕분에 'UUID'에 대해 찾아봤습니다.

 

UUID

- 36개 문자(32개의 문자와 4개의 하이픈) 8-4-4-4-12
- 가장 많이 쓰이는 버전은 버전4 (시간+랜덤)
- 128비트의 숫자, 32자리의 16진수로 표현 ('-'까지 포함하면 36자리)

 

장점

- 중복이 사실상 없어서 고유적인 키를 즉석에서 생성할 수 있고 연속성이 없어서 쉽게 추적할 수 없다.

 

단점

- 연속성이 없어서 만든 사람도 의미를 알 수 없다.

 

사용하는 경우

- 보호하려는 데이터가 있을 경우
- url 검색 시 쿼리값에 사용자의 id가 그대로 노출되는 경우가 있어 이를 막고자
- 중복되지 않아야 할 쿠폰 번호

 

UUID에 대해 알아봤으니 CharField의 max_length와 비교해보고자 합니다.

 

DB의 character_set은 utf8mb4이고 글자당 4바이트가 할당됩니다.
만약 max_length=20 으로 하면 20 * 4바이트 = 80바이트가 할당됩니다.

UUID와 charfield의 max_length를 연결시켜 생각해보면

UUID - char(32)만큼의 공간이 필요해서 32바이트 필요한데
Charfield로 UUID를 구현하려면 36자리 필요해서 36*4바이트 = 144바이트 필요합니다.

 

그래서 기존에 정의했던 방식으로는 구현이 불가능하기도 하고 효율적이지도 못 해서

아래처럼 UUIDField를 통해서 구현하는 쪽으로 바꿨습니다.