Производительность базы данных для определения сущностей, назначенных пользователям

Question

Меня интересует понимание улучшения производительности в следующем случае:

В настоящее время я работаю над приложением, которое имеет иерархическую структуру сущностей, в которой, в зависимости от уровня пользователя в организации, они будут иметь назначение определенной сущности на определенном уровне - и, таким образом, будут иметь доступ ко всем своим дочерним элементам (в в этом случае здания внутри районов в пределах регионов по всей территории США). Большинство суперпользователей будут иметь в своем портфеле свыше 20 000 отдельных субъектов, а некоторые - до 40 000.

Вместо того, чтобы вдаваться в подробности, достаточно сказать, что для определения всех сущностей, к которым имеет доступ пользователь, необходима хорошая логика. Эта логика в настоящее время обрабатывается с использованием табличной функции, которая используется в 95% хранимых процедур. Средняя хранимая процедура занимает не более 1-2 секунд. НО, на странице ASP.Net, которая вызывает более 10 различных хранимых процедур, производительность быстро возрастает до 20+ секунд.

В качестве альтернативы мы думали о том, чтобы вызвать эту табличную функцию только один раз (после входа в систему) и сохранить результаты в таблице (после очистки любых предыдущих значений для того же пользователя). Тогда бы все хранимые процедуры ссылались на эту новую таблицу вместо табличной функции. Тест показал, что при выборе из новой таблицы страница, загрузка которой заняла 15 секунд, может отрисоваться менее чем за 3 секунды.

Например:

1. Пользователь входит в систему
2. Система удаляет все сущности для пользователя в таблице
3. система вставляет все сущности пользователя, затем
4. система отправляет их в веселом режиме и больше не запускает табличную функцию для текущего сеанса

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

Answer 1

Я думаю, что это будет плохой дизайн, и в какой-то момент вы столкнетесь с проблемами производительности.

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

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

Answer 2

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

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