我正在研究 SQL Server 中的 Multi-Tenancy 实现。我正在考虑此处描述的共享数据库、共享架构和租户 View 过滤器。唯一的缺点是连接池碎片化...
每http://msdn.microsoft.com/en-au/architecture/aa479086 ，Tenant View Filter描述如下:
"SQL views can be used to grant individual tenants access to some of the rows in a given table, while preventing them from accessing other rows.
In SQL, a view is a virtual table defined by the results of a SELECT query. The resulting view can then be queried and used in stored procedures as if it were an actual database table. For example, the following SQL statement creates a view of a table called Employees, which has been filtered so that only the rows belonging to a single tenant are visible:
CREATE VIEW TenantEmployees AS
SELECT * FROM Employees WHERE TenantID = SUSER_SID()
This statement obtains the security identifier (SID) of the user account accessing the database (which, you'll recall, is an account belonging to the tenant, not the end user) and uses it to determine which rows should be included in the view"
仔细想想，如果我们有一个数据库存储 5,000 个不同的租户，那么连接池就完全碎片化，每次向数据库发送请求时，ADO.NET 都需要建立一个新连接并进行身份验证(请记住连接池适用于每个唯一的连接字符串)，这种方法意味着您有 5,000 个连接字符串...
我应该对此有多担心？有人可以给我一些现实世界的例子，说明连接池对繁忙的 Multi-Tenancy 数据库服务器有多大的影响(比如每秒处理 100 个请求)？我可以通过投入更多硬件来解决这个问题吗？
想法??
最佳答案
我的建议是在数据库上开发一个可靠的 API。可扩展性、模块化、可扩展性、计费将是主要原因。几年后，您可能会因为使用 SUSER_SID() 而咒骂自己。例如，考虑由一个帐户管理多个租户或白标签等情况......
有一个数据访问 API，它将负责身份验证。您仍然可以在数据库级别进行授权，但这是一个完全不同的主题。拥有用户(也许还有组)并向他们授予租户权限。
尽管如此，对于大型项目，您仍然会发现每个大型参与者拥有一个数据库会更好。
我发现我没有回答您关于碎片连接池性能的主要问题，但我相信有许多有效的论据表明不要走这条路。
关于sql-server - Multi-Tenancy 应用程序中的 SQL Server 碎片连接池性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8077586/