其中多租戶方式建議

Question

按多租戶數據架構後，有3種方法來實現多租戶

1. 單獨的數據庫

2. 共享數據庫，不同的模式

3. 共享數據庫共享模式

我h ave以下詳細信息：

1. 用戶應該能夠備份和恢復其數據。

2. 沒有租戶：3（約）

3. 每個租戶可能屬於不同的域（URL）。

4. 所有租戶都有一些共同的表格。

5. 在每個租戶表的編號：10（初始）

我想知道哪種方法更適合我？

Answer 1

我認爲選項2是最好的選項，但您仍然遇到需求1的問題。備份和恢復不適用於每個模式。您將需要使用導入數據或任何自定義工具來處理此問題。公用表將具有獨立的模式。

在選項1中，您需要處理需求4，常用表將在所有數據庫之間複製。

Answer 2

所有5個條件中最重要的條件是條件4--其中說明一些表在所有租戶中都是常見的。如果某些表格很常見，則排除單獨的數據庫（即選項1）。

你可能已經選擇了2，共享數據庫和單獨的模式，但租戶數量相當少（在你的情況下爲3）。在這種情況下，增加維護獨立模式的開銷是一種應該避免的開銷。因此，我們可以跳過選項2，直到我們評估選項3.

選項3 - 具有共享模式的共享數據庫將是您最有效的選項。它避免了維護獨立模式的開銷，並允許租戶之間的公共表。在共享架構中，通常跨表使用租戶標識符。 Hibernate已經支持這種租戶標識符（以防萬一你將使用Java-J2EE來實現）。 唯一的問題可能是性能，因爲將所有三個租戶的數據放在同一個表中將導致較低的數據庫訪問\搜索性能，您必須採取反歸一化和索引來應對。

我會建議使用選項3

Answer 3

對於我們前進，我們已經開發人力資源的ERP所使用的客戶端的約四萬一千個用戶的;第三種是用於多租戶的方法。

此外，使用的技術分離表之一是遺產。

Answer 4

我在我的系統中遇到同樣的問題。我們的廣告網絡系統的加班時間非常長，所以我正在考慮向每個發佈商遷移到多租戶架構。

選項3與某些發佈者有特殊要求（額外的列/過程，我們不支持分區）不相關。 選項2不相關，因爲我們在客戶之間存在併發和加載問題。爲了實現高性能，我們計劃擴展到1000家發佈商，擁有20個小部件和高併發性，我們唯一的解決方案是選項1 - 單獨的數據庫。

我們已經遷移到這種模式，我們有10個數據庫在運行，配置和廣告共享數據庫。從表現來看，這很棒。從高可用性來看，它也非常好，因爲每個發佈者的流量都不會影響其他所有流量。添加新的發佈者對我們來說是一個簡單的步驟，因爲我們有我們的模板環境。我們唯一的問題是維護。

最近我一直在閱讀關於PartitionDB，它看起來非常簡單，因爲您可以有門數據庫來執行所有維護工作，包括升級和頂級查詢。它支持共享共享數據庫（與我們已有的一樣），我現在正在嘗試瞭解如何使用stand alone database。