정렬이 보장하는 것과 아닌 것

시계 오차보다 큰 단위에서만 믿습니다.

같은 밀리초 안에서는 다음 칸인 노드 번호가 크기를 정합니다. 노드 9가 먼저 발급해도 노드 2의 ID가 더 작습니다.

노드마다 시계가 몇 밀리초 다를 수 있으므로 그 오차만큼의 구간에서 순서가 뒤바뀝니다.

흔한 실수: "시간순 정렬" 을 순서 보장으로 이해하는 것. 요구사항에 "같은 밀리초 안 순서를 보장하지 않는다" 고 적은 이유가 이것이고, 그 문장이 실제로 무엇을 뜻하는지 말할 수 있어야 합니다.

안 됩니다. 인과 관계는 보장하지 않습니다.

A를 만든 뒤 그 결과로 B를 만들었어도, 두 발급이 다른 노드에서 일어났고 같은 밀리초 안이거나 시계가 어긋나 있으면 B의 ID가 더 작을 수 있습니다.

선후가 정말 중요하면 그 사실을 따로 기록한다
ID 크기에 기대면 드물게 뒤집힌다

그리고 그 드문 경우가 정확히 문제가 되는 순간입니다. 평소에는 맞으므로 검증에서 드러나지 않고 운영에서 드러납니다.

흔한 실수: 시계를 잘 맞추면 된다고 답하는 것. 오차가 좁아질 뿐 0이 되지 않고, 같은 밀리초 안 순서는 애초에 보장하지 않기로 정한 것입니다.

작은 ID가 뒤늦게 삽입되면 그 항목을 건너뜁니다.

"마지막으로 본 ID 다음부터" 로 요청하는 패턴에서, 시계가 뒤로 갔거나 노드 사이 오차가 있으면 이미 지나간 위치보다 작은 ID가 나중에 들어올 수 있습니다.

빠진 것은 눈에 보이지 않습니다. 중복은 사용자가 알아채지만 누락은 아무도 모릅니다.

흔한 실수: 이 위험을 알고도 그대로 쓰는 것. 화면 목록은 괜찮지만 데이터를 옮기거나 집계하는 순회에서는 누락이 곧 사고입니다. 그런 용도에는 별도의 증가 값이나 시간 범위 조회를 씁니다.

정렬은 저장 비용을 위해 도입한 성질이고 논리의 근거가 아닙니다.

처음에 정렬을 요구사항에 넣은 이유가 인덱스 삽입 비용이었다는 것을 기억하면 구분이 쉽습니다. 그 목적에는 완벽하게 맞고, 다른 목적에는 맞지 않습니다.

흔한 실수: 하나의 값이 여러 목적을 겸하게 만드는 것. ID가 식별자이면서 순서이면서 시각이면 편해 보이지만, 어느 목적의 보장이 어디까지인지 아무도 모르게 됩니다. 목적마다 필요한 보장을 따로 적는 편이 안전합니다.