Здравствуйте, vsb, Вы писали:

vsb>Это ты пытаешься какой-то вариант выдумать, где без UUID никак?
Нет, просто удивлён тем, что в 2021 году есть люди, незнакомые с REST.

vsb>Ну можно такой вариант выдумать, и что? Обычно пользователь есть и так или иначе он сможешь разрулить такую проблему самостоятельно. А ты что будешь делать, если получишь 502? Ну попробуешь перевести ещё раз и опять получишь 502. И десять раз получишь 502, и сто раз. Всё равно в итоге всё упадёт (ну или будет гадить в логи без перерыва) и всё.
Вовсе даже не всё равно. В вашем варианте сто 502 могут означать 100 повторов перевода денег, или 100 повторных заказов в магазине.

vsb>Поэтому ответ на твой вопрос — зафиксировать ошибку в логах и более ничего не предпринимать. Поставщик позвонит, пожалуется и разберёмся. А если такое случается два раза, значит будет какой-нибудь алёрт по этому логу. Ну или таки пошевелимся и исправим причину, по которой там этот 502 возникает. Как-то так.
Обычно 502 исправляется очень быстро, потому что его причиной является перезапуск одного из серверов в цепочке. Очень немногие приложения могут себе позволить в такой ситуации просто лечь и требовать ручного перезапуска.
Да ещё и с ручной коррекцией данных — потому, что встроенного способа восстановить синхронность нет, и надо руками проверять, была ли выполнена операция, и на клиентской стороне править базу соответствующим образом.

Здравствуйте, Sinclair, Вы писали:

S> Брр. А какие базы нетолерантны к вставке в середину индекса?

Например MySQL будет плохо на интенсивной вставке в рандомные места pk при большом размере таблицы. Другим "традиционным" БД скорее всего так же будет в разной степени нехорошо (чудес не бывает), но MySQL — это просто хрестоматийный пример грабли, на которую "новички" наступают с завидной регулярностью.

Здравствуйте, Anton Batenev, Вы писали:
AB>Например MySQL будет плохо на интенсивной вставке в рандомные места pk при большом размере таблицы. Другим "традиционным" БД скорее всего так же будет в разной степени нехорошо (чудес не бывает), но MySQL — это просто хрестоматийный пример грабли, на которую "новички" наступают с завидной регулярностью.
Мне очень интересно, как это может работать.
Что за индексы использует MySQL?
B-Tree, Hash, и Bitmap индексам совершенно всё равно, в каком порядке идёт вставка. Точнее, для некоторых из них могут быть интересные эффекты, связанные с блокировками (если они используются), но они как бы имеют второй порядок малости по сравнению с основным членом разложения асимптотики, да ещё и работают "в другую сторону", ускоряя вставку при равномерном её разбросе по диапазону ключа.

Здравствуйте, Sinclair, Вы писали:

S> AB>Например MySQL будет плохо на интенсивной вставке в рандомные места pk при большом размере таблицы. Другим "традиционным" БД скорее всего так же будет в разной степени нехорошо (чудес не бывает), но MySQL — это просто хрестоматийный пример грабли, на которую "новички" наступают с завидной регулярностью.
S> Мне очень интересно, как это может работать.
S> Что за индексы использует MySQL?

Как-то так: innodb-page-merging-and-page-splitting.

Здравствуйте, Anton Batenev, Вы писали:
AB>Как-то так: innodb-page-merging-and-page-splitting.
Ну, там начато за здравие, а закончено за упокой.
В том смысле, что сначала идёт неплохой рассказ про B-деревья, и их реализацию в MySQL.
А вот в разделе MyPrimaryKey начинается булшит.
То есть сняты корректно, но объяснение причин явно бредовое. Вот эта вот фраза не имеет ничего общего с действительностью:

while the semi-random nature of the UUID will cause a significant “sparse” page distribution (causing a higher number of pages and related split operations).

Автор плохо учил математику, и не понимает, что коэффициент полноты страниц в B-дереве слабо связан с распределением вставки.
Более того, вставка в конец гарантирует fill-factor в 50%
Разница в производительности, которую наблюдает автор, связана с размером ключа, а не со случайностью порядка.
В MYSQL UUID хранится как строка, и занимает 36 байт. Естественно, индекс по 36-байтовому ключу потребует больше страниц, чем индекс по 4-байтовому ключу.

Здравствуйте, Sinclair, Вы писали:

S> Разница в производительности, которую наблюдает автор, связана с размером ключа, а не со случайностью порядка.

Размер ключа конечно влияет, но на больших табличках его влияние незначительно за счет размера связанных данных. Ты можешь провести подобный же эксперимент с random uint64 — результат будет плюс-минус одинаковый (в сравнении со вставкой в хвост).

Если интересно, то можно почитать еще вот это: store-uuid-optimized-way. А вообще подобных исследований и докладов на всяких HighLoad-подобных конференциях в то время было достаточно много, если покопаться.

S> Более того, вставка в конец гарантирует fill-factor в 50%

IRL заполнение будет близко к 100% — так же легко подтверждается натурным экспериментом.

В>>Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).
S>А можно попо дробнее с этого места?
S>Как именно вы предлагаете получать ID при сохранении? Да ещё и так, чтобы не было тормозов?
S>Я знаю три способа, из них два — неправильные:
S>1. Берём и делаем POST /mytransactions/<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
S>При получении таймаута, 10060, или 50x мы начинаем дорогостоящую процедуру восстановления синхронности клиента и сервера
S>2. Берём и делаем POST /mytransactions/<CRLF>X-Request-ID: 9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}.
S>Тут мы хотя бы имеем возможность корректно обработать фейлы. Но эта обработка достаточно неудобна: нам надо иметь какой-то временный ID нашей транзакции (а точнее — реквеста по её созданию), который потом заменять на "настоящий" ID, который вернёт сервис.
S>3. Ну, и нормальный способ — берём и делаем PUT /mytransactions/9b74165a-b248-4e99-9d57-a8066878e7ca<CRLFCRLF>{"from":112312312, "to": 8908094654, "amount": 500.00}
S>ID транзакции известен в момент её порождения, он ничем не будет заменяться, ждать сервера для его получения не надо.

Я не уверен, что мы говорим об одном и том же.
Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?

Здравствуйте, Ватакуси, Вы писали:

В> Я не уверен, что мы говорим об одном и том же.
В> Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В> Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?

Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.

В>> Я не уверен, что мы говорим об одном и том же.
В>> Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>> Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
Повторить. Если сохранилось, то 201 и ответ. В чём сложность?

·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
Это что-то меняет?

Здравствуйте, Ватакуси, Вы писали:

В>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
Как сервер отличит повтор от нового НЕЧТО?

В>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>Это что-то меняет?
Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.

Здравствуйте, ·, Вы писали:

В>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
·>Как сервер отличит повтор от нового НЕЧТО?

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

В>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
·>Как сервер отличит повтор от нового НЕЧТО?
Куча способов. От целостности ДБ (уникальные ключи и т.п.) до проверки модели ДБ на сервере.
Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.

В>>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>>Это что-то меняет?
·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
Они же либо пачкой отправляются, либо отдельными запросами. В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.

Здравствуйте, gyraboo, Вы писали:

В>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
G>·>Как сервер отличит повтор от нового НЕЧТО?
G>Если это нечто настолько важное, то для него можно использовать натуральный ключ. В этом случае проверка наличия натурального ключа в БД покажет, сохранилось оно или нет.
Ок. Давай конкретный пример, пусть нечто заказ: "Принесите мне чашку кофе". Как сервер отличит повтор заказа, т.к. клиент не услышал ответа и повтор заказа, т.к. клиент хочет ещё одну чашечку? В этом случае ключом натурально становится уникальный идентификатор заказа. Который проще всего сгенерить на клиенте.

Здравствуйте, Anton Batenev, Вы писали:

AB> Другими словами, использовать сейчас int в качестве pk — это или глупость или целенаправленная отложенная диверсия.

А long?

Упдате: увидел ответ выше. Вопрос закрыт.

Здравствуйте, ·, Вы писали:

В>>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
G>>·>Как сервер отличит повтор от нового НЕЧТО?
G>>Если это нечто настолько важное, то для него можно использовать натуральный ключ. В этом случае проверка наличия натурального ключа в БД покажет, сохранилось оно или нет.
·>Ок. Давай конкретный пример, пусть нечто заказ: "Принесите мне чашку кофе". Как сервер отличит повтор заказа, т.к. клиент не услышал ответа и повтор заказа, т.к. клиент хочет ещё одну чашечку? В этом случае ключом натурально становится уникальный идентификатор заказа. Который проще всего сгенерить на клиенте.

Если ключ генерится случайно, то имхо есть вероятность коллизии. Я понимаю, что эта вероятность мизерна, но "осадочек остается", я до сих пор не могу привыкнуть к гуидам, не покидает ощущение что это плохая технология и когда-нибудь она выстрелит по человечеству такой неприятной коллизией, таким "черным лебедем", что мало не покажется. Не лучше ли в таком случае генерить уникальный ключ с привязкой к названию кафешки (или к её гео-координатам) и ко времени заказа? Например:
STARBUCKS-4756-07-12-2021-16-22-56-045-UTC
вместо
2062b11c-4ecb-42aa-be35-798203a758f9

В этом случае такой натуральный ключ имеет минимальные шансы коллизии, т.к. в одну и ту же миллисекунду маловероятен заказ нескольких кружек кофе в одной кафешке. Но даже если и вероятен, например если касс несколько, то в ключ можно добавлять и id кассы:
STARBUCKS-4756-07-12-2021-16-22-56-045-UTC-545663

С таким id и работать приятнее, нет того неприятного ощущения что он "чуховый" и "коллизийный", чем с каким-то непонятным гуидом, который сгенерён по непонятному алгоритму.

Здравствуйте, Ватакуси, Вы писали:

В>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
В>·>Как сервер отличит повтор от нового НЕЧТО?
В>Куча способов.
Опиши конкретно, с подробностями хотя бы один из них.

В>От целостности ДБ (уникальные ключи и т.п.)
Эээ.. Т.е. чтобы у нас был уникальный ключ нам нужно иметь уникальный ключ?..

В>до проверки модели ДБ на сервере.
Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.

В>Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.
Это не то что идея, это неизбежный вариант.

В>>>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>>>Это что-то меняет?
В>·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
В>Они же либо пачкой отправляются, либо отдельными запросами.
Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.

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

Здравствуйте, gyraboo, Вы писали:

G>·>Ок. Давай конкретный пример, пусть нечто заказ: "Принесите мне чашку кофе". Как сервер отличит повтор заказа, т.к. клиент не услышал ответа и повтор заказа, т.к. клиент хочет ещё одну чашечку? В этом случае ключом натурально становится уникальный идентификатор заказа. Который проще всего сгенерить на клиенте.
G>Если ключ генерится случайно, то имхо есть вероятность коллизии. Я понимаю, что эта вероятность мизерна, но "осадочек остается", я до сих пор не могу привыкнуть к гуидам, не покидает ощущение что это плохая технология и когда-нибудь она выстрелит по человечеству такой неприятной коллизией, таким "черным лебедем", что мало не покажется.
This number is equivalent to generating 1 billion UUIDs per second for about 85 years.
https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions

А если сделать, чтобы данные устаревали (т.е. удалять очень старые заказы), то вообще всё невероятно.

G>Не лучше ли в таком случае генерить уникальный ключ с привязкой к названию кафешки (или к её гео-координатам) и ко времени заказа?
Это аналогично UUID v1 или v2.

Здравствуйте, Ватакуси, Вы писали:

В>Я не уверен, что мы говорим об одном и том же.
Об одном, об одном.
В>Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?

В>>>>·>Клиент создал НЕЧТО. Послал серверу команду "сохрани", связь оборвалась и ответа клиент не увидел. Как клиент сможет узнать, сохранилось НЕЧТО или нет? Должен он ещё раз послать это НЕЧТО для сохранения или нет? Если оно сохранилось, как получить этот ID сохранённого?
В>>>>Повторить. Если сохранилось, то 201 и ответ. В чём сложность?
В>>·>Как сервер отличит повтор от нового НЕЧТО?
В>>Куча способов.
·>Опиши конкретно, с подробностями хотя бы один из них.
Хорошо.

В>>От целостности ДБ (уникальные ключи и т.п.)
·>Эээ.. Т.е. чтобы у нас был уникальный ключ нам нужно иметь уникальный ключ?..
Нет, у тебя всегда (ну, почти) есть уникальные поля (или их сочетания).
Нельзя, например, создать документ с ровно таким же названием как уже существующий (уникальность по имени) или в пределах определённого раздела (уникальность по двум или более полям).

В>>до проверки модели ДБ на сервере.
·>Это как? Модели чего? Проблема в рассинхронизации между клиентом и сервером. Сервер не знает что у клиента, клиент не знает что у сервера.
Ну, спрашиваещь базу, кэш или что-нибудь ещё есть у меня такой объект с такими полями или нет.

В>>Полагаться на ID с клиента для подобного — это мягко говоря — так себе идея.
·>Это не то что идея, это неизбежный вариант.
Ну, прислал ты два разных ID, но объекты 100% одинаковые. У тебя база или служба ВСЁ РАВНО должны это обработать. Тогда зачем платить больше?

В>>>>·>Более того... Клиент может создать пачку НЕЧТ и послать на сохранение. Или продолжать создавать новые НЕЧТЫ пока сервер сохраняет предыдущие.
В>>>>Это что-то меняет?
В>>·>Тем, что НЕЧТЫ надо между собой как-то идентифицировать ещё до сохранения на сервере.
В>>Они же либо пачкой отправляются, либо отдельными запросами.
·>Т.е. ты должен неявно отправить N штук и потом ждать N назад, сопоставляя по очередности. Вариант, конечно, но опять всё сломается при сетевых ошибках, да и не очень очевидно в чём преимущества.
Не знаю про ваших клиентов, но у меня за такое отвечает библиотека, которая выполняет запросы. Или среда исполнения.

В>>В любом случае ты получишь ответ соответсвующий каждому из них. Даже, если это асинхронно выполнять.
·>Асинхронно вообще бардак начаться может, если, скажем, сервер работает в нескольких экземплярах и в итоге запросы могут обрабатываться не по порядку.
Ну и что? Вернуться же они куда надо и кому надо.

В>>Твой клиент создал НЕЧТО. Но без ID. Далее он хочет сохранить это нечто. В этот момент ему и присваивается ID (который может быть возвращён вместе с ответом). Вернуться же может и многое другое (вычислимые поля, временные метки и т.п.). Их же никто на клиенте не создаёт, так?
В>>Зачем создавать заранее ID, если объект (или запись) всё равно никуда ещё не сохранён?
S>Повторю вопрос: что будет в вашей схеме, если клиент отправил объект на сохранение, но подтвержения (и ID вместе с ним) не получил?
S>Как он отличит ситуацию "запрос потерян на пути к серверу" от ситуации "ответ потерян на пути от сервера"?
Так если нет соединения в принципе, то никак.
Если оно есть, то повтор. Далее через 200, 201 или 409 можно управлять "пониманием".
Но, к слову, в современных клиентах вообще никто не парится. Не прошло, ошибку вернул и всё. Пусть "кто-нить другой" пытается повторить.