🔗 DB 식별자 값으로 UUID v7 사용하기

문제

쿼리가 의도한 대로 동작하지 않습니다. 인덱스 스캔이 되지 않습니다.

select max(basechat2_.chat_id)  
from chat basechat2_  
where basechat2_.room_id = roomuser0_.room_id  
order by basechat2_.create_at desc,  
         basechat2_.chat_id desc

전체 쿼리로 하면 길어지기 때문에 전체 쿼리 중 문제의 서브쿼리만 작성하였습니다.

create_at는 시간 순이며 변경되지 않습니다.
chat_id도 시간 순으로 순차적으로 추가되며 변경하지 않습니다.

그러나 MySQL에서는 A, B 레코드가 있을 때, A가 B보다 create_at이 크면 chat_id도 크다는 걸 모릅니다(어플리케이션 단에서 정한 규칙이므로).
현재 인덱스가 basechat_idx(room_id, create_at, chat_id)인데, room_id까지만 유효하고 중간에 create_at가 없어서 처리가 되지않습니다.
그래서 room의 모든 chat을 index full scan하게 됩니다.

쿼리 테스트 시 상태

• user 100명
• room 200
• roomuser 100 개
• chat 100000 개 = 한 방당 500개

왜 문제일까?

index full scan = 테이블 데이터가 늘어날 수록 읽는 량이 증가 -> 성능 감소

원인

인덱스 조건으로 인한 문제이지만, 더 근본적으로는 id와 create_at으로 시간 순 정렬 2가지 값을 모두 사용하려고 해서 생긴 문제입니다.

해결 방법

1. 인덱스 추가/조건 수정
   • 성능 감소 or 유연한 쿼리(특정 시간 순 검색 등) 중에 하나는 포기를 해야 합니다.
2. 시간 정보가 포함된 ID를 사용하기
   • 근본적인 원인 해결
3. Native SQL을 사용하기
   • JPA의 한계로 from 절 서브쿼리 및 서브쿼리 limit이 불가능, 하지만 직접 SQL문을 작성한다면 기존 구조로도 유효한 설계를 가져갈 수 있습니다.

해결 방법 선택

2번 방법 채택 이유: 설계 단계이므로, 기존 데이터와의 호환성을 걱정하지 않아도 됩니다. long, localdate의 byte 크기를 합치면 uuid와 동일하여 저장공간 문제도 적습니다.

어떤 식별자를 사용할 것인가?

• ObjectID: MongoDB에서 사용함, 시간 순 정렬, 96bit(12-bytes)
• UUID: 128bit(16byte), 표준으로 널리 쓰임. v1과 v7만 시간 데이터가 포함되며, 시간 순 정렬이 가능합니다.
• ULID: UUID와 호환됨, 시간 데이터를 추가한 커스텀 UUID 형식
• Snowflake ID: 트위터에서 만든 PK, 오픈소스 했던 걸로 아는데 지금은 아닙니다.

결론: UUIDv7 채택

• ULID와 달리 표준입니다.
• v1처럼 필요하지 않은 MAC address(보안 상 문제가 생길 수도 있다고 함)같은 데이터가 없습니다.
• 시간 제외하고 나머지 요소는 전부 순차적인 랜덤 데이터입니다 (구현에 따라 다를 수 있다고 함)
• 스타가 꽤 많은 오픈소스 라이브러리 존재함 (타 라이브러리 대비)
• 그리고 JPA의 호환을 위해 ULID 라이브러리의 ULID 타입을 사용하더라도 저장을 UUID로 하고 ULID의 기능을 사용하기 위해서 형병환을 해야 하는데, 이러한 변환 과정이 번거로울 수 있습니다.

실제 서비스에서 식별자로 사용하기도 합니다. CICD 툴을 제공하는 Buildkite 서비스에서 식별자로 UUIDv7을 채택하기도 했습니다.

라이브러리 선택

1. java-uuid-generator
2. uuid-creator

스타 수가 더 많은 1 선택

시간 조건 쿼리 사용법

https://buildkite.com/blog/goodbye-integers-hello-uuids << 참고

0x018B5642A68F7892AD50248BAC01E76C << Chat ID 일때, 0x018B5642A68F 를 Hex to Decimal 하면 1697959290511가 나옵니다. 이 값이 시간 정보(epoch time)입니다.

코틀린 코드로 UUID를 시간 정보를 포함하는 long 타입으로 변환하려면 아래처럼 구현 가능합니다.

fun getTime(uuid: UUID): Long { return uuid.mostSignificantBits ushr 16 }

msb가 64비트니까 오른쪽으로 16비트 시프트 해서 48비트만 구해서 시간 정보를 가져옵니다.

날짜 기준으로 쿼리 사용 시에는

select *  
from chat  
where chat_id <= 1697959290511

로 검색할 수 있습니다. (16진수나 10진수랑 호환되는 듯)

아니면 0x018B5B123FAA72E2BE5953AAF2A0741B 처럼 걍 16진수 써도 실행 가능

대신 UUIDv7 특징 상 앞자리가 시간이고 나머지는 랜덤이라 정확히 그 시간대더라도 <= 조건으로 검색해야 합니다(어차피 == 조건 쓰면 에러).

만약 특정 시간대 이하(>=) 조건을 사용하고 싶다면?

select *  
from chat  
where chat_id > 1697959290511 + 1 # 시간대에 1 밀리초를 추가하고 미만 조건으로 검색하는 것

처럼 사용합니다.

java UUID 사용 시 주의점

JDK에는 64비트 값의 순진한 비교를 사용하는 java.util.UUID의 구현에 결함이 있습니다.
compareTo()기본 콘텐츠가 모든 목적에 대해 서명되지 않은 경우 이는 예상대로 작동하지 않습니다.
예를 들어 두 개의 UUID는 다음과 같습니다.

7f905a0b-bb6e-11e3-9e8f-000000000000
8028f08c-bb6e-11e3-9e8f-000000000000

부호 확장으로 인해 두 번째 값부터 먼저 주문됩니다(두 번째 값은 음수로 간주되므로 "더 작음").

이 때문에 항상 com.fasterxml.uuid.UUIDComparator간단한 부호 없는 정렬인 예상 정렬 순서를 구현하는 와 같은 외부 비교기를 사용해야 합니다.
이는 UUID의 사전식(알파벳) 정렬(균일한 대문자 사용을 가정할 때)과 동일합니다.

위 글은 java-uuid-generator에서 참고

코드 구현 시 문제점

LocalDateTime을 Long으로 변환 or 반대 로직을 수행하는 경우에서 LocalDateTime.MAX를 사용하면 Long 변환 과정에서 overflow 발생 -> LocalDateTime.MAX 대신 5000 년도 시간으로 변경하고 Util 클래스에서 공유해서 사용하도록 변경

UUID 적용 후

id에 시간 정보가 포함되기 때문에 create_at을 삭제, 인덱스 구조를 chat_idx_1(room_id ASC, chat_id DESC),로 변경

SELECT MAX(chat.chat_id) FROM chat WHERE chat.room_id = 11

실행 계획

-> Zero input rows (No matching min/max row), aggregated into one output row  (cost=0..0 rows=1) (actual time=0.00954..0.00963 rows=1 loops=1)

room_id=11에는 500개의 채팅이 있지만 하나의 레코드만 읽고 쿼리를 종료합니다.

SELECT count(chat.chat_id) FROM chat WHERE chat.room_id = 11
-> Aggregate: count(chat.chat_id)  (cost=101 rows=1) (actual time=0.257..0.257 rows=1 loops=1)
    -> Covering index lookup on chat using chat_idx_1 (room_id=11)  (cost=50.9 rows=500) (actual time=0.0692..0.223 rows=500 loops=1)

결론

시간 순 정렬과 시간 데이터까지 하나로 처리함으로써 인덱스를 더욱 효과적으로 설계할 수 있었습니다.

나중에 엔티티 구조 자체가 변경되어서 해당 쿼리를 사용하지는 않게 되었습니다.

하지만 UUID를 사용함으로써 효율적인 인덱스 사용이 가능해졌고, 이후 새롭게 구현하는 구조에서도 사용되었습니다.