資料庫租戶能力大調研

資料庫工作筆記發表於2023-12-19
資料庫

來源：韓鋒頻道

隨著SaaS軟體日益流行，如何為企業使用者提供即統一又相互獨立的服務，成為很多基礎軟體商的課題，因而租戶能力正受到更多關注。另一方面，隨著分散式資料庫的流行，如何充分利用分散式環境的算力及儲存資源為不同業務服務，也同樣對租戶能力提出的要求。本文針對常用的租戶實現方法、技術路線進行說明，重點說明場景資料庫的租戶能力並加以對比。


1. 多租戶能力概述

多租戶（Multi Tenancy/Tenant）是一種軟體架構，是實現如何在多使用者環境下共用相同的系統或程式元件，並且可確保各使用者間資料的隔離性。與之相對應的就是單租戶SaaS架構（也被稱作多例項架構（Multiple Instance））。兩者的區別在於，單租戶是為每個客戶單獨建立各自的軟體應用和支撐環境。後者通常被廣泛引用在客戶需要支援定製化的應用場合。
1).多租戶業務訴求
很多平臺類應用或系統（如電商 CRM 平臺、倉庫訂單平臺等等），它們的服務模型是圍繞使用者維度（這裡的使用者維度可以是一個賣家或品牌，可以是一個倉庫等）展開的。因此，這型別的平臺業務，為了支援業務系統的水平擴充套件性，業務的資料庫通常是按使用者維度進行水平切分。當平臺類應用的一些使用者慢慢成長為大使用者（比如大品牌、大賣家、大倉庫等）後，這些大使用者由於其資料量或流量明顯要比其它使用者多得多，容易出現如業務熱點瓶頸、資源使用不均、服務品質受損等問題。SaaS 多租戶模型作為一種應用的架構，常用來解決業務的上述問題。在SaaS多租戶模型中，業務系統會需要服務多個使用者，每個使用者（或每批使用者）可以被視為一個租戶。SaaS 多租戶解決業務系統穩定性問題以及租戶資源彈性定製的核心思路，就是租戶間的資源隔離及資料隔離。針對多租戶的問題，可以有多種解決思路。
2).多租戶構建模式
針對多租戶需求，常見有三種構建模式：
  • 獨立資料庫：一個租戶獨享一個資料庫例項，提供最強的分離度，租戶資料彼此物理不可見，備份恢復都很靈活；
  • 共享資料庫、獨立 Schema：將每個租戶關聯到同一個資料庫的不同 Schema，租戶間資料彼此邏輯不可見，上層應用程式的實現和獨立資料庫一樣簡單，但備份恢復稍顯複雜；
  • 共享資料庫、共享 Schema、共享資料表：租戶資料在資料表級別實現共享，提供最低成本，但引入了額外的程式設計複雜性，備份恢復也更復雜。

資料庫租戶能力大調研

從上面多種構建模式對比可見，各方案有著鮮明的優缺點。在技術實現上，可分為兩種情況，一種是採用資料庫內建能力來支援租戶，一種是在應用側來解決。針對前者，後文將著重談談各資料庫的租戶能力；後者往往依賴於應用研發能力。特別是共享庫、Schema、表的模式，具有成本低的明顯優勢，通常在應用研發側來解決，但這一模式面臨諸多難點，在實際使用中常透過中介軟體策略增強這一模式能力，補齊短板。

3).中介軟體策略解決難點

如上面所說，採用中介軟體策略可以解決第三種模式的短板，這其中需要著重解決以下問題：
  • 開發複雜問題。原模式中通常需要引入租戶ID的概念，在行級增加標識來區分，這對於業務研發是不太友好的，需要在中介軟體層面最好遮蔽，讓業務研發迴歸到租戶內，不用感知到租戶資訊。
  • 跨機分散式事務。有時是需要提供跨租戶的資料訪問，這意味著業務需要做很多額外的應用改造成本，才能儘量來避免跨機事務導致業務出現報錯。可透過中介軟體層提供強一致分散式事務能力來解決這一問題。
  • 後設資料一致性。當使用跨Schema或共享資料表的模式，都面臨操作所有租戶物件同時生效問題。比如在 MySQL 的建刪表、加減列、加減索引等常見的DDL操作，需要中介軟體能力來保證平臺所有租戶的表能同時生效，一旦執行中斷，可以自動回退，無需人工介入來訂正。
  • 租戶資料遷移。當租戶發展壯大後會面臨資源不足需要遷移等情況，此時就需要針對租戶提供資料遷移能力，與底層資源層解耦，實現按需使用。這部分維護成本很高，中介軟體可提供此能力便於在租戶層面進行遷移。


2. 資料庫租戶能力調研

有很多資料庫已經內建了多租戶能力，使用者可很方便地基於此快速開發 SaaS 類應用。下面簡單對比下：

資料庫租戶能力大調研

1).Oracle 租戶能力

Oracle 多租戶功能允許在一個資料庫例項中同時執行多個獨立的資料庫，這些資料庫被稱為外掛資料庫（簡稱 PDB）。多租戶功能透過將不同的 PDB 分離在不同的儲存空間中，實現資料和應用程式的隔離，從而提高資料庫的利用率和靈活性。以下是 Oracle 多租戶功能的主要特點：

  • 獨立性：每個 PDB 都是一個獨立的資料庫，具有自己的資料和配置。這使得您可以在同一個資料庫例項中執行多個獨立的應用程式，而不會相互干擾。

  • 共享資源：多個 PDB 可以共享一些資源，如資料庫伺服器、CPU 和記憶體。這有助於提高資源利用率，並降低硬體成本。

  • 資料隔離：每個 PDB 都有自己獨立的資料儲存，確保資料安全性。此外，Oracle 多租戶還支援跨 PDB 資料複製和同步，便於資料在不同 PDB 之間共享和一致性。

  • 許可權管理：Oracle 多租戶功能允許您為每個 PDB 獨立設定使用者和許可權。這有助於實現精細化的許可權控制，提高資料安全性。

  • 簡化管理：透過 Oracle 多租戶功能，您可以集中管理多個 PDB，從而簡化資料庫管理和維護工作。

  • 高可用性：Oracle 多租戶支援 PDB 的自動故障轉移、資料備份和恢復，確保應用程式的高可用性。

資料庫租戶能力大調研







2).PostgreSQL 租戶能力

PostgreSQL 資料庫本身並沒有類似 Oracle 資料提供完善的租戶能力，但是可以結合多種開源技術和框架，實現廣義軟體架構上的多租戶模式。PostgreSQL 支援例項-庫-Schema三級，也支援行級安全策略，可透過上面技術能力，實現在庫、Schema和行級別的租戶能力。

資料庫租戶能力大調研

3).TiDB 租戶能力
TiDB 採用了雙層資源管控機制來實現更精確的管控。“流量控制”模組控制資源限額，確保僅在限額內的操作才能得以執行；“排程控制”模組則對佇列中的任務設定不同的優先順序，以確保在負載劇烈變化或超負荷執行時，高優先順序的任務能夠得到快速反饋。TiDB 資源管控特性提供了兩層資源管理能力，包括在 TiDB 層的流控能力和 TiKV 層的優先順序排程的能力。將使用者繫結到某個資源組後，TiDB 層會根據使用者所繫結資源組設定的配額對使用者的讀寫請求做流控，TiKV 層會根據配額對映的優先順序來對請求做排程。

資料庫租戶能力大調研

  • 資源組，是資源管理的邏輯單元。任意一個會話屬於唯一的資源組，而同一資源組的所有會話共享同一組資源限額。TiDB 支援資料庫使用者與資源組的對映關係，透過設定資料庫使用者的預設資源組，使用者會話可以分屬於不同的資源組。未指定預設資源組的使用者，與系統內建的 default 資源組相關聯。

  • 資源限額，TiDB 首先支援為資源組配置用量 (RU)。RU (Request Unit) 是 TiDB 對 CPU、IO 等系統資源的統一抽象的單位，目前會考慮 CPU、IOPS 和 IO 頻寬三個指標，按照一定的比例統一到 RU 單位上。TiDB 支援設定資源組為 BURSTABLE 模式，BURSTABLE 模式允許資源組超額使用到叢集的空閒資源。

  • 排程優先順序，預設情況下所有資源組的優先順序 (PRIORITY)均為“中等(medium)”。當資源組在同一優先順序下，排程優先順序按照資源配額的比例分配，這已經能夠滿足絕大多數場景的需要。使用者仍舊可以顯式地指定資源組優先順序為“高(high)”或者“低(low)”，從而完成更復雜的設定。

4).OceanBase 租戶能力
OceanBase 資料庫採用了多租戶架構。多租戶架構適用於資源整合、SaaS 服務等場景，同時也降低了運維複雜度。叢集偏向於部署層面的物理概念，是 Zone 和節點的集合，Zone 和節點具有部署地域（稱為 Region）等屬性；而租戶則偏向於資源層面的邏輯概念，是在物理節點上劃分的資源單元，可以指定其資源規格，包括 CPU、記憶體、日誌盤空間、IOPS 等。租戶類似於傳統資料庫的資料庫例項，租戶透過資源池與資源關聯，從而獨佔一定的資源配額，可以動態調整資源配額。在租戶下可以建立 Database、表、使用者等資料庫物件。

資料庫租戶能力大調研




  • 資源規格，定義常見物理資源項的大小，包括 CPU、記憶體、磁碟空間、IOPS 等。建立資源池時指定其資源規格，從而根據定義建立資源單元。
  • 資源單元（Unit），Unit 是租戶管理中非常重要的概念。OceanBase 按照 Unit 來管理物理資源，是 CPU、記憶體、儲存空間、IOPS 等物理資源的集合。Unit 也是資源排程的基本單位，其具有節點、Zone、Region 等位置屬性，節點是伺服器的抽象，Zone 是機房的抽象，Region 是地域的抽象，透過調整 Unit 的位置屬性從而調整租戶的部署方式。
  • 資源池，每個 Unit 都歸屬於一個資源池，每個資源池由若干個 Unit 組成，資源池是資源分配的基本單位，同一個資源池內的各個 Unit 具有相同的資源規格，即該資源池內 Unit 的物理資源大小都相同。
透過 Unit 的概念，我們將 OceanBase 資料庫的物理概念和邏輯概念進行了關聯。每個租戶有若干 Unit ，分佈於若干 Zone 的若干節點上。而每個節點上分佈有若干個 Unit ，這些 Unit 歸屬於不同租戶。概括的講：叢集由節點組成，節點是 Unit 的容器。租戶由 Unit 組成，Unit 是資料庫物件的容器。

5).PolarDB-X 租戶能力

PolarDB-X 是阿里雲旗下一款分散式資料庫產品。它透過結合非模板化二級分割槽與Locality兩項能力，來解決租戶場景問題。

資料庫租戶能力大調研

  • 非模組化二級分割槽，是指 PolarDB-X 支援使用二級分割槽建立分割槽表。可在各個一級分割槽之下的二級分的分割槽數目及其邊界值定義允許不一致。透過這種方式可以將大小租戶的資料進行不同的資料儲存策略，例如大租戶可以將資料路由到一組資料分割槽中，小租戶可以按雜湊演算法自動均衡到不同分割槽，從而避免訪問熱點。

  • Locality，PolarDB-X 透過這個關鍵字來指定資料庫分割槽的實際儲存資源位置（PolarDB分散式版中儲存資源由多個資料節點（DN節點）組成，可以透過DN的ID進行位置分配），以實現資料隔離或資料的均勻分佈。




3. 資料庫租戶操作示例

1).TiDB 操作示例

資料庫租戶能力大調研

2).OceanBase 操作示例

資料庫租戶能力大調研


來自 “ ITPUB部落格 ” ，連結：https://blog.itpub.net/70027826/viewspace-3000552/，如需轉載，請註明出處，否則將追究法律責任。

相關文章