[TIL] TSID를 사용해야하는가? 왜 Id값은 Long(bigint)로 하는가?

 

TSID를 사용해야하는가?

TSID는 보통 서버용 프로그래밍에서 사용하는 int, Long 타입의 auto increment에 비해 실행 중인 노드 정보 및 시간 정보를 포함하여 64비트 단위로 id를 생성하고 활용하는 방법이다.

 

대부분의 애플리케이션에서는 필요없다. DB가 분산시스템으로 2대 이상 존재하며 서로 싱크를 맞춰야하는(샤딩) 상황에서 필요하다.

 

TSID에 대한 개념은 이 글에서 적지 않는다. 좋은 참고자료들이 많다.

https://jsonobject.tistory.com/634
https://tech-monster.tistory.com/228

 

 

TSID를 사용해야할 때, 사용하는 장점

 

여러 시스템이 동시에 DB에 insert를 할 때도 id가 중복나는 경우가 거의 발생하지 않기 때문에 안전하다. 그리고 Long 타입으로 인코딩 변환하여 활용하면 정렬도 지원되므로 단순 유일성을 보장하는 uuid 대비해서도 유리하다.

 

Long(bigint), auto increment를 사용할 때 고려할 점

 

db lock

여러 대의 서버가 1대의 DB를 바라보고 ID를 생성하는 경우라도, DB에서 기본적으로 ID 생성 시 lock을 잡아서 유일성이 보장된다. 너무 많은 삽입이 동시에 일어난다면 해당 락 때문에 성능 저하가 걸릴 수도 있겠다. 그러나 이런 부하가 걸리는 경우라면 ID 생성 lock 외에도 레코드 삽입용 lock도 걸릴텐데, 이 부분이 더 큰 성능 저하 포인트가 될 수도 있을 것 같다. 참고로 TSID 생성 방식은 DB에서 ID 생성을 하도록 요청하는 것이 아니고 애플리케이션단에서 생성하기 때문에 DB의 ID 생성 락은 피할 수 있다.

 

bin, char 대신 Long(int, bigint)을 사용하는 이유

TSID 외에 bin, int, char 타입을 적용할 수 있다. char는 문자열이라 길게 저장할 수는 있으나 block에 저장하는 용량이 크고, bin은 사람이 탐색하기에는 불편한 점이 많으므로 int 타입을 사용하여 가성비가 좋게 설계한다.

 

int vs long

대표적인 64비트를 지원하는 언어들(자바, 자바스크립트, 파이썬 등)은 bigint 단위인 약 9경에 이르는 숫자까지 지원한다. 특히 파이썬은 9경 이상의 숫자를 사용하더라도 숫자 크기에 제한이 없기 때문에 오류가 발생하지 않는다고 한다. 따라서 long 타입을 가정하고 사용해도 된다. 다만 32비트 php 같은 구식 서버 같은 경우 int 단위인 약 21억 정도까지만 지원하기 때문에 long 타입으로 설계된 서버와의 통신을 위해서는 long 타입의 ID를 인코딩 및 디코딩하여 문자열로 주고받는 방식을 사용해야할 수 있다.

 

 

DB 별 특징

 

mongDB

기본적으로 TSID와 같은 개념으로 노드의 키값과 타임스탬프를 기반으로 하는 Object_ID라는 것을 사용한다. 애초에 디비 자체가 그런 분산 시스템을 위해 설계되었다.

 

MySQL

PK로 지정된 id 값이 클러스터링된다. 순서대로 auto increment되던 중 특정 id에 해당하는 레코드가 삭제되고, 그 이후에 다시 그 번호로 레코드가 삽입되면 재정렬되면서 pk의 정렬 순서를 항상 맞춘다.

 

PostgreSQL

MySQL과 달리 삭제되고 나중에 추가된 번호가 작은 id값이 재정렬되지 않는다. 조회 시마다 정렬을 해야해서 부하가 걸릴 수 있다.