軟體設計師的庫

內容介紹單租戶vs多租戶資料庫和多租戶真實示例優點缺點用例概要1.簡介

在多租戶環境中，多個客戶（租戶）共享相同的應用程式，它們在相同的作業系統上，相同的硬體上以相同的資料儲存機制執行。客戶之間的區別是在應用程式設計期間實現的。客戶不會共享或看到彼此的資料。與每個使用者都有自己專用環境的專用系統相比，這樣做的主要動機是降低每位使用者的成本。

> In a multi-tenant application, most of the software stacks — up until the application itself, — are shared by the different tenants.

軟體即服務（SaaS）應用程式經常使用多租戶。SaaS的本質歸結為以下事實：供應商開發軟體，將其放置在伺服器上，維持其效能，安全性，客戶可用性（通常為複數形式），支付伺服器費用和其他費用。對於客戶而言，這種方法更便宜，而對於賣方而言則是值得的（因為它解決了許可和盜版問題，而且最重要的是，可以為多個客戶提供一項服務）。

2.單租戶vs多租戶2.1單租戶

該軟體和支援基礎結構的單個例項為單個客戶提供服務。透過單一租賃，每個客戶都有自己的獨立資料庫和軟體例項。本質上，此選項不會發生共享。

2.2多租戶

多租戶意味著該軟體及其支援基礎結構的單個例項為多個客戶提供服務。每個客戶共享該軟體應用程式，還共享一個數據庫。每個租戶的資料都是孤立的，其他租戶看不到。

> Single-Tenant and Multi-Tenant architectures comparison

3.資料庫和多租戶3.1一個通用資料庫，一個通用模式

一切都儲存在一個數據庫和公用表中。要實現此選項，先決條件是引入一個附加的欄位TenantID（或您喜歡的CustomerID）以分隔客戶之間的資訊。

好處：

當我們將所有資訊儲存在一組表中時，更易於開發，更新和維護新增客戶就像在客戶表中建立新記錄一樣簡單

缺點：

沒有靈活性，所有客戶端都使用同一組表和列。出現了非典型客戶會導致問題和打補丁。浪費人力和精力開發自己的許可權分離系統：(備份和恢復問題。一個表不能簡單地刪除和建立，因為它包含其他客戶端的資料。您必須查詢所需的行並將其覆蓋，這很麻煩。

解析度：

如果您有很多客戶並且缺乏資金/伺服器，並且所有硬碟驅動器不會同時消失，那麼這是個不錯的選擇。

3.2一個通用的資料庫，不同的模式

來自不同客戶端的資訊儲存在不同的表中。模式是包含某些資源（例如表）的“名稱空間”，可以在其上授予某些許可權。

好處：

由於有了這些架構，訪問共享發生在DBMS級別，因此不需要我們進行其他開發（我們節省了工時）更少的資料庫-更少的硬體資源，再次儲存可擴充套件性不錯-在新增客戶端時，我們會基於標準架構建立一個新架構，配置訪問許可權，然後完成。儘管所有架構都基於標準架構，但由於保留了隔離性，因此它們可能會發生一些更改，因此可以編輯列，表等。

缺點：

由於表在邏輯上而不是物理上分開，因此不同客戶的資料儲存在一起。備份和恢復存在問題。因為只有一個數據庫，所以如果來自一個客戶端的表已摺疊，則資料庫的簡單回滾將把所有客戶端的資料返回到過去，這是不可接受的。在這裡，您將需要選擇性地回滾以及合併新舊資料。該過程比僅回滾整個資料庫要複雜一些。

解析度：

如果客戶準備好生活在共享環境中，則選擇均衡的方案。

3.3分開的資料庫

程式碼在客戶端之間共享（使用通用的UI和業務邏輯），資料在邏輯上（可能物理上）在客戶端之間共享。

好處：

簡單的可擴充套件性（新增客戶端足以建立和配置新資料庫）輕鬆擴充套件-您可以在不同的伺服器上分發不同客戶端的資料庫個性化-您可以為某些客戶端進行個別設定（甚至將資料庫放置在另一個DBMS上）簡單備份-如果某個客戶端在資料庫回滾期間發生故障，則其他客戶端不會受到任何影響；

缺點：

昂貴。一臺伺服器支援的資料庫數量有限，這意味著這種解決方案將需要更多的硬體（而不是將所有內容儲存在一個數據庫中的方法），更多的硬體-更多的管理員，伺服器機房空間和電費再次昂貴。當一臺伺服器上有多個數據庫，其總容量大於RAM大小時，資料將被轉儲到交換檔案中，因此訪問硬碟非常慢。出路是購買更多伺服器

解析度：

對於主要目標是安全性且願意付款的客戶（例如銀行），這是最佳解決方案。

4.實際例子

> Serverless single database multi-tenant architecture on Google Cloud