MultiTenant與多個DB

Question

我正在開發一個自定義CRM解決方案，該解決方案將通過Web/SaaS模型進行銷售。我預計有數十或數百個客戶使用此解決方案。我將使用MS SQL作爲數據庫引擎。

選項1是具有單個數據庫，並在表上包含一個TenantId列，一個合適的索引並在每個數據庫訪問中使用'where tenantId = {...}。

選項2是爲每個客戶端分配一個DB，避免需要TenantId和where子句。

我預計每個客戶端都會有數十萬條記錄，而不是數百萬條記錄。

正如我所看到的，無論我選擇哪個選項，都會有數據總頁數。這個決定似乎集中在SQL是否更好地管理多個數據庫，或者是一個包含TenantId和索引的數據庫。最初該解決方案將運行在單個數據庫服務器上，但最終會轉移到SAN。

有沒有人對此有任何看法？

Answer 1

有一個有趣的MSDN文章，標題爲Multi-Tenant Data Architecture，您可能想查看。作者們在這裏一定方法可能比另一種更合適的簡要分析：

的數量，性質，和你期望以服務 租戶需求的所有影響 不同的方式 您的數據架構的決定。以下某些問題可能會使您偏向於更孤立的方法，而其他問題可能會使您偏向於更加共享的方法 。

• 多少準租戶你 預期的目標？你可能不在 附近能夠估計 未來有權使用，但 認爲在數量級上： 你正在建造一個應用程序爲 數百租戶？成千上萬的？數千個數字 ？更多？您預計您的租戶基數越大， 更有可能您會想要考慮 更多共享方法。

• 多大的存儲空間你期望 平均租戶的數據佔據？ 如果您希望部分或全部租戶存儲大量數據，那麼最好使用單獨數據庫方法 。 （事實上​​，數據存儲 要求可能會迫使你無論如何要採取 獨立型數據庫模型。如果是這樣， 它會更容易設計 應用程序，從 的方式開始，而不是移動到 獨立型數據庫的方法以後。）

• 多少個併發最終用戶你 預計平均租戶支持？ 這個數字越大，越適合一個更孤立的方法 將會滿足最終用戶的要求。

• 你希望提供任何每個租戶 增值服務，如 每個租戶的備份和恢復 能力？這種服務更容易通過更獨立的 方法來提供 。

注意「共享方式」是選項1，「分離的方法」是選項2，你的情況。當談到前兩點時，你不會偏向任何一方，所以我想我會根據最後兩點作出決定。

Answer 2

如果您不必在租戶之間鏈接數據，那麼您最好擁有多個數據庫。維護更容易，設置更容易，性能會更好。 在一張表中有來自多個租戶的數據時，表鎖和大表上的搜索查詢可能並最有可能會降低您的解決方案速度。

共享一個數據庫的唯一原因我會看到，如果你有非常多的客戶端和每個客戶端的行數很少。