Возможно, дело не в AI. А просто пузырь на рынке труда стал сдуваться (не из-за AI а в силу естественных экономических процессов.)
Пример : Работаю в компании. Развиваем ERP систему. Параллельно, 1 разработчик ведет проект на C#. В помощь ему открыли вакансию (чтобы мог в отпуск хотя бы уходить спокойно). Поразились числом соискателей доступных на рынке (их стало существенно больше). Каждый 2-й на собеседовании спрашивает, насколько у нас тут надежно и надолго ли проект. На рынке много спецов которых сократили. Причем нередко рубили целыми командами.
>> и через 3 года когда понадобятся трактористы - учить будет некого. Мне кажется, что процессы не происходят так стремительно. Люди же не хомячки со сроком жизни 1,5 - 5 лет И потребность в программистах не скачет на 100 % за 3 года Похоже что вы запаниковали преждевременно. Либо сгущаете краски. Зачем ?
>> Что именно улучшить? Скорость работы? Надежность? Время написания?
Добавлю еще к предыдущим.
Возможно, будет быстрее работать. Но тут может по-разному быть. Транзакций будет больше, поэтому может быть медленнее из-за более частых коммитов. Это фактор замедления.
Но!
Если строк в заявке будет много, то в случае одной транзакции (как у вас) растет время ожидания так как пока 1-я сессия не завершит резервирование всей заявки с Х строками, другая сессия которая, возможно, ее ждет, не начнет работу, ждет пока блокировки снимутся. В случае коротких транзакций они меньше будут друг другу мешать, меньше ожидание. Быстрее работа.
Какой из факторов сильнее скажется заранее сложно спрогнозировать. Если строк много и большая конкуренция за остатки то вариант с 1 транзакцией на строку будет быстрее. А если нет, то может быть обратный эффект.
>> Что именно улучшить? Скорость работы? Надежность? Время написания?
Снизить вероятность блокировок - я об этом явно написал.
Масштабируемость будет лучше. Если вдруг изменятся условия и в заявке для резервирования число строк увеличится например в 100 - 1000 раз, то работать будет норм. И примерно с той же скоростью на 1 строку (меньше будет ожидание разными сессиями друг друга). Конечно код будет сложнее, как вы справедливо указали. Но ничего бесплатно не бывает.
>> Можете пример кода привести, который демонстрирует эти улучшения?
Собственно, я описал идею и пошагово все привел. что там непонятного ? Или это придирка такая ? Ну кто хочет понять тот ищет возможности, кто не хочет - ищет причины.
>> Я пока увидел, что для реализации цикла с транзакциями внутри, а не снаружи нужен фоновый процесс, который будет отменять незавершенные брони. Тогда как в моем примере из статьи такой процесс не нужен.
Он потребуется для обработки аварийных ситуаций как минимум. Но и в вашем примере он нужен, о чем я указал.
Могу подробнее пояснить.
Вот приходит в вашем примере заявка - делается резерв, коммитится транзакция, а тут все падает (например электричество вырубилось или виртуальная машина грохнулась). Транзакция закоммичена. А оплата не прошла. Как в вашем примере решалась бы эта проблема ? Все равно нужно стороннее вмешательство для снятия резерва или восстановления сессии в которой можно было бы провести оплату.
>> Если для вас ACID и гарантии СУБД это "догмы" и "ярлыки", тогда вы правы.
Вы просто подменяете понятия, приписываете мне то что я не говорил, а потом "опровергаете". Гаденький, но детский приемчик. И совсем вас не украшает. На него никто уже не ведется.
Касательно транзакций и ACID - а кто вам сказал что вся обработка должна идти в одной транзакции ? Это совсем не обязательно. Все определяется задачей. Тем на какие по смыслу шаги можно разделить обработку (а в некоторых случаях и распараллелить, но это уже другая тема). В зависимости от условий, допустимо последовательность действий разбивать на несколько последовательных транзакций. И это не нарушение ACID. Нужно просто понимать что делаешь и соотносить с практикой.
"гораздо менее надёжный, чем использование транзакций."?
Вы серьезно?
Да вы видимо никогда не сталкивались с кучей блокировок из за больших транзакций. Вам что важно, надежность или мнимая "простота"? И зачем она будет если повиснет под нагрузкой.
Насчет резервов - можно предположить экзотический сценарий когда из за падения обработки останется зависший резерв по части строк. Так он по куче причин может быть. Например в вашем случае, резерв полностью прошел но оплата не прошла. Или электрисество вырубилось. Та же ситуация только больше зарезервированных строк.
Для разруливания таких ситуаций делают фоновые обработки, которые снимаю старые ненужные рещервы или такие вот аварийные заказы. Обычная ситуация. И вы без такой обработки не обойдетесь даже с вашим вариантом длинных транзакций.
А, не. Нагуглил оригинал. "Их" - речь об алгоритмах а не о багах.
Правило 4. В сложных алгоритмах больше ошибок, чем в простых, и их гораздо труднее РЕАЛИЗОВАТЬ.
Явно ошибка перевода. В оригинале наверно стоит "realize" - в данном контексте в значении "понять, осознать"
Целые команды рубанули?
А туда ли вы смотрите ?
Возможно, дело не в AI. А просто пузырь на рынке труда стал сдуваться (не из-за AI а в силу естественных экономических процессов.)
Пример : Работаю в компании. Развиваем ERP систему. Параллельно, 1 разработчик ведет проект на C#. В помощь ему открыли вакансию (чтобы мог в отпуск хотя бы уходить спокойно). Поразились числом соискателей доступных на рынке (их стало существенно больше). Каждый 2-й на собеседовании спрашивает, насколько у нас тут надежно и надолго ли проект. На рынке много спецов которых сократили. Причем нередко рубили целыми командами.
Вот где корень проблемы.
а вы все AI, AI ...
Не там ищете проблему.
>> и через 3 года когда понадобятся трактористы - учить будет некого.
Мне кажется, что процессы не происходят так стремительно. Люди же не хомячки со сроком жизни 1,5 - 5 лет
И потребность в программистах не скачет на 100 % за 3 года
Похоже что вы запаниковали преждевременно. Либо сгущаете краски. Зачем ?
>> и потребность в людях которые разбираются в этом коде только вырастет
Вопрос в том сколько им будут платить как раньше или значительно меньше, ожидая что ресурс стал дешевле. В этом вся соль.
10 ку уже снимпют с поддержки. Вы не поздновато спохватились ?
Возможно станут популярнее SOC когда cpu и память в одном чипе как в apple M1,2,3,4....
Интересно когда amd до такого дозреют.
Нервно курит в сторонке ваш ркн :)
Перенимает опыт.
Прекрасно !
Будут ли его читать ...
>> Что именно улучшить? Скорость работы? Надежность? Время написания?
Добавлю еще к предыдущим.
Возможно, будет быстрее работать. Но тут может по-разному быть. Транзакций будет больше, поэтому может быть медленнее из-за более частых коммитов. Это фактор замедления.
Но!
Если строк в заявке будет много, то в случае одной транзакции (как у вас) растет время ожидания так как пока 1-я сессия не завершит резервирование всей заявки с Х строками, другая сессия которая, возможно, ее ждет, не начнет работу, ждет пока блокировки снимутся. В случае коротких транзакций они меньше будут друг другу мешать, меньше ожидание. Быстрее работа.
Какой из факторов сильнее скажется заранее сложно спрогнозировать. Если строк много и большая конкуренция за остатки то вариант с 1 транзакцией на строку будет быстрее. А если нет, то может быть обратный эффект.
>> Что именно улучшить? Скорость работы? Надежность? Время написания?
Снизить вероятность блокировок - я об этом явно написал.
Масштабируемость будет лучше. Если вдруг изменятся условия и в заявке для резервирования число строк увеличится например в 100 - 1000 раз, то работать будет норм. И примерно с той же скоростью на 1 строку (меньше будет ожидание разными сессиями друг друга). Конечно код будет сложнее, как вы справедливо указали. Но ничего бесплатно не бывает.
>> Можете пример кода привести, который демонстрирует эти улучшения?
Собственно, я описал идею и пошагово все привел. что там непонятного ? Или это придирка такая ? Ну кто хочет понять тот ищет возможности, кто не хочет - ищет причины.
>> Я пока увидел, что для реализации цикла с транзакциями внутри, а не снаружи нужен фоновый процесс, который будет отменять незавершенные брони. Тогда как в моем примере из статьи такой процесс не нужен.
Он потребуется для обработки аварийных ситуаций как минимум. Но и в вашем примере он нужен, о чем я указал.
Могу подробнее пояснить.
Вот приходит в вашем примере заявка - делается резерв, коммитится транзакция, а тут все падает (например электричество вырубилось или виртуальная машина грохнулась). Транзакция закоммичена. А оплата не прошла. Как в вашем примере решалась бы эта проблема ? Все равно нужно стороннее вмешательство для снятия резерва или восстановления сессии в которой можно было бы провести оплату.
>> Если для вас ACID и гарантии СУБД это "догмы" и "ярлыки", тогда вы правы.
Вы просто подменяете понятия, приписываете мне то что я не говорил, а потом "опровергаете". Гаденький, но детский приемчик. И совсем вас не украшает. На него никто уже не ведется.
Касательно транзакций и ACID - а кто вам сказал что вся обработка должна идти в одной транзакции ? Это совсем не обязательно. Все определяется задачей. Тем на какие по смыслу шаги можно разделить обработку (а в некоторых случаях и распараллелить, но это уже другая тема). В зависимости от условий, допустимо последовательность действий разбивать на несколько последовательных транзакций. И это не нарушение ACID. Нужно просто понимать что делаешь и соотносить с практикой.
Я вам пишу как можно улучшить и сделать надежнее несильно усложняя код.
Я этим больше 20 лет занимаюсь. Практикой все проверено.
А вы какими догмами рассуждаете.
Ярлыки навешиваете.
Ну, делайте как вам нравится. Никто не заставляет.
"гораздо менее надёжный, чем использование транзакций."?
Вы серьезно?
Да вы видимо никогда не сталкивались с кучей блокировок из за больших транзакций. Вам что важно, надежность или мнимая "простота"? И зачем она будет если повиснет под нагрузкой.
Насчет резервов - можно предположить экзотический сценарий когда из за падения обработки останется зависший резерв по части строк. Так он по куче причин может быть. Например в вашем случае, резерв полностью прошел но оплата не прошла. Или электрисество вырубилось. Та же ситуация только больше зарезервированных строк.
Для разруливания таких ситуаций делают фоновые обработки, которые снимаю старые ненужные рещервы или такие вот аварийные заказы. Обычная ситуация. И вы без такой обработки не обойдетесь даже с вашим вариантом длинных транзакций.
А можете озвучить цифры, сколько запросов на резерв в секунду у вас было в среднем и в пике?
Да причем здесь WAL?
Это же другой уровень. Все в приложении делается. Промежуточный статус млжно клиенту не показывать.
Ну вот рассмотрим ваш пример.
Клиент делает запрос - зарезервировать Х билетов.
В вашем примере
код открывает транзакцию.
Начинает цикл по числу билетов.
На каждом шаге цикла выполняет резервирование.
В конце после цикла закрывает транзакцию.
Возвращает ответ клиенту об успехе (дальше пойдет оплатп)
А как я предлагаю
Начинает цикл по числу билетов
На каждом шаге цикла делаем
А. Открываем транзакцию
Б. Делаем резерв одного билета.
В. Закрываем транзакцию
После завершения цикла возвращаем ответ об успехе (дальше идет оплата)
По факту, 2 строки кода поменять и все.
Можно чуть усложнить, в каждой транзакции несколько билетов резервировать на гаге Б. - тогда будет меньше накладных расходов.
Да, он просто задирал требования и дрючил студентов почем зря. Это не говорит о том что хорошо преподавал предмет.
Трепет первокуров...
Ну о чем вы. Даже несерьезно обсуждать.
>> Беклемишев — вершина, изумруд даже, можно сказать, Физтеха
С каких то пор он вершина и изумруд? Вы чего то попутали. Никогда такого отношения к нему не было.
Если что - закончил ФУПМ 2002. Так что с предметом знаком.
Вариант с хранимкой БЕЗ SELECT FOR UPDATE + с проверкой остатка в конце, в логах консольки пусто, цифры в конце сходятся, скорость 300 rps
Примерно такое решение реализовано в erp dynamics axapta от microsoft. Работает с 4-й версии (выпущена в 2008-м)