多租户应用程序中的 SQL Server 碎片连接池性能

Question

我正在寻找一种在 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 都需要建立一个新的连接并进行身份验证（请记住连接池适用于每个唯一的连接字符串），这种方法意味着您有 5,000 个连接字符串......

我应该对此有多担心？有人可以给我一些真实世界的例子，说明连接池对繁忙的多租户数据库服务器的影响有多大（比如每秒处理 100 个请求）？我可以在问题上扔更多硬件然后它就消失了吗？

想法？？

Answer 1

我的建议是在您的数据库上开发可靠的 API。可扩展性、模块化、可扩展性、会计将是主要原因。几年后，您可能会因为玩 SUSER_SID() 而对自己发誓。例如，考虑由一个帐户管理的多个租户或像白标这样的情况......

有一个数据访问 api，它将负责身份验证。您仍然可以在数据库级别进行授权，但这是一个完全不同的主题。拥有用户和组，并授予他们对租户的权限。

尽管如此，对于大型项目，您仍然会发现每个大型参与者拥有一个数据库会更好。

我知道我没有回答你关于碎片连接池性能的主要问题，但我相信有很多有效的论据不走这条路。

• 请参阅 http://msdn.microsoft.com/en-us/library/bb669058.aspx 了解混合解决方案。
• 见Row level security in SQL Server 2012