Стоит ли использовать uuid или есть что-то еще?

Question

[nepster-web]

Часто возникает задача, когда необходимо "укомплектовать" объект и особенно знать его идентификатор до того, как он полетит в базу данных.

Этого можно достичь с помощью uuid, однако тут минусов куда больше чем плюсов:
- Падает производительность при выборке и вставке
- Падает производительность при JOIN
- База вырастает

Поэтому вопрос следующий:
Как без особого вреда для базы можно генерировать id для объекта за ранее ?

Comments

[sim3x]

>Часто возникает задача, когда необходимо "укомплектовать" объект и особенно знать его идентификатор до того, как он полетит в базу данных.

Нет, не воникает

[tkutru]

sim3x +1. Зачем это знать заранее, можно сохранить и получить ид.

[nepster-web]

tkutru: что если мне нужно некоторые данные сохранить до того, как я смогу сохранить основную запись ?

[tkutru]

nepster-web зачем?

[lega]

tkutru: sim3x: Есть пачка примеров, в основном связаны с оптимизацией.

Например клиент прислал данные, мы ему сразу вернули результирующий ид и отпустили клиента, а приложение дальше начинает транзакцию с сохранением в этот ид.

Или например, когда получить ид не так ловко, есть однонаправленный поток задач (через rabbitmq), мы сразу отдали клиенту ид, а удаленный воркер уже не спеша выполняет задачу и ложит результат по этому ид.

Ещё MongoDB только так и работает, если вы не указали ид (ObjectId) он автоматом генерируется на клиенте перед отправкой на сервер. В итоге что-бы иметь ид не нужно ждать ответа от сервера, когда он закончит.

[tkutru]

>>Например клиент прислал данные, мы ему сразу вернули результирующий ид и отпустили
lega ну так ничто не мешает сейвить в табличку, а потом дорабатывать обработчиком, как вы написали далее.

>>В итоге что-бы иметь ид не нужно ждать ответа от сервера, когда он закончит.
но так и не будет понятно, сохранился результат или нет. D - durability.

[lega]

tkutru: > ну так ничто не мешает сейвить в табличку

Можно, но будет медленнее

> сохранился результат или нет

Это уже совсем другой вопрос, задачи бывают разные

[sim3x]

lega: насколько медленнее?

[lega]

sim3x: Например монга с ожиданием ответа от сервера 2-3k rps, без ожидания 10k rps на моем лептопе

[lega]

sim3x: правда это если мерять в ограниченное кол-во потоков, но все же

[sim3x]

lega: а замеры на субд, а не на монге, есть?

[lega]

sim3x: были но уже ничего не помню, но если вам интересно можете прикинуть (сравнить) разницу между построчным комитами и одним bulk комитом, второй будет явно быстрее.

[lega]

sim3x: вот какие-то цифры: stackoverflow.com/questions/1793169/which-is-faste... bulk получился в 5 раз быстрее на этом примере

[sim3x]

lega: только ето не будет иметь отношения к uuid

[sim3x]

lega: опять же
Интересует только результат у субд

[lega]

sim3x: Вы пытаетесь перевести тред в другую плоскость, я вам показал где это имеет смысл (ид до запроса), впрочем вы против ничего не сказали. Если у вас есть что сказать, выкладывайте.

[lega]

Ещё такой пример - когда конечный ид генерирует сам клиент (при этом клент должен быть доверенным), в этом случае можно балансировать, если нода тормозит или упала, то можно отправить на другую ноду не боясь о дублях (они высекаются по ид)

[sim3x]

lega: нет, я пытался получить хоть какие-то аргументы в пользу подхода

[tkutru]

sim3x если у вас не супер-пупер хайлоад можете сейвить в табличку и не париться.
Я имел дело с распределенной архитектурой, пиковыми 3*10^4 rps на нелегкие бекенды и это все спокойно работало через очереди с отдачей id через предварительное сохранение в СУБД.
Если речь про что-то еще большее + ограничение по бюджету, то можно как lega написал. Но там параллельно еще куча вопросов возникнет, станет не до этого) В хайлоадах у кого нормальная архитектура и шардирование, тот и молодец.

Answer 1

[Dmitry MiksIr]

>Как без особого вреда для базы можно генерировать id для объекта за ранее ?

SELECT nextval('name_of_sequence');

Answer 2

[lega]

Варианты:
1) Генерируемый уникальный ид (guid)
2) Нумератор, нужно где-то хранить глобальный счетчик, redis/db
3) Префиксы/суфиксы, каждый писатель имеет свой префикс и нумератор, например
Писатель 1: 10001, 10002, 10003...
Писатель 2: 20001, 20002, 20003...
Писатель 3: 30001, 30002, 30003...
Либо по модулю, писатель 1 пишет только нечетные, писатель 2 только четные

Answer 3

[Falseclock]

А зачем знать заранее? Не представляю себе такого.
Если после внесения новой строки в базу хотите знать уникальный ID сформированный в базе, то делаете так

INSERT INTO table_name (column1,column2) VALUES (value1,value2) RETURNING table_column_id;