Как сгенерировать уникальный число int64 ?

Question

[becks]

Знаю вопрос криво звучит, попытаюсь объяснить на пальцах.

Есть 2 хранилки, в обе нужно укладывать данные по некоторым сущностям. Часть данных по каждой сущности попадает в одну систему, часть в другую. Необходимо организовать возможность объединить данные для требуемой сущности.
Идея генерировать уникальный ключ и хранить его в обеих системах. Хотели использовать GUID. Но возникла проблема - одна из систем использует в качестве первичного ключа только int64. GUID -128 бит.

Есть ли какая-нибудь возможность генерировать уникальный int64?

Comments

[becks]

Пытался все обобщить, в итоге плохо написал. Первая система - это Oracle. И будет не 1 сервер, а несколько. Ключ нужно генерировать уникальным на уровне всех серверов, а не конкретной машины. По этой причине банальный авто инкремент не подойдет.

[ldv]

becks: Что мешает генерировать уникальный ID средствами Oracle на одной машине и использовать это значение на других? Источник ID один - коллизий нет

[becks]

ldvldv: ничего не мешает, тоже вариант. Спасибо.

Answer 1

[Иван Филатов]

Зачем генерировать long (Int64) значение?
Если ключ long целочисленный - то просто добавляйте записи c MAX IDENTITY + 1

Comments

[becks]

А если укладывает данные в систему много потоков\клиентов?

[Иван Филатов]

becks: если база данных у вас одна - то генерируете в ней. AntoIncrement тот же самый.

просто различайте GUID и LONG.

LONG - это по простому циферки от 0 до 9 223 372 036 854 775 807

в MS SQL это тип BIGINT

[Иван Филатов]

becks: какая у вас СУБД ?

[becks]

Иван Филатов: Я написал выше в комментарии к вопросу. Прошу прощения, совсем забыл указать этот момент.

[Иван Филатов]

becks: тогда делается так, два варианта:

1. составной ключ - первый ключ - ID сервера, второй сам LONG.

2. разделите LONG на количество серверов - получите шаг.
первый сервер будет генерировать с 0 до ШАГА-1
второй сервер генерирует с ШАГ до ШАГ*2-1
и т.д.

задать начало и конец генерации поля можно в настройкой конкретной таблицы.

в MS SQL знаю как. в Oracle не работал. но такое тоже есть там 100%.

ваши LONG значения не будут пересекаться между серверами.

[becks]

Иван Филатов: Да, это уже вариант. Спасибо.

Answer 2

[maaGames]

Генерируешь GUID и берёшь для него остаток от деления на 64 битное простое число. Или ксоришь первые 64 бита со вторыми 64 битами (но тут возможны конфликты уже).

Comments

[becks]

А таким образом точно будет без коллизий?

[becks]

Я имел ввиду решение с деление на 64 битное простое число. И важно ли какое именно простое число взять?

[maaGames]

becks: Если брать остаток от деления на простое число, то вероятность коллизий ооооочень низкая. С учётом того, что GUID всего вдвое больше остатка, то на практике вероятность коллизий почти нулевая. Главное, чтобы делитель 65 битным был простым числом, тогда остаток будет 64 бита.

[becks]

maagames.ru: Спасибо.

[AxisPod]

GUID и сам-то не гарантирует строгой уникальности в целом, только в определенной замкнутой системе. Ну и к примеру для шардинга всё куда как проще может быть. Если знаете какое хранилище использовать, то спокойно заводите счетчик для каждого хранилища и выставляете нужное кол-во старших бит, чтобы точно идентифицировать нужную ноду. В вашем случае всего 1 бит. Или даже грубо можно использовать знаковое число, для одной ноды плюсовать от 1, для другой минусовать от -1.

Answer 3

[Андрей Язу]

Если сущностей меньше миллиона, то можно просто генерировать random int64 - шансы на коллизию - меньше 1 к 10 000 000. Я бы поставил на противоположное ;) Подробнее