Auto-Increment와 UUID

좋아요와 이모티콘 기능을 구현하면서 PK에 대해 들었던 의문과 학습/생각정리를 위해 간략하게 글을 남겨봅니다. 

 

 

 

 

 

1. Auto-Increment와 UUID. 그 의미

---

Auto-Increment의 경우 데이터가 추가될때 자동으로 PK값이 1 증가하며 UUID의 경우 VARCHAR 혹은 Binary 값으로 PK를 저장할 수 있습니다. Auto-Increment 같은 경우 순차적으로 값이 증가하기 때문에 값이 연속적으로 증가하는 것을 한 눈에 알아볼 수 있는 장점이 있는 반면 중간에 데이터가 유실되거나 하더라도 그 값이 채워지지 않습니다. 반면 UUID의 경우 랜덤한 값이 생성돼서 데이터베이스에 들어오기 때문에 연속적인 값들을 알 수 는 없지만 중간에 공백이 생기더라도 PK의 연속성을 신경쓰지 않아도 됩니다.

 

 

 

 

 

 

 

회원과 게시글/댓글과 같은 경우 몇 번째 회원, 몇 번째 게시글과 같이 순차적인 값이 의미가 있기 때문에 Auto-Increment를 사용하는 것이 나쁘지 않지만 반면 좋아요/이모티콘과 같은 경우 이 값을 굳이 Auto-Increment로 관리할 필요가 있을까? 에 대한 의문이 들었습니다. 회원이나 게시글보다 자주 추가/삭제 될텐데 중간에 값이 비더라도 별 탈없는 UUID가 더 낫다고 생각했기 때문입니다.

 

 

 

 

 

 

 

2. 인덱스와  UUID를 선택한 이유

---

좋아요/이모티콘을 UUID로 바꾸기로 결정하면서 한가지 고민사항이 생겼는데요, 데이터베이스가 UUID의 인덱스를 어떻게 정렬하는지와 인덱스의 길이, 성능이었습니다. 성능에 관해서는 해당 블로그와 스택 오버,인프런 강의 질문/답변 에서 잘정리해주셨는데요, 한 번 읽어보실 것을 추천드립니다.

 

 

우선 인덱스를 어떻게 인식할까에 대해 고민은 UUID도 데이터베이스의 B-Tree 자체적인 기준으로 정렬할 것이기에 따로 고민하지 않아도 되는 부분이었습니다. 또한 key-len에 대해서는 별도로 신경쓰지 않았는데 binary 형태로 사용할 경우 UUID가 큰 영향을 주지 않기 때문입니다. [출처]

 

key-len은 binary 형태로 사용할 경우 큰 영향을 주지 않는다고 판단

 

 

 

 

 

따라서 INSERT, SELECT 성능만 고민하면 되었는데 INSERT시에는 성능이 조금 떨어지지만 조회시에 사용자가 느낄 정도의 큰 차이는 없습니다.

 

 

 

 

 

 

따라서 UUID를 좋아요/이모티콘의 PK로 설정했고 지금도 사용하고 있습니다. 물론 UUID를 사용하는것에 대한 부정적인 의견도 정말 많았는데요, 이런 부분에 대해서는 UUID가 주는 장점이나 제가 선택한 이유에 대해 희생해야할 비용이라고 생각하고 사용하기로 했습니다. 

 

     - 이모티콘/좋아요는 추가/삭제가 빈번한데 중간에 값이 삭제되더라도 PK 공백이 생기지 않는다.
        (PK 공백이란 1, 2,  3,  x, 5, 6과 같이 PK가 있을때 4가 비는 현상을 말합니다)

     

 

 

 

단, 데이터가 자주 추가/삭제 된다면 이 부분에 대해서는 별도로 신경을 써야 하는데요, 이 부분에 대해서는 중간에 캐싱 서버를 만들 예정이기 때문에 조금 더 고려해볼 예정입니다. 또한 데이터의 INSERT / DELETE가 조금 늦어지더라도 조회하는 속도가 빨라지기 때문에 희생해야 할 부분이라 생각했습니다. **Auto-Increment를 활용하더라도 추가/삭제 발생하기 때문에 이 부분은 (아직은) 조금 더 지켜봐야할 것 같습니다.

 

 

 

 

3. Conclusion

---

결론적으로 UUID를 사용해도 사용자가 느낄 정도로 큰 차이는 없다 는 것이 결론이었고 이를 위해 Auto-Increment대신 UUID를 선택했습니다. 성능상 안 좋은 부분도 있겠지만 데이터가 많아지면서 느끼는 불편함이 있다면 이 부분에 대해 추가적으로 포스팅을 해보려 합니다. 읽어주셔서 감사합니다.