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

AB>Вторая проблема больше организационная, нежели техническая и связана с тем, что когда у тебя pk выглядит как int, инкрементится как int, и сравнивается как int, то большинство потребителей твоей информационной системы хардкорно заложатся на то, что это int, даже если в документации (которую традиционно никто не читает) красным жирным шрифтом будет написано обратное.

Практически всегда это решается изоляцией базы от клиентов через микросервис.

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

bnk>>1. генерация id на клиенте. Зачастую сейчас объекты создаются прямо на клиенте (в браузере например). Для int это тупо невозможно.
bnk>>2. репликация или шардирование. как разбивать объекты на несколько баз без пересечений по id, как мержить две реплики (особенно актуально если поле автоинкремент — тогда вообще ппц)

В>Как часто ты с эим сталкивался?

Как-то постоянно

Практически для любого веб-приложения с которым я сталкивался, первое (необходимость генерации id на сервере) является проблемой.

Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база)

Элементарный импорт-экспорт данных в каком-нибудь текстовом формате.
Объекты в экспортируемом файле должны иметь (глобально) уникальный идентификатор, иначе будет каша.
Где они его возьмут, если его нет в базе?

bnk>>>1. генерация id на клиенте. Зачастую сейчас объекты создаются прямо на клиенте (в браузере например). Для int это тупо невозможно.
bnk>>>2. репликация или шардирование. как разбивать объекты на несколько баз без пересечений по id, как мержить две реплики (особенно актуально если поле автоинкремент — тогда вообще ппц)

В>>Как часто ты с эим сталкивался?

bnk>Как-то постоянно

bnk>Практически для любого веб-приложения с которым я сталкивался, первое (необходимость генерации id на сервере) является проблемой.
Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба (в монолите или нет — неважно).

bnk>Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база).
В век микросервисов вообще непонятно, зачем это может кому-нибудь потребоваться. Базы же маленькие. Если таки у тебя огромная база по каким-то причинам, то для этого есть другие архитектурные решения.

bnk>Элементарный импорт-экспорт данных в каком-нибудь текстовом формате.
bnk>Объекты в экспортируемом файле должны иметь (глобально) уникальный идентификатор, иначе будет каша.
Это почему ещё?

bnk>Где они его возьмут, если его нет в базе?
Понятно, что в базе он должен быть. Только как это связано с гуидами?

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

B>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
Тормоза же, плюс поддержка этой никому не нужной службы.

bnk>>Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база).
В>В век микросервисов вообще непонятно, зачем это может кому-нибудь потребоваться. Базы же маленькие. Если таки у тебя огромная база по каким-то причинам, то для этого есть другие архитектурные решения.

Так я еще эти микросервисы толком разглядеть не успел, а они вроде уже всё

Автор: BlackEric
Дата: 22.11.21

?

bnk>>Где они его возьмут, если его нет в базе?
В>Понятно, что в базе он должен быть. Только как это связано с гуидами?

Не понял. Мы же и говорим про базу. Что он должен там быть. Гуид.

B>>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
bnk>В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
bnk>Тормоза же, плюс поддержка этой никому не нужной службы.
Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).

bnk>>>Разделение базы на несколько, допустим по регионам, или просто создание архива по датам (отдельная база).
В>>В век микросервисов вообще непонятно, зачем это может кому-нибудь потребоваться. Базы же маленькие. Если таки у тебя огромная база по каким-то причинам, то для этого есть другие архитектурные решения.

bnk>Так я еще эти микросервисы толком разглядеть не успел, а они вроде уже всё

Автор: BlackEric
Дата: 22.11.21

?
Я сильно в этом сомневаюсь-))) Уже накопилась изрядная индусская масса, которая в принципе иначе не работает. Если ты говоришь, что у MS есть минусы, у них сразу грустнеют глаза.

bnk>>>Где они его возьмут, если его нет в базе?
В>>Понятно, что в базе он должен быть. Только как это связано с гуидами?

bnk>Не понял. Мы же и говорим про базу. Что он должен там быть. Гуид.
Тогда уточни проблему.

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

Б>Почему? Какие проблемы могут появиться?

Лично знаю проект, где упёрлись в размер int32 для ключа. Срочно переделывали на int64.

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

B>>> Я вот вообще не уверен, что это здорово — создавать ID на клиенте. Более того, ни разу этого не видел нигде. Для этого есть служба
bnk>В смысле, чтобы создать новый объект, ты делаешь запрос к этой службе что ли?
bnk>Тормоза же, плюс поддержка этой никому не нужной службы.

Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

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

vsb>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

Например, если на клиенте уже есть собственная модель со связями.
Работа оффлайн например, и сохранение данных в localstorage или indexeddb.

Хотя этот случай тоже в какой-то степени синхронизация. Так что можно наверное обобщить и сказать,
что нужда в гуидах появляется, когда появляется больше одной "базы" (или другого хранилища объектов).

В случае веб-приложения, такой "базой" может быть любой браузер пользователя по сути.

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

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

Б>>Почему? Какие проблемы могут появиться?

MD>Лично знаю проект, где упёрлись в размер int32 для ключа. Срочно переделывали на int64.

Да, например для логов int32 может не хватать, но тут всё зависит от того, как часто в него писать, пока у меня имеется единственный случай, где стабильно пишется около 1.5К записей в секунду, т.е. в данном случае будет израсходован за месяц.
Зато вполне хватает для таких обыденных вещей как идентификатор товара (если конечно не глобальный уровень типа eBay/AliExpress/Amazon ...), новостной статьи, документа в корпоративной системе, или сообщения на этом форуме.

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

vsb>>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?

bnk>Например, если на клиенте уже есть собственная модель со связями.
bnk>Работа оффлайн например, и сохранение данных в localstorage или indexeddb.

bnk>Хотя этот случай тоже в какой-то степени синхронизация. Так что можно наверное обобщить и сказать,
bnk>что нужда в гуидах появляется, когда появляется больше одной "базы" (или другого хранилища объектов).

bnk>В случае веб-приложения, такой "базой" может быть любой браузер пользователя по сути.

Конечно uuid упрощает синхронизацию баз, но этот случай типичным назвать явно нельзя.

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

AB>Для больших баз уже никаких int быть не должно.

Т.е. для миллиарда записей перестроение индекса для каждой вставки это самое оно?

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

IT> AB>Для больших баз уже никаких int быть не должно.
IT> Т.е. для миллиарда записей перестроение индекса для каждой вставки это самое оно?

Уточни пожалуйста что именно ты имеешь ввиду? Если ты про вставку в середину индекса, то я ранее дал ответ на этот вопрос — uuid должен монотонно возрастать (таким свойством например обладает UUIDv1 после перестановки байт местами, но ничто не мешает генерировать собственный uuid-like идентификатор длиной 128 и более бит). В реальной практике, когда есть множество независимых генераторов, мы можем с высокой вероятностью гарантировать, что в худшем случае будет перестраиваться только хвост индекса, что существенно менее затратно.

Впрочем, есть базы относительно толерантные к вставке в середину индекса при наличии достаточного аппаратного обеспечения (из публично доступных HBase например).

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

scf> AB>Вторая проблема больше организационная, нежели техническая и связана с тем, что когда у тебя pk выглядит как int, инкрементится как int, и сравнивается как int, то большинство потребителей твоей информационной системы хардкорно заложатся на то, что это int, даже если в документации (которую традиционно никто не читает) красным жирным шрифтом будет написано обратное.
scf> Практически всегда это решается изоляцией базы от клиентов через микросервис.

Эм, ну так в базу никогда напрямую и не пускают, а только через какое-нибудь api. Но как это поможет, если на выходе этого api что-то в стиле:

{
  "id": "123456",
  "value": "Hello World!"
}

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

В> bnk>Тормоза же, плюс поддержка этой никому не нужной службы.
В> Ну, конечно. Никаких тормозов нет (это делается при сохранении, всё равно же сохранять).

Если ты в фоне не подкачиваешь id-шники в пул локально с достаточной скоростью, а ходишь каждый раз в службу генерации последовательности, то есть "тормоза" минимум в RTT (такого счастья на практике конечно никогда не бывает). Дополнительно ты ожидаешь блокировок от других клиентов, периодически ловишь tcp retransmit-ы и прочие прелести работы сети включая ее отказы. И это мы еще не затрагиваем организацию самой службы генерации, ее отказоустойчивость, балансировку нагрузки, синхронизацию между нодами и т.д.

Служба подобного типа имеет смысл для распределенных транзакций/блокировок (ну просто потому что по другому ты не сделаешь), а вот при генерации id куда как проще и надежнее иметь локальный независимый генератор.

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

Здравствуйте, vsb, Вы писали:
vsb>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?
А если при создании ты получил не ID, а 502 Gateway timeout? Каким образом узнать, был ли объект создан, или ещё нет?

Здравствуйте, Anton Batenev, Вы писали:
AB>Впрочем, есть базы относительно толерантные к вставке в середину индекса при наличии достаточного аппаратного обеспечения (из публично доступных HBase например).
Брр. А какие базы нетолерантны к вставке в середину индекса?

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

vsb>>Создаёшь новый объект, тебе возвращается его ID. Вроде все так делают. Зачем тебе нужен ID ещё до того, как объект был создан?
S>А если при создании ты получил не ID, а 502 Gateway timeout? Каким образом узнать, был ли объект создан, или ещё нет?

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

Здравствуйте, vsb, Вы писали:
vsb>Никаким, показываешь пользователю, что произошла ошибка, а дальше пусть сам разбирается.
Офигенно придумано. А если пользователя нет — это у нас фоновый процесс? Ну, там, мы получили подтверждение поставки, и теперь надо деньги перевести поставщику?

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

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

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

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