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

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

G>>>>А в чем смысл "верно моделировать реальность"? тем более что у слов "верно" и "реальность" очень субъективное понимание?
G>>>>Я думаю есть единственно верный способ моделирования — отталкиваться от конкретных решаемых задач. Если нам нужно транзакционно обновить состояние корзины с резервов на складе, то они должны быть в одной базе и работать в одной транзакции.
G>>·>А откуда возникла такая задача "транзакционно обновить состояние корзины с резервов на складе"? По-моему, ты путаешь цель и средство.
G>>Конкретно это из озона.
·>Это ты описываешь конкретное решение некой задачи. Сама задача-то в чём?
Не в курсе чем озон занимается? В основном товары со склада продает. Вот и надо продать не больше чем есть.

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



G>>·>Аналогия. Мне это напоминает давнишние споры cvcs vs dvcs. Ну как типа "нам нужно точно пронумеровать каждый changeset, как в svn. А вот git так не умеет, значит отстой". Вот только git точнее описывает реально происходящее при работе с исходниками, а не случайно придуманные "нам нужно". Не бывает в ральном мире точно пронумерованных changesets. Поэтому svn умер.
G>>Я даже не возьмусь комментировать по пунктам этот опус. Я работал с SVN и git, и первый умер совсем по другим причинам, а не связанным с нумерованные ченджсетов.
·>Да не важно. Подставь любую другую очень "нужную" фичу, которая есть в svn но нет в git.
Так в том и дело, что у СВНа не было преимуществ перед Гит. У Гита был один недостаток — сложность использования, до сих пор два из трех программистов не умеют в гит.

·>Суть моей аналогии, что твоё "нам нужно [xxx]" ты исходишь не из постановки бизнес-задачи, а из конкретного решения в виде монолитной архитектуры и гигантской всемогущей субд в виде одного процесса.
СУБД умеет ровно то, что у умеет — Атомарные изолированные транзакции, сохраняющие согласованность данных и гарантирующие надежность.
Любые реализации таких гарантий вручную дают менее надежный и менее производительный код, который не имеет преимуществ. Никакая теория и философия еще ни разу никому помогли сделать лучше транзакций в БД там, где транзакции решают проблему.

G>>>>Тогда можно атомарность сделать за счет одной бд на одном сервере.
G>>>>СУБД умеет обеспечивать атомарность изменений в рамках одного сервера\бд. Прям гарантировано умеет, в отличие от наколеночных поделок.
G>>·>Да не важно. СУБД это просто такой готовый процесс.
G>>Угу, процесс который умеет это делать, в отличие от твоего процесса, который по умолчанию не умеет и надо прям поприседать чтобы умел.
·>Речь о другом — процесс не один. Можно иметь две субд, в каждой свои локальные транзакции.
И что это даст? Неатомарное, несогласованное, неизолированное изменение данных? В чем смысл?

G>>>>Как это связано? Если они все приходят в итоге на одни сервер? бд например, то задача решаема.
G>>·>Мы можем попытаться их заставить ходить на один сервер, реализуя такую монолитную архитектуру. И это даже как-то будет работать. Пока этот один сервер не ляжет.
G>>У OpenAI как-то не лег с их количеством клиентов и обращений.
·>А там тоже все ходят на один сервер с бд?
Один кластер — один мастер для записи и 15 реплик для чтения. Все транзакции меняющие данные ходят на один сервер.

G>>Если ты сделал оптимальные запросы, а сервер бд лег от нагрузки, то у тебя будет только одна проблема — куда потратить миллионы, которые ты заработал.
·>Он может просто лечь, и без нагрузки.
Сам? Просто так? Реплик нет? Админов нет? Какой смысл это рассматривать как реалистичный сценарий?
Ну даже допустим что у вас сервер может лечь, вы его надежность оцениваете как число X в интервале (0;1) — оба конца не включены.
Если рассмотреть сценарий выше с покупкой товаров в ОЗОН и разнесением транзакций на два сервера, то общая надежность будет равна X^2, что строго меньше Х. То есть надежность двух серверов ниже.


G>>>>И что? Все равно потеряли.
G>>>>В рамках бизес-процесса бывают шаги, где нужна транзакционно, а бывает что не нужна. Я же описывал что резервирование товаров на складе и смена статуса заказа на "зарезервирован" должны быть в одной транзакции
G>>·>А как это решит твою проблему "пользователь плюет на это дело и идет в другой магазин"?
G>>Этой проблемы просто не будет, мы никогда не продадим больше чем есть на складе если резервирование сделаем транзакционно.
·>Я не понимаю как "пользователь плюёт" соотносится с "не продадим больше".
Это относится к недостаткам решения. Так как "пользователь плюет" это потеря денег. Потому что дальше пользователь идет на другой маркетплейс и к тебе возможно уже не возвращается никогда

G>>·>Какую вообще проблему решает эта твоя "одна транзакция"?
G>>Ту самую, которую ты непонятно как хочешь решить.
·>Это какую?
Чтобы пользователь придя за своим товаром получил его.

G>>·>С таким же успехом резервировать можно в одной транзакции, а обновлять статус заказа на "зарезервирован" в другой.
G>>
G>>нельзя
·>Почему? Напомню контекст: МСА.
Выше все описал. Без МСА получается лучше.

G>>·>Вот только в этом случае транзакция резервирования выполняется в БД склада, а транзакция смены статуса в БД заказов. И эти БД могут быть физически распределены и размещены поближе к местам событий.
G>>Ага, и в этом случае статус может стать "зарезервирован", а остаток на складе не уменьшится, и ты будешь разговаривать с недовольными покупателями.
·>Пока сервис склада не вернёт ответ "резервация прошла успешно" мы не обновляем статус заказа в сервисе заказов.
Тогда в этом нет никакого смысла, потому что недостатки есть, а преимуществ нет.

G>>·>Это повод не использовать один процесс. И транзакции, если ими пользоваться, будут распределёнными. Что кошмар и ужас.
G>>С распределенными транзакциями у тебя все ляжет сильно раньше, поэтому на практике под нагрузкой их не используют.
·>Я это собственно и сказал. Так какие транзакции ты предлагаешь использовать в случае нескольких процессов?
Напомню что ОпенАИ не использует распределенные транзакции и живет на одном кластере, то есть все записи приходят в один мастер.