多租户应用中的 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都需要建立一个新的连接并进行身份验证（请记住，连接池对每个唯一的连接字符串起作用），这种方法意味着你有5000个连接字符串...

我应该对此感到多么担忧？有人能给我一些现实世界的例子，说明连接池对繁忙的多租户数据库服务器（例如每秒服务100个请求）有多大的影响吗？我可以投入更多硬件解决问题吗？

你有什么想法？

- AIDAN CASEY

---

你打算让每个租户建立他们自己的SQL Server连接，还是打算通过一个中间服务（例如WCF），将所有请求路由到其中？ - Alexander

简而言之：文档中描述的那个想法是不好的... - usr

Answer 1

我的建议是在数据库上开发一个坚实的API。可扩展性、模块化、可扩展性和会计将是主要原因。几年后，您可能会发现自己在玩SUSER_SID()时咒骂自己。例如，考虑由一个帐户管理的多个租户或类似白标签的情况...

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

对于大型项目，您仍然会发现最好为每个大玩家拥有单个DB。

我看到我没有回答您关于分段连接池性能的主要问题，但我相信仍然有许多有效的论点不走这条路。

请参见http://msdn.microsoft.com/en-us/library/bb669058.aspx以获取混合解决方案。

请参见SQL Server 2012中的行级安全性。

- Robert Cutajar