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

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

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

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


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

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

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

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

·>С таким же успехом резервировать можно в одной транзакции, а обновлять статус заказа на "зарезервирован" в другой.

нельзя

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


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

G>>>>У меня в проекте сейчас работает C# 10-летней давности. Да, неэффективно по сравнению с текущей версией, но работает.
G>>·>Именно. А начнёшь переезд — заколебаешься для большого проекта.
G>>Так у меня большой проект. За 10 лет огого сколько всего написали.
·>Так и я о том же. В рамках МСА была бы группка мелких проектов, то можно было бы есть слона по частям. А сейчас ты в тупике.

У меня большой проект, который состоит из группы мелких проектов, которые примерно 8 лет усиленно пилили. В 2018 году взяли курс на микросервисность. Сейчас огромное количество проблем с консистентностью данных и быстродействием из-за МСА, что приходится почти целые сервисы переписывать, чтобы обеспечить надежность.
Я думаю за годик смогу запинать все это, чтобы модульный монолит получился.