MS SQL Server
  1. MS SQL Server
  3. Performances du pool de connections fragmentées SQL Server dans les applications multi-tenant
Intereting Posts
Comment puis-je modifier la source de données dans Microsoft SQL Server dans Visual C #? Requête dynamic TSQL Utiliser plusieurs instructions WITH nom de table AS (…) SQL Server Impasse sur 2 pages Variable de date de procédure stockée T-SQL Créer une procédure stockée CLR à l'aide de la DLL créée par .net framework 4.0 dans SQL Server 2008. L'erreur est présente Est-ce que la command Fusionner effectue des mises à jour légitimes? Comment résoudre une erreur La clause ORDER BY est invalide dans les vues, les fonctions inline, les tables dérivées, les sous-requêtes Comment restaurer la sauvegarde de la database msdb La mise à jour de la table avec l'index est trop lente Comment contrôler le nombre de lignes renvoyées dans une requête SQL, sans connaître le nombre de lignes dont nous avons besoin comment get Roundhouse pour créer db sur le second disque dur Quel est le nombre entre parenthèses sur l'label de tabulation d'un script sql dans VS2010? Erreur "impossible d'exécuter le script" dans SQL Server Management Studio L'utilisation de CTE dans un DELETE n'est pas en cours d'exécution

Performances du pool de connections fragmentées SQL Server dans les applications multi-tenant

Je regarde un outil pour la multi-location dans SQL Server. Je considère une database partagée, un schéma partagé et un filter d'affichage de locataire décrits ici. Le seul inconvénient est un pool de connection fragmenté …

Pour http://msdn.microsoft.com/fr-fr/architecture/aa479086 , le filter de vue du locataire est décrit comme suit:

Les vues SQL peuvent être utilisées pour accorder aux locataires individuels l'access à certaines lignes d'une table donnée, tout en les empêchant d'accéder à d'autres lignes.

En SQL, une vue est une table virtuelle définie par les résultats d'une requête SELECT. La vue obtenue peut ensuite être interrogée et utilisée dans des procédures stockées comme s'il s'agissait d'une table de database réelle. Par exemple, l'instruction SQL suivante crée une vue d'une table appelée Employés, qui a été filtrée afin que seules les lignes appartenant à un seul locataire soient visibles: 

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

Cette instruction obtient l'identificateur de security (SID) du count user accédant à la database (qui, vous vous souviendrez, est un count appartenant au locataire et non à l'user final) et l'utilise pour déterminer les lignes à inclure dans la vue "

En pensant cela, si nous avons une database stockant 5 000 locataires différents, le pool de connection est complètement fragmenté et chaque fois qu'une requête est envoyée à la database, ADO.NET doit établir une nouvelle connection et s'authentifier string de connection unique) et cette approche signifie que vous avez 5000 strings de connection …

Dans quelle mesure devrais-je être inquiet? Quelqu'un peut-il me donner des exemples concrets de l'impact significatif du pool de connections sur un server de bases de données à locataires multiples occupé (par exemple 100 requêtes par seconde)? Puis-je simplement jeter plus de matériel sur le problème et il s'en va?

Pensées ??

    Ma suggestion sera de développer une API solide sur votre database. Évolutivité, modularité, extensibilité, comptabilité seront les principales raisons. Quelques années plus tard, vous pouvez vous refind en train de vous jurer de jouer avec SUSER_SID (). Par exemple, considérez plusieurs locataires gérés par un count ou des situations comme des balises …

    Avoir un API d'access aux données, qui prendra soin de l'authentification. Vous pouvez toujours faire une autorisation au niveau de la database, mais c'est un sujet complètement différent. Avoir des users et peut-être des groupes et leur accorder des permissions aux locataires.

    Pour les projets de grande envergure, vous findez toujours préférable d'avoir une seule database par grand joueur.

    Je vois que je n'ai pas répondu à votre question principale sur la performance du pool de connections fragmenté, mais je suis convaincu qu'il existe de nombreux arguments valables pour ne pas aller dans ce sens.