А вы сами читали? Транзакционность в Orleans реализована за счет сохранения состояния в транзакционном хранилище, то есть в БД.
Продолжайте читать. Если вам советуют почитать (и даже ссылки кидают) - надо говорить Спасибо за ценную информацию.
Не надо делать какие-то невнятные заявления о транзакциях БД и прочем, в надежде что Вам сейчас все разъяснят.
Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)
Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)
The Orleans runtime guarantees that a grain instance will never execute on more than one thread at a time. This means that within the context of a single grain, you do not need to worry about race conditions or shared state being accessed concurrently by multiple threads.
Вы через WebApi дергаете BookItems
В Orleans.
Там (В методе BookItems у объекта ShopItem) в транзакции
уже проверяется словарь с записями по количеству на складах, вычитается у первого склада, на котором товар есть, пишется результат бронирования (в шину, оттуда BatchInsert).
Все, вы не можете записать результат бронирования пока не провалидируете количество на складах.
Остается только добавить возвращение результата (тоже через шину(!))
Почти akka.net
Есть явные причины так не делать под высокой нагрузкой.
Orleans offers high "actor speed" through a framework that keeps grain (actor) state in memory, providing low-latency access for real-time applications and enabling massive horizontal scalability by distributing grains across many silos (servers) and managing their lifecycles automatically. This in-memory state management is significantly faster than database roundtrips, allowing the system to achieve high throughput and sub-millisecond responses for concurrent tasks
У вас сколько типов товаров на распродаже? Меньше миллиарда (Чтобы на одном сервере поместились все акторы)?
Отлично.
10 кRPS.
Могу даже бесплатно подсказать:
Актор у вас
— item_id — уникальный идентификатор товара;
— warehouse_id — склад, где товар лежит;
— stock — общее количество (сколько товара на складе прям сейчас);
— reserved — сколько уже зарезервировано.
Ну а записи о резервировании опять в шину (персистентно, горизонтально масштабируемо), а оттуда - в БД (батчами).
Поздравляю, вы построили систему бронирования для миллиарда типов товаров, которая выдерживает
10 КRPS.
Саммари:
Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)
Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)
При этом не понимаете, что писать в <TargetFramework>. Поменяв net7.0 на netcoreapp2.0, вы сделали хуже, потому что если у .NET 7 поддержка закончилась в мае 2024, у .NET Core 2.0 - в октябре 2018.
И? Моя задача сделать либу, которая поддерживается наибольшим числом проектов. Core2.0 - самое то.
Да, нужно разбивать на несколько пакетов. Unity отдельно, Microsoft DI отдельно. Нет, разбираться в 3+ пакетах никому не придётся. Кому нужен RegistrationByAttributes для Microsoft DI, те по-прежнему поставят один пакет.
Зачем? Пакеты по 100 строк кода? При этом без тяжелых зависимостей (Только Abstractions)?
Во-вторых, лично я с возрастом начал ценить простоту. Я выберу 200 строк скучного, повторяющегося, но понятного как пять копеек кода, нежели магический чёрный ящик на 20 строк.
400-800-1000 строк скучного, повторяющегося кода, который всегда вызывает конфликты при merge :)
1) Отсекать по минимальным\максимальным значениям по осям
2) Добавить еще M гиперплоскостей неподалеку со слегка модифицированными угловыми коэффициентами (чтобы не тащить во время оптимизации гиперплоскости из +inf)
и т.д.
А за фолд респект, правда есть ньюансы:
1) Температура
2) Персептрон не годится, лучше SVM
3) наличие воды (да, AlphaFold показывает погоду на марсе, это выяснили в CAS) и pH
меняют картину чуть ли не полностью (а еще ситуация в соседних участках)
Ну и алгоритмически это полностью решаемо. Лучше делать на уровне сил (чтобы смотреть, как происходит сворачивание).
Функция 7-10 переменных, или Titanic Dataset :)
Ну и хоть концентрацию электронов, примерную скорость, направление перемещения у участков белка (фолд-3)
Есть вообще мнение, что это LowCost Cosplay на CAS (там уже биомаркеры-пептиды и окно в 10-20 лет)
Ну или даже на печально известное Delphi-2M
(да плевать что нейросети очень плохи в Explanation)
https://www.nature.com/articles/s41586-025-09529-3
Очень, учитывая что это почти DreamCoder (Darpa).
Т.е. просто спонсируем грант MiT, через 10 лет достаем (у нас тут в Alphabet почти OpenSource)
Продолжайте читать. Если вам советуют почитать (и даже ссылки кидают) - надо говорить Спасибо за ценную информацию.
Не надо делать какие-то невнятные заявления о транзакциях БД и прочем, в надежде что Вам сейчас все разъяснят.
Бесплатно - нет
Orleans так-то ACID.
Ну и весь код с Orleans - Положить запросы в шину,
При обработке:
1) дергать Orleans (bookTemporary(int count, int itemId), получаем guid)
2) отсылаем в шину операции на бронирование заказов (там BatchInsert)
3) отсылаем в шину операцию bookFinalize(подтверждаем бронирование)
Все, 100+ RPS.
За счет outboxConsistency точно не будет повисших бронирований.
Даже если шина вдруг откажет (ага), остатки будут возвращены на склад
Вы через WebApi дергаете BookItems
В Orleans.
Там (В методе BookItems у объекта ShopItem) в транзакции
уже проверяется словарь с записями по количеству на складах, вычитается у первого склада, на котором товар есть, пишется результат бронирования (в шину, оттуда BatchInsert).
Все, вы не можете записать результат бронирования пока не провалидируете количество на складах.
https://learn.microsoft.com/ru-ru/dotnet/orleans/grains/transactions
Как не решает?
Остается только добавить возвращение результата (тоже через шину(!))
Почти akka.net
Orleans offers high "actor speed" through a framework that keeps grain (actor) state in memory, providing low-latency access for real-time applications and enabling massive horizontal scalability by distributing grains across many silos (servers) and managing their lifecycles automatically. This in-memory state management is significantly faster than database roundtrips, allowing the system to achieve high throughput and sub-millisecond responses for concurrent tasks
У вас сколько типов товаров на распродаже? Меньше миллиарда (Чтобы на одном сервере поместились все акторы)?
Отлично.
10 кRPS.
Могу даже бесплатно подсказать:
Актор у вас
Ну а записи о резервировании опять в шину (персистентно, горизонтально масштабируемо), а оттуда - в БД (батчами).
Поздравляю, вы построили систему бронирования для миллиарда типов товаров, которая выдерживает
10 КRPS.
Саммари:
Автор вообще слабо представляет Highload, ругает стандартные подходы (вроде Orleans) и лепит системы в 10-1000 раз менее производительные, чем можно :)
Ну а гит - вообще прелестно. Хоть Concurrent коллекцию возьмите :)
А вообще забавно.
10 RPS
Если просто взять, записать все в шину (шины могут быть развернуты на 100 инстансах, и писать гигабиты запросов) - можно тоже получить 10 кRPS.
Ну и как-то сложно.
Вот генерация веб-апи, которое пишет все в шину и разбирает по батчам (для IOT).
https://habr.com/ru/articles/906778
Orleans.
Богатые доменные модели в оперативке (и дампятся в хранилище автоматом).
Хоть 1M RPS (упретесь в CPU\сеть) :)
Даже с транзакциями(!).
Но есть минусы.
Ну, расскажите нам, что у вас за git
Да вы что, добавление 2-х разных строк в одно и то же место в файле - 100% конфликт при мерже.
Вам написали, что вы - идиот?
Ссылки привели?
Что Вас не устраивает? )
(del)
Вы откровенно херню городите, Вам даже ссылки приводят.
Вам уже написали:
1) вы читали меньше меня
2) у вас нет ни интерпретации ни оптимизации персептрона (А как публикация называется? А какие понятные причины? :) )
(и интерпретировано все, и оптимизировано, и это уже сделано с позиции LP)
3) почему те, кто понимает нейросети и перцептроны лучше, чем средние дурачки из Google (или CAS), не пишут вам статьи об этом. Да еще и бесплатно )
Удивительно, но у меня есть куда более перспективные занятия (а хабр с точки зрения науки - трэш :) ).
Вы пропустили 3-4 публикации:
1) Перцептрон, знаки в S/A слое и гиперкубы логических функций
2) Перцептрон, нейросети и ошибки из-за ненормированного расстояния до гиперплоскостей
3) Перцептрон как линейное ограничение
И? Моя задача сделать либу, которая поддерживается наибольшим числом проектов. Core2.0 - самое то.
Зачем? Пакеты по 100 строк кода? При этом без тяжелых зависимостей (Только Abstractions)?
400-800-1000 строк скучного, повторяющегося кода, который всегда вызывает конфликты при merge :)
Тут согласен.
Это который превращает boilerplate регистраций в еще менее поддерживаемый? И требует перерегистраций? Где истина-то?
Ого, то есть если вероятность ошибки за шаг 0.8,
то за 100 шагов будет правильный результат с шансом 0,8^100=2e-10
А если ошибка на каждом шаге 0.9 то 0,9^100 = 2e-5
Научный прорыв!
Боже...
Да потрудитесь обьяснить-то!
Есть кстати тысячи улучшений (За N времени):
1) Отсекать по минимальным\максимальным значениям по осям
2) Добавить еще M гиперплоскостей неподалеку со слегка модифицированными угловыми коэффициентами (чтобы не тащить во время оптимизации гиперплоскости из +inf)
и т.д.
А за фолд респект, правда есть ньюансы:
1) Температура
2) Персептрон не годится, лучше SVM
3) наличие воды (да, AlphaFold показывает погоду на марсе, это выяснили в CAS) и pH
меняют картину чуть ли не полностью (а еще ситуация в соседних участках)
Ну и алгоритмически это полностью решаемо. Лучше делать на уровне сил (чтобы смотреть, как происходит сворачивание).
Функция 7-10 переменных, или Titanic Dataset :)
Ну и хоть концентрацию электронов, примерную скорость, направление перемещения у участков белка (фолд-3)
И называется это
https://ru.wikipedia.org/wiki/Графический_метод_решения_задачи_линейного_программирования