DB의 id 값은 INT? BIGINT?

---

MySQL과 Java와의 자료형 매핑

MySQL	Java
INT	Integer, (unsigned라면) Long
BIGINT	Long, (unsigend라면) java.math.BigInteger

고려해야할 내용

1. MySQL의 메모리 용량, 서버 저장 공간, 쿼리 속도 고려

• int형은 bigint형에 비해 10% 이상의 디스크 용량을 절약한다.
• id값이 43억이 넘어가는 아주 큰 DB를 사용한다면 고민없이 bigint형을 사용해야 한다.

2. 향후 업그레이드 용이성 고려

• DB 규모가 큰 앱 개발 시에는 서버 운영 효율이 낮아지더라도 bigint형이 좋은 선택일 수 있음
  • id의 경우에는 다른 테이블의 외래키로 사용하고 있을 확률이 높고, 변경을 고려할 정도라면 데이터 양이 많을 것이므로 수정이 엄청 오래 걸릴 것이다.

DB의 id 생성은 AUTO_INCREMENT? UUID?

---

1. AUTO_INCREMENT

• 1부터 시작해서 값을 계속 증가시키면서 db에서 저장될 때 자동으로 생성한다.
  • Neo4j 라는 그래프 DB가 있는데 얘는 id가 0부터 시작함 ㅋㅋ…

→ 단점

MySQL AUTO_INCREMENT의 문제점

1. 분산 환경에서 문제가 생긴다.
   • 데이터베이스가 여러 개인 분산환경에서 PK에 auto_increment 설정을 주면 데이터 일관성에 문제가 생긴다.
     • 중복된 키가 생긴다.
2. 키를 예측하기 쉬워진다.
   • 경쟁사 회사의 고객수를 알기 위해서 아이디를 만들고 url를 통해 primary 키를 알아내기만 하면 된다. 또한 키를 예측하기 쉽기 때문에 SQL Injection 공격에도 취약해진다.

2. UUID (Universally Unique ID)

• 중복이 아닌 유니크한 값을 자동으로 생성한다.
• BINARY(16)이나, VARCHAR를 써야한다.

@Id
@GeneratedValue(generator = "uuids")
@GenericGenerator(name = "uuid2", strategy = "uuid")
private UUID id;

→ 단점

1. 메모리 차지
   • INT 타입을 쓰는 AUTO_INCREMENT방법보다 메모리를 더 많이 차지하게 된다.
2. 소요 시간
   • uuid를 생성해야하므로 insert할 때 시간이 더 걸린다.

결론

• 단일 DB는 AUTO_INCREMENT이 성능과 메모리 측면에서 더 낫다
• 다중 DB를 사용하는 분산형 환경이면 데이터 일관성을 위해 UUID 고려하기