ID (번호) 생성 전략

개요

Rails에서 SNS계 서비스를 만들 때 타임라인형으로 페이지네이션을 실현하기 위해서는 메모.
평소대로 정렬하고 카운팅만으로는 해결할 수 없었던 이야기와 솔루션의 이야기입니다.

결론

결론부터 말하면 UUID version1과 같은 시간형으로 충돌하지 않는 id 생성이 이루어지고 있으면 OK.
어디까지나 Rails에서 벗어나지 않고 코드 관리만으로 생각했을 때에 시계열로 늘어선 ulid의 구현에 침착했습니다.
htps : // 기주 b. 코 m / ぃ d / s ぺc

구현 제안

토끼에도 모퉁이에도 실장예를 보이지 않으면 시작되지 않기 때문에, 이하에 침착했습니다.
cursor형 페이지네이션의 구현이 됩니다.
htps : // 기 st. 기주 b. 코 m / 펜구인을 krs / 45 아 7c 푹 d3c31698이다 9b3
키모의 해설입니다만, UUID를 붙여 UUID끼리를 비교해 초과 이후를 추출하고 있을 뿐입니다.

klass.where("`uuid` < '#{cursor}'") # cursorの部分もuuidです。

(...단지 이것만...ulid...대단해...)

기존 문제

트위터와 같은 서비스로 페이지 네이션 구현을 생각했을 때, 작성 시간을 바탕으로 정렬하고 나서 20건씩 카운팅하면, 우연히도 같은 시간에 트윗될 가능성은 크게 있기 때문에, 1페이지째와 2 페이지째에 중복된 트윗 내용이 나올 가능성이 있다.
SQL적으로는, 이하와 같은 구현이 대응으로서 회피 가능하다.
Pagination(페이지 네이션)이 어긋나는, 빠지는 문제를 해결한다

채용하지 않은 이유로는 다음과 같습니다.
* 밀리 초 단위로 제어가 고려되지 않았습니다.
* SQL적으로 튜닝과 유지 보수가 엄격한 것 같습니다. (저비용으로 할 수 있는 방법을 실현시키고 싶었다)

참고문헌

Facebook, Twitter, Instagram 등이 어떻게 ID를 생성하는지 정리

Pagination(페이지 네이션)이 어긋나는, 빠지는 문제를 해결한다

UUID_SHORT

h tps:// 퀵했다. 작은 m/카와시마/있어 MS/6b0f47아 60c9cb5

소감

대규모 서비스일수록 스케일할 때 어떻게 할지 굉장히 생각하고 있어, 참고가 되네요.
Mastodon은 오픈 소스로서 Twitter가 작성한 snowflake를 채용하고 있어 좋다고 생각했지만, 구현을 스토어드 프로시저로 관리하고 있었다.
snowflake의 구현은 좋다고 생각하지만, 전용 서버 준비하거나 스토어드 프로시저는 현대에서 생각하면 코스트가 높게 느끼는 것은 자신만일까.

트렌드적으로 GraqhQL이 제품에 투입되기 시작하고 있으므로, 이쪽의 Edge와 Node 도 배워 가고 싶은 곳입니다.

P.S.
구현의 제안으로 보충입니다만, header의 부분에서 github같이 RFC 스타일 에 준거하고 싶었지만, API를 이용하는 개발 진영과의 접이가 없고, 독자 구현이 되었습니다.

RFC 5988 "Web Linking": htps : // 및 ls. 아니 tf. rg/html/rfc5988