MySQL PK 전략

현재 제 경험내에서는 PK 전략은 두가지로 나뉩니다

1. UUID를 PK로 사용
2. 정수형 PK를 사용 + Unique Identifier 컬럼 추가

1안으로 대부분 처리했고 중간에 데이터 성격에 따라 2안을 사용한 경우도 있습니다

PK 설정시 고민했던 포인트

1. MSA 환경
   - UID PK: UID가 많이 편했습니다. 데이터 마이그레이션할때 ID 충돌에 대한 걱정은 없었습니다
   - 정수형 PK: 정수형 PK의 경우에는 id가 unique하지 않기 때문에 id에 해당하는 데이터가 있는 경우, 그 데이터가 마이그레이션 할 데이터와 다른경우.. 머리가 아픕니다 새로운 id를 매핑해주고 기존 데이터들도 새로운 id를 매핑해주는 작업이 정말 귀찮고 어렵습니다
2. 정렬
   - UID PK: 제가 사용한 UID는 순서보장이 안되므로 순서대로 정렬하고 싶은 경우에는 createdAt를 인덱스를 걸었습니다 어쩔수 없이 걸게되는 경우입니다
   - 정수형 PK: row 생성순으로 저장되기 때문에 별도의 인덱스가 필요하지 않습니다
3. 인덱스 저장공간
   큰 의미가 없는 포인트입니다 운영에서 사용하려면 둘다 비슷하기 때문입니다
   왜냐하면 UID로 PK를 설정해도 정렬등을 위해서 다른 인덱스가 필수이며, 정수형 PK를 사용해도 UID 유니크 인덱스가 필요하기 때문입니다
   - UID: PK로 사용시 nanoId(CHAR(21)), uuidV4(CHAR(36))를 사용했으나 char 바이트 차가 조금 있긴합니다
   - 정수형 PK: bigint의 경우에도 UID 유니크 인덱스가 필요하기 때문에 큰 차이가 없는것 같습니다
4. 조회/ insert/ update 성능
   해당 내용은 이미 많은 블로그에서 데이터수가 커질수록 정수형 PK가 성능이 월등하다는 벤치마크는 많이 봤습니다
   운영할때 모든 테이블이 그만큼 row수가 많아지는 경우가 있지 않고, 고속 insert해야하는 요구사항도 없었기 때문에 경험 부족합니다
   그러나 마이그레이션 속도는 많이 차이가 났었습니다
   - UID PK: 한 번에 많은 양의 데이터를 조회해오는 경우가 없었기 때문에 많은 차이를 느끼진 못했습니다. 단, 조금의 차이라도 연산의 횟수가 많을 경우에는 당연히 정수형이 인덱스 탐색이나, insert시 차이가 날것 같습니다.
   - 정수형 PK: 일반적인 시스템 개발 및 운영에서는 큰 차이를 느끼지 못했고, 대량 처리를 해야하는 경우 속도 차이를 체감할 수 있었습니다

저는 고민한 결과 정수형 PK + UID 조합이 다양한 요구사항에 대응하면서도 퍼포먼스가 좋은 조합이라 생각하여 추가 테이블 설계시 당분간은 해당 전략을 사용하려고 합니다

 

여기까지 단순히 Read, Write만 나눈 구조로 Mysql PK전략에 대해서 정리했습니다
물론, ProxySQL, Vitess를 이용한 샤딩 및 클러스터링 솔루션이 있지만, 모든건 트레이드오프가 있다고 생각이 됩니다