mysql 데이터 베이스를 설계하면서 pk를 auto increment 로 하면 왠지 안될 것 같다는 느낌이 들어 이유를 찾아 보았다.
PK 를 auto increment(자동 증가) 할 경우 생기는 문제점
- 1씩 증가하는 형식은 ID 의 앞 뒤로 다른 user 의 PK 값임을 쉽게 예측할 수 있으며 악의적인 공격에 취약하다.
- 새 항목을 생성하고 해당 ID 를 검사하면 테이블의 행 수를 알 수 있다.(정보가 공개된다.)
- 각 테이블이 순차적인 값을 가지므로, 동일한 값이 다른 엔티티의 기본키로 발견된다.
- 1씩 증가하는 방식은 범위가 한정적이기 때문에 서비스를 이용하는 수가 폭발적으로 증가하면 고갈이 될 수 있다.
그런데 unsigned bigint로 데이터 타입을 정의한다면, UNSIGNED BIGINT는 8바이트(64비트) 크기를 가지며, 범위는 0부터 18,446,744,073,709,551,615까지의 양의 정수 값을 나타낸다. 약 18경으로 매우 큰수인데, 웬만한거는 커버할 수 있는 값이라고 생각하는데도 불구하고 4번을 고려해야하는가?? 라는 의문점을 가지게 되었다.
그래서 네이버 부트캠프에서 멘토분들과, 캠퍼분들에게 물어보았다.
캠퍼분으로 부터 "저장공간이 1GB밖에 없는데 최대한 많은 유저 정보를 저장해야한다면 유저 정보에서 필요 없는 군더더기들을 최대한 드러내야겠죠. 그렇다면 BIGINT를 쓰기보단 SMALLINT 등 범위를 줄이는게 좋은 선택일 것입니다. 그 다음 SMALLINT로 전체 유저를 커버할 수 있는가? 고갈되지 않는가? 를 고려하게 되겠죠." 라는 답변을 얻었다.
그리고 멘토분들로 부터 "4번이 말하는 바는 id 값 자체의 고갈이 아니라 저장공간의 고갈이다." 라는 답변을 얻었다.
결론적으로 4번의 "고갈"은 저장공간의 고갈을 의미하는 것이었다.
728x90
