Производительность фрагментированного пула соединений SQL Server в мультитенантных приложениях - PullRequest
7 голосов
/ 10 ноября 2011

Я смотрю на инструмент для мультитенантности в SQL Server. Я рассматриваю общую базу данных, общую схему и фильтр представления клиентов, описанные здесь. Единственный недостаток - фрагментированный пул соединений ...

За http://msdn.microsoft.com/en-au/architecture/aa479086, Фильтр просмотра арендатора описывается следующим образом:

"Представления SQL могут использоваться для предоставления отдельным арендаторам доступа к некоторым строкам в данной таблице, в то же время предотвращая их доступ к другим строкам.

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

CREATE VIEW TenantEmployees AS 
SELECT * FROM Employees WHERE TenantID = SUSER_SID()

Этот оператор получает идентификатор безопасности (SID) учетной записи пользователя, обращающегося к базе данных (которая, как вы помните, является учетной записью, принадлежащей арендатору, а не конечному пользователю) и использует ее для определения того, какие строки следует включить в представлении "

Если подумать, если у нас в одной базе данных хранится, скажем, 5000 разных арендаторов, пул соединений полностью фрагментируется, и каждый раз, когда запрос отправляется в базу данных, ADO.NET необходимо устанавливать новое соединение и проходить аутентификацию (помните, что пул соединений работает для каждой уникальной строки подключения), и этот подход означает, что у вас есть 5000 строк подключения ...

Насколько я должен беспокоиться об этом? Может ли кто-нибудь дать мне примеры из реальной жизни о том, как сильно пул соединений влияет на занятый мультитенантный сервер базы данных (скажем, обслуживание 100 запросов в секунду)? Могу ли я просто добавить больше оборудования к проблеме, и она исчезнет?

Мысли ??

1 Ответ

1 голос
/ 16 января 2013

Мое предложение - разработать надежный API для вашей базы данных. Масштабируемость, модульность, расширяемость, учет будут основными причинами. Через несколько лет вас могут ругать за то, что вы играете с SUSER_SID (). Например, рассмотрим нескольких арендаторов, управляемых одним аккаунтом, или ситуации, подобные whitelabels ...

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

Тем не менее, для крупных проектов вам все равно будет удобнее иметь одну БД на крупного игрока.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...