Как избежать коллизии по данным?

Question

[Pantuchi]

На работе используем MS SQL Server. Приложения работают на C# ASP Net. Архитектура базы данных реляционная с объектно-ориентированным подходом (если правильно написал). Запросы к базе данных идут асинхронно с клиентской стороны через js. При высокой нагрузке близкой к 100% пользователь может совершить транзакцию на создание объекта в базе. Сама транзакция может подвиснуть. Пользователь не дожидаясь ответа обновляет страницу и снова создает объект. Получается уже две транзакции в очереди. По итогу когда очередь доходит до выполнения имеем в базе два одинаковых объекта (созданных вплоть до ms) что ломает логику программы. Когда в нормальных условиях создастся должен только один объект (уникальность на уровне логики пользователя). Т.е. по логике пользователь создает объект получает результат и больше не создает (но если захочет может добавить такой же). Что имеем по итогу при 100% нагрузки получаем логические коллизии по данным. Пытались через интерфейс блокировать клики пока не придет результат, но это не вариант. Обновляешь страницу ничего не видишь потому что операция подвисла.
Как можно решить проблему данного характера? Она появилась именно когда на сервере появилась большая нагрузка.

Comments

[Akina]

Пользователь не дожидаясь ответа обновляет страницу и снова создает объект. Получается уже две транзакции в очереди. По итогу когда очередь доходит до выполнения имеем в базе два одинаковых объекта (созданных вплоть до ms) что ломает логику программы.

В таблице должны быть уникальные индексы, блокирующие создание дубликатов. Тогда вторая транзакция просто окончится неудачей.

[Pantuchi]

Да так и есть. Это спасло. Но хотелось бы больше контроля над такими ситуациями

[Pantuchi]

Akina, но у нас уникальность на уровне свойств объекта. От создания самого объекта это не спасет

[Akina]

Pantuchi, а создание объекта - это за пределами MS SQL, то есть это не его проблема. Решается, впрочем, легко - если транзакция обломилась, объект уничтожается.

[Pantuchi]

Akina, это вы говорите про полную транзакцию, которая проверяет и создает объект в одной транзакции. У нас все операции разбиты на мелкие транзакции. Транзакция на проверку, транзакция на запись, транзакция. Т.е. например таблица обджект обладает 5 поляуми. Объект заполняется не одним запросом, а мелкими. Например чтобы создать тело объекта, я проверю некоторое условие в базе, потом отправлю трнзакцию на создание объекта т.е. выдам ему ID потом имея ID создам в таблице Свойств уникальную пару ID, СВойство ID, и запишу например число. Как буд то вы работает с ООП. Мелкие запросы. Вот тут и возникает параллельный доступ к данным и коллизии.

[Akina]

Pantuchi, не, я не понял...

Во-первых, Вы специально и сознательно делаете всё, чтобы описанные коллизии были не только возможны, но и почти что неизбежны.

Во-вторых, эти коллизии возникают и существуют там, куда SQL-сервер даже теоретически не дотягивается. Более того, дробя единое действие на кучу мелких и не связанных между собой шагов, Вы заведомо уничтожаете возможность контролировать целостность и легитимизируете несогласованные результаты коллизий, с которыми хотите бороться.

В третьих, Вы почему-то даже не пытаетесь бороться с коллизиями там, где они собственно и возникают - на уровне веб-интерфейса и обслуживающего его веб-сервера. Совершенно непонятно почему.. а бороться с проблемой там, где она аукается, бессмысленно.

В общем, проблема не в SQL-сервере.

[Pantuchi]

Akina, На уровне интерфейса это нереально. Заблокировать web интерфейс? Пользователь обновит страницу и повторит. Один вариант крутится в голове это сделать свой планировщик, но это геморно втискивать его уже в работающую систему.

Вы правильно сказали все, куча разрозненных операций, неконтролируемых sql. Весь контроль идет на бекенде (в коде) не в транзакциях

[Akina]

На уровне интерфейса это нереально. Заблокировать web интерфейс? Пользователь обновит страницу и повторит.

Да чё за бред-то? создай идентификатор сессии, который присваивается соединению по факту аутентификации, и передавай его по всем страницам и со всех страниц. Тогда дубликаты запросов от имени одной и той же учётной записи ловятся по щелчку пальцев...

Answer 1

[mayton2019]

При высокой нагрузке близкой к 100% пользователь может совершить транзакцию на создание объекта в базе. Сама транзакция может подвиснуть. Пользователь не дожидаясь ответа обновляет страницу и снова создает объект. Получается уже две транзакции в очереди. По итогу когда очередь доходит до выполнения имеем в базе два одинаковых объекта (созданных вплоть до ms) что ломает логику программы.

Очень плохо что вы довели систему до нагрузки 100%. Обычно concurrency работает хорошо когда мы не доводим до такого состояния. Есть даже такой термин thread starvation (голодание потоков) когда потоки никак не могут получить квант времени.

Без кода и лог-файлов тут нечего обсуждать. Я просто могу дать несколько направлений на подумать.

1) CQRS (Command-Query-Separation) - это шаблон разработки при котором команды на изменение данных и запросы на их чтение идут независимо и существуют как-бы в разных временных эпохах. Это дает возможность масштабировать системы довольно сильно. И такие системы обычно лишены блокирок.

2) Idempotency- это два свойства бизнес операций. Идемпотентность например предполагает что если платежная система дважды продублировала ваш платеж (MQ/сетевые replays) за покупку чашки Кофе например то это не означает что с вас банк снимет дважды деньги. На самом деле каждая ваша карточная операция имеет уникальный ID и с точки зрения биллинга будет применение платежа только 1 раз с одним уникальным ID. Второй платеж-дубль будет проигнорирован. Это свойство часто используется в Apache Kafka как один из способов поднять скорость и надежность.

3) Когда ваша база или сервер приложений находтся в состоянии как-бы "агонии" то не стоит пытатся добивать ее повторами операций. А стоит на некоторое время прикрыть канал операций. Или разорвать цепь предохранителя. Как делают в электрике при повышенной нагрузке. Есть такой шаблон Cirquit Breaker. Аварийный размыкатель. Netflix его активно использует.

Вот подумайте.

Comments

[Pantuchi]

Спасибо за совет, сегодня провели анализ нагрузки и пришли к выводу, что из за роста объема данных некоторые тяжеловесные запросы стали нагружать sql. Пришли к выводу , что надо пытаться оптимизировать некоторые запросы и минимизировать запросы со стороны клиента когда данные ему вообщем то не нужны и грузить их лишний раз не стоит.

На счет уникально ID запроса ... тут я не знаю как прокомментировать. У нас в sql есть учетные данные входа по котором пользователь авторизуется и работает с базой, есть так же дефолтная учетка для неавторизованных пользователей. Все веб приложения используют учетные данные входа и тут я думаю нужно наверное какой то уникальный ID делать в связке приложение + учетка sql. Может это уже под капотом есть IIS + SQL пока не могу сказать. Не давать стакать запросы пока не завершиться первый ... ну это так бешенная идея

[mayton2019]

Спасибо за совет, сегодня провели анализ нагрузки и пришли к выводу, что из за роста объема данных некоторые тяжеловесные запросы стали нагружать sql.

Еще одно наблюдение. Может будет полезно. Услово БД делятся на OLTP и DWH.
В первой работают короткие транзакции типа key-value во второй - всякие sum/avg/count
и прочая аналитика. В реальности БД создают условия когда нет различия для выборки 1
строки по поисковым ключам или множества строк. Благо... реляционная алгебра позволяет.
И как следствие большая часть БД никак не бъется на такую классификацию а просто
по сути являет собой гибридные БД где есть и те и другие виды запросов. И ничего
с этим сделать нельзя. Просто человеческая лень и бизнес-прагматизм решает задачи
здесь и сейчас и не думает ни о каких классификациях и уж тем более на разделениях систем
на первые и вторые. Мне такие БД чаще всего попадались в очень плачевном и загнаноом
состоянии. Вот. И я думаю что формальное разделение систем на NoSQL/key-value и Analytics
было тем самым "ответом" на такое плачевное положение реляционной архитектуры.

Разделение позволяло по крайней мере выделить главную цель - дать быстрый TTFB для
пользователя веб-сессии и сделать это время независимым ни от каких фоновых джобов
или отчетов. Ну а аналитические БД - обычно цеплялись репликой или slave или логическим
стенда-бай (смотря в какой БД) к базе онлайн транзакций.

Вот все кто изначально такую архитектуру сделали - живут припеваючи и ни о каких загонах
и не думают. Благо в наше время, в эпоху докеров и кубернетисов задача поднятия инстанса
стала во много раз дешевле чем 10-15 лет назад когда покупалась железка под задачу.

Сегодня железки нет в изначальных условиях и значит вы - свободны в выборе архитектур.

Answer 2

[Alex G.]

Для решения данной проблемы можно использовать механизм блокировки, который позволит избежать создания дубликатов объектов в базе данных при высокой нагрузке. Также можно оптимизировать запросы к базе данных и настроить ее на работу с большой нагрузкой. Для этого можно применить индексы, кластеризацию таблиц и другие методы оптимизации. Кроме того, можно использовать технологии кэширования, которые помогут ускорить доступ к данным и снизить нагрузку на сервер.

Answer 3

[res2001]

Сделать в таблице уникальный индекс по одному или нескольким полям, которые образуют уникальный ключ для объекта. В этом случае при попытке создать в базе запись с таким же уникальным ключом будет ошибка.

Вообще нагрузка 100% - это повод задуматься о масштабировании приложения или оптимизации базы, не понял где у вас нагрузка 100%.
Необходимость масштабирования не отменяет создания уникального индекса.

Comments

[Pantuchi]

У нас было раньше два сервера. Один из которых был старый и на нем были некоторые ресурсозатратные операции. Как то жили и вытягивали. Потом по определенным причинам, пришлось объединить базы на один сервер. И при разовой высокой нагрузке по расчету годовому, стали наблюдаться как раз таки проблемы. Что транзакция стала подвисать, а пользователь он такой неудержимый. Обновляет страницу и и снова создает запрос на создание объекта из за чего появляется ошибка по уникальному ключу

[res2001]

Pantuchi, Значит уникальный индекс есть? Тогда не вижу тут проблемы.

[Pantuchi]

res2001, но у нас уникальность на уровне свойств объекта. От создания самого объекта это не спасет

[Pantuchi]

есть главный объект (узел) у него дочернии объекты со своими свойствами. Свойства уникальны в пределах объекта. Т.е. уникальность на уровне свойств имеется. Уникальность у объекта только по id. Из за подвисуна может создасться два таких объекта. Потому что пользователь не дождался предыдущей транзакции, обновил страницу и нажал создать снова

[res2001]

Pantuchi, Видимо надо пересмотреть структуру базы. Если у вас есть набор уникальных свойств, который лежит в другой таблице, то эти свойства надо перенести в одну таблицу с объектом и по ним делать уникальный индекс.
Все остальные не уникальные свойства, пусть лежат в другой таблице.
На сколько я понял уникальность вы обеспечиваете кодом приложения. При таком подходе подобные ошибки вполне закономерны.

Answer 4

[Константин Цветков]

Свойства уникальны в пределах объекта. Т.е. уникальность на уровне свойств имеется. Уникальность у объекта только по id

Значит собираете все свойства в "цифровой отпечаток" и блокируете объект по нему.

два одинаковых объекта

Они не будут одинаковыми, так как и них разный "отпечаток". А значит нужно оставлять только тот, который имеет более полный и используется для операций.