Snowflake UID를 사용해야하는 이유

UUID를 PK로 사용한다면

데이터베이스 모델링을 할 때, PK를 외부에서 예측하기 어렵게 만들기 위하여 UUID를 사용하곤 합니다. 하지만 UUID를 PK로 갖는 것은 다음과 같은 단점을 갖습니다.

1. 너무 긴 문자열

UUID는 128비트, 즉 16 byte로 구성되어있지만 가독성을 위해서 문자열로 저장하곤 합니다. 32자리의 문자열을 저장하기 위해서는 인코딩에 따라 다르지만 UTF-8 기준으로 32 byte가 필요할 것입니다. ( "-"를 포함하면 36 byte가 됩니다.) 이는 8 byte를 갖는 BIGINT와 같은 자료형과 비교하면 4배 정도의 차이가 납니다.

일반적으로 PK의 크기는 곧 인덱스의 크기에 영향을 미칩니다. MySQL의 경우 PK를 위한 인덱스 뿐 만 아니라 모든 Secondary Index에도 PK가 포함되어야 하므로 데이터의 규모가 커질 수록 무시못할 성능 이슈를 낳게 됩니다.

2. 시간에 순차적이지 않은 값

UUID를 PK로 사용한다면, 생성 순서에 따라 단조 증가하지 않는 특성에 의해 인덱스가 비효율적으로 저장됩니다. 값의 생성에 따라 수시로 인덱스의 균형이 깨져 재구성을 해야하는 상황이 빈번하게 발생합니다.

쿼리를 처리하기 위해 필요한 인덱스의 범위를 Working Set이라고 부릅니다. 대부분의 요청은 최신 데이터에 치중되어있기 때문에 데이터베이스는 인덱스의 일부 범위만을 주로 참조할 것입니다. 이 때에, UUID를 PK로 사용하는 구조에서는 최신 데이터들이 트리에 분산되어 저장됩니다. 따라서 최신 요청에 필요한 데이터를 가져올 때에 인덱스 내의 분산되어 있는 여러 페이지들을 가져오게 될 것입니다. 이는 불필요한 과거 데이터를 갖고있는 인덱스까지 함께 가져오게 되는 효과와 함께, 수시로 인덱스 페이지를 메모리에서 교체해야하는 비효율을 낳을 것입니다.

UUID를 PK로 사용할 때 최신 데이터를 위한 Index Working Set

Snowflake UID

Snowflake UID는 트위터가 개발한 분산 시스템 환경에서 고유한 64비트 ID를 생성하기 위한 알고리즘입니다. 이 알고리즘은 분산 환경에서도 중복되지 않는 고유한 ID를 매우 빠르게 생성할 수 있도록 설계되었습니다.

Snowflake UID의 특징은 첫 41개의 bit가 timestamp로 이루어져 있다는 점입니다. UUID는 timestamp를 사용하지 않거나, timestamp 비트를 재조합하여 ID를 만드는 반면, Snowflake UID는 첫 비트를 온전한 timestamp로 구성하기 때문에 정렬될 수 있다는 점이 가장 큰 특징입니다.

또한 Snowflake UID는 64비트(8 Byte)로 이루어져 있어 UUID에 비해 공간 절약에 유리합니다. 또한 이를 PK로 하여 저장했을 때 시간 순서로 정렬되기 때문에 인덱스의 균형이 잘 깨지지 않을 뿐 더러 하나의 인덱스 페이지에 유효한 데이터를 더 많이 가지고 있을 가능성이 높아 효율적인 동작이 가능합니다.

Snowflake UID를 PK로 사용할 때 최신 데이터를 위한 Index Working Set

GitHub - dustinrouillard/snowflake-id: Time based 64-bit unique id generator, inspired by Twitter snowflakes

GitHub - callicoder/java-snowflake: Distributed Unique ID Generator in Java inspired by Twitter Snowflake

Snowflake-id와 관련된 오픈소스 라이브러리도 꽤 있으니 다음번에 프로젝트 하실 때는 뻔한 UUID보다 요런 것도 한번 찾아서 적용시켜보고 차이점을 분석해보면 좋을 것 같습니다~