Почему идентификатор TSID такой?

Question

[Мир]

Идентификатор TSID состоит из [timestamp:42bit, nodeID:10bit, counter:12bit]
Какой смысл хранить время если наличие nodeID подразумевает наличие архитектуры для назначения и распределения nodeID?
nodeID+counter уже исключает повторяемость
Получается наличие такой архитектуры позволяет сделать более лаконичный ID, например
[nodeID:16bit, counter:48bit]

Comments

[Everything_is_bad]

чём тебя не устраивают ответы в гугле?

[Мир]

Everything_is_bad, очевидно что там нет ответа

[Everything_is_bad]

Мир, очевидно что ответ дан очень давно, как пример, https://fillumina.wordpress.com/2023/02/06/the-pri...

[Мир]

Everything_is_bad, повторюсь, там нет ответа на мой вопрос. Перефразирую вопрос: какая причинно-следственная логика разработчиков TSID исходя из которой TSID имеет timestamp, если при наличии инфраструктуры распределения nodeID от timestamp можно отказаться.

[Everything_is_bad]

Мир, там рассказано для чего именно это надо, если для тебя это не актуально, ну так откажись.

[Мир]

Everything_is_bad, мой вопрос не "для чего это надо", а "какова логика создания именно такого решения"

[Everything_is_bad]

Мир, ты прочитал статью? какая проблема поставлена, как она решается и какими вариантами. Попытаться чуток самостоятельно подумать. Например, "monotonically incremented" тебе что-то говорит? Если нет у тебя такой проблемы, но не нужен тебе timestamp

[Мир]

Everything_is_bad, прочитал. Ни о чём не говорит. Сейчас ты указал на это и стало понятней что это нужно для правильного создания B-tree индекса. Это логично в рамках одной БД. Но когда у нас распределённая система с множеством БД то вариант [nodeID:16bit, counter:48bit] даст тот же самый "monotonically incremented" для каждой БД.
В итоге не понятно зачем timestamp чтобы иметь "monotonically incremented" ведь "monotonically incremented" и так есть.

[Everything_is_bad]

Мир, так вариантов распределенных систем может быть куча, например, те же примарикей конкретной части могут быть как внешние ключи в разных частях этой системы.

[Мир]

Everything_is_bad, то есть если есть две БД А и Б, но Б имеет внешней ключи на таблицы из А, то в случае без timestamp... не могу въехать что произойдёт. Плохое построение B-дерева?

Пока вижу единственно зачем может быть нужно "monotonically incremented" в рамках распределённой системы это в случае слияния двух БД. Но думаю эффект при слиянии будет такой же как с TSID.

Answer 1

[Сергей Соловьев]

Чтобы уметь их сравнивать.
Если использовать твое решение (без времени), то будет верным только 1 узел всегда (если в этом случае сравнение будет иметь смысл).

Comments

[Мир]

Т.е. чтобы чтобы последующие значения были больше предыдущих? А для чего это в рамках распределённой системы?

[Сергей Соловьев]

Мир, много для чего. Например, представь что с 2 узлов приходит команда на (пере) запись одного и того же значения. Как ты их рассудишь?

[Мир]

Сергей Соловьев, это уже вопрос бизнес логики, а не БД. То есть ID за это уж точно не отвечает. Или я недопонимаю?
Имеется ввиду например сгенерировать команды на узлах в виде TSID и хост получивший их по timestamp отсортирует и выполнит? Допустим TSID в пакете сообщений. Но причём тут TSID как формат хранения первичного ключа в БД?

[Сергей Соловьев]

Мир,

Но причём тут TSID как формат хранения первичного ключа в БД?

Это откуда вообще взялось?