Короче (если получится):
В настоящее время, для обеспечения уникальности неких “элементов”, хранимых в базе данных, используется uuid V4.
И всё бы ничего, но, предполагается генерация этих uuid на разных инстансах. Что, не теоретически, а практически, точно приведёт к коллизиям (генерации разными инстансами одинаковых значений). Чтобы эти инстансы не зависили от некоего единственного провайдера uuid’ов, который в состоянии проверять, выдавал ли он ранее такой uuid или нет, появилась идея использовать “пространства имён” на основе даты и времени создания нового “элемента”.
Вообще, понятно, что в самой таблице, хранящей данные “элементов”, присутствует автоинкрементное поле “id”, которое эту уникальность, конечно же, обеспечивает. Но вот беда, некоторые приложения, пользующиеся этими данными, не используют автоинкрементные айдишники, а используют выше обозначеный uuid V4. Засим, дабы не патчить эти приложения, вместо uuid V4 им можно подсунуть строковый уникальный идентификатор, о котором ниже:
Я хочу генерировать уникальные ключи вида (без квадратных скобок, они тут только для того, чтобы вам было понятно из чего состоит ключ):
[year][month][day][hour][min][sec][usec][usec][usec]
Где:
year – год, всегда 4 цифры
month – месяц в году, всегда 2 цифры
day – день, всегда 2 цифры
hour – текущий час, всегда 2 цифры
min – текущие минуты, всегда 2 цифры
sec – текущие секунды, всегда 2 цифры
usec – текущие микросекунды, всегда 6 цифр, три раза по 6
Теперь подробнее про микросекунды:
Тики процессора, в принципе, по частоте их следования, сопоставимы с его тактовой частотой и значениями микросекунд. Кроме того, процессор, как правило, выполняет несколько задач, циклически обходя каждую из них, и, возвращаясь к задаче генерации ключа, эта задача, трижды запрашивающая текущее значение микросекунд, будет получать немного отличающиеся значения (уже проверено). Ну а три раза подряд – это и есть защита от коллизий в пределах одной секунды, ещё и на разных инстансах.
Так вот вопрос:
Насколько по вашему подход, выбранный мной, будет надёжным? Конечно же, учитывая генерацию на разных инстансах.

Вот бы не использовать айди клиента в ключе, ибо клиентов много и ручное их добавление – суть гемор.
Я зацепился за микросеки, таймстамп там только ака неймспейс. Может этот самый ууид запользовать в конце вместо микросеков?
Я думаю тебе надо вернутся к твоему прежнему посту:
И так, если тебе надо чтобы инстансы имели общую характеристику, например уникальность для всего облака создаваемого инстансом id то должно быть что-то, что эти инстансы объединит, будь то сервис или созданный в ручную id инстанса.
Для тебя отмечу то, что как я понимаю тебе не нужно строгое соответствие между инстансами и их id, тебе достаточно чтобы в каждый момент времени каждый id инстанса использовался не более чем одним инстансом.
Отсюда простой рецепт: для каждого хоста являющимся сервером облака инстансов ты создаёшь на этом хосте директорию в которую складываешь пустые файлы с именами в виде предварительно сненерированных для этого хоста id инстансов и далее конкретный инстанс берёт себе из неё случайный свободный id инстанса и создаёт для него lock файл показывая что этот id инстанса занят.
Не, я б на твоём месте даже и не пытался на время завязываться. Это только у нормальных людей оно всё время вперед течёт, а у программистов бывает и наооборот.
Потому и спрашиваю, насколько уникальными будут ключи, генерящиеся зависимо от времени добавления записи не важно каким клиентом?
Ты говоришь, что получится херня. Я согласен. Какой тогда формат ключа не даст коллизий для одной записи между всеми клиентами? Ключ клиента? Больше никак? Тогда придется дергать писателей клиентов, а это, не сказать, что просто и быстро – у них давно формат обмена данными устаканился. Хак с другим пересылаемым полем позволяет никого не дергать.
Если генерация зависит только от времени, то нужно для надёжности использовать hardware RTC, ну или хотя бы ядерные таймеры. Если ты будешь брать условное epoch time, то можно нарваться на коллизии при коррекции часов демоном ntp. И это всё должно быть на одном единственном хосте, на нескольких у тебя ещё больше сложностей будет. Плюс, если у тебя многопоточное приложение, то при одновременной обработке нескольких запросов так же может произойти коллизия, тогда надо к таймстампу дополнительно брать ещё один монотонный атомарный счётчик.
А как ты вообще клиентов добавляешь? У тебя совсем открытый сервис, никаких API ключей?
Даже если будет у каждого свой, то авторизация никак не связана с данными в базе. Проблема в том, что все эти клиенты используют данные из одной базы, но ууиды для этих данных у этих клиентов у каждого свои. Отсюда возникают коллизии и на стороне базы и на стороне клиентов, т.к. каждый клиент мерджит данные, отправляет свои новые в базу и получает чужие (других клиентов) из базы. Клиенту можно скормить в ответе (в другом пересылаемом в обе стороны поле) ключи, уникальные для всей базы, а соответственно, уникальные и для всех клиентов. Клиент может сопоставить свой, коллизный к внешним, но уникальный у него, ууид и этот ключ для какой-то записи. Пусть ебется со своими ууидами сам. Дабы обойти коллизии с ууидами, я хочу вообще не цепляться за ууиды клиентов и вообще не хранить их в базе, вместо этого хранить свои уникальные.
Я, правда, до конца не понимаю механизм работы сервиса. Получается, что у тебя все клиенты могут добавлять записи в базу. При этом идентификаторы создаются ими же, а не тобой. И с этими айдишниками кто в лес, кто по дрова. Правильно?
Тогда надо генерить свой и возвращать клиенту в ответ, пусть они там сами ебутся с маппингом.
Если ты можешь заставить клиентов использовать твой айдишник, то генерь его сам тем же UUID генератором, только проинициализируй его правильно.
Если не можешь, то надо городить композитный ключ у себя, при этом нужно будет как-то уникально идентифицировать клиентов.
Именно так.
Они этого не умеют…
Эх… Обрадовал ты меня!