Предположим, у нас есть небольшое приложение для электронной коммерции, в котором есть базовый спрос на товары, а запасы хранятся в таблице, как показано ниже.
SupplyTable
Элемент CurrentInventory
Там может бытьn номеров предметов, присутствующих в этой таблице, с последним номером инвентаря.
Теперь предположим, что бизнес стал популярным, и на определенный предмет есть огромный спрос.
Например, у Item1 всего 20 в качестве текущегоInventory.и многие люди одновременно заказывают один и тот же товар, то есть «Item1».
Теперь, очевидно, из-за концепции блокировки «на уровне строк», только один запрос может пойти и записать / обновить инвентарный номер, а другие должны ждать.[В соответствии с текущим дизайном для каждого заказа мы сначала обновляем таблицу снабжения] Представьте, что у вас есть запрос на 100 с для того же предмета, все поступили более или менее в одно и то же время, и все ждут снятия блокировки.
В основном нам нужно масштабировать эту БД.Как мы решаем эту проблему?Нужно ли брать какой-нибудь дополнительный стол?или любое другое возможное решение.Решение должно быть в виде rdbms, даже если мы используем какой-либо NoSQL здесь, что может быть решением?