多租戶應用程序中的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個請求）？我能否在問題中拋出更多的硬件，它會消失？

的思考？

Answer 1

我sugestion將是開發在你的數據庫了堅實的API。可擴展性，模塊化，可擴展性，覈算將是主要原因。幾年後，你可能會發現自己罵自己玩SUSER_SID（）。例如，考慮通過一個帳戶或情況類似whitelabels管理多個租戶......

有一個數據訪問API，這將需要認證的照顧。您仍然可以在數據庫級別上進行授權，但這是一個完全不同的主題。擁有用戶和可能的團體並授予他們租戶的權限。

對於大型項目儘管如此，你還是會發現它最好有每個大個子球員單DB。

我見我沒有回答你關於分段連接池的性能主要問題，但我相信有很多有效參數不走不過這條道路。

• 有關混合解決方案，請參閱http://msdn.microsoft.com/en-us/library/bb669058.aspx。
• 見Row level security in SQL Server 2012