Greenplum 是最出色的開源MPP數據庫,經過15年的發展,從數據倉庫發展成了雲時代的理想大數據平台。
本系列文章將從各個方面介紹Greenplum對雲的支持。本篇側重多租戶。
1. 什么是多租戶
多租戶指一套系統能夠支撐多個租戶。一個租戶通常是具有相似訪問模式和權限的一組用戶,典型的租戶是同一個組織或者公司的若干用戶。
要實現多租戶,首先需要考慮的是數據層面的多租戶。數據層的多租戶模型對上層服務和應用的多租戶實現有突出影響。本文重點介紹數據層多租戶及Greenplum數據庫對各種多租戶模型的支持。
權衡不同的多租戶實現方式時,需要考慮如下因素:
- 擴展性:租戶數量級別,以及未來發展趨勢
- 安全性:租戶之間數據隔離級別要求
- 資源共享:多租戶通常有某種形式的資源共享,需要避免某個租戶的糟糕SQL吃掉系統資源,影響其他租戶的響應時間
- 靈活性:不同租戶可能有不同的需求,對特定租戶需求的擴展能力
- 跨租戶分析和優化:對全部租戶或者多個租戶的數據和行為進行分析的能力
- 運維和管理:運維管理的復雜度和便宜性,包括監控、修改數據庫模式、創建索引、收集統計數據、數據加載等
- 成本:總體擁有成本,包括方案實現成本、運維成本等
2. 多租戶模型
多租戶模型描述了租戶和該租戶的數據之間的映射關系。不同的多租戶模型會影響數據庫和應用程序的設計、管理和維護。
使用較多的多租戶模型有三種。 Greenplum 對這三種模型都有出色的支持。
2.1 一租戶一數據庫
最簡單的多租戶實現方式是為每一個租戶創建一個Greenplum集群,如下圖所示。應用程序為每個租戶分配一個租戶id,並為每個租戶配置相應的數據庫連接信息(包括數據庫ip、端口等)。應用程序根據租戶id連接到為其分配的數據庫。
這種模型中不同租戶的數據物理隔離,安全級別高。如果每個租戶的Greenplum集群使用不同的硬件,則他們之間的資源使用也是物理隔離的;如果租戶的Greenplum集群共用同一套硬件,則需要對資源進行合理分配和管理,避免相互影響。由於不同租戶使用獨立的數據庫,靈活性好,容易滿足不同租戶的特定需求(譬如需要額外的字段)。出現故障時影響面小。缺點是數據庫數量大,維護復雜,擁有成本高。適合租戶數目比較少的場景。
2.2 一租戶一名字空間(Schema/Namespace)
多個租戶共享同一個數據庫,每個租戶擁有獨立的名字空間(或模式)。應用程序為每個租戶分配一個id,並把每個租戶的所有操作限制在為其分配的名字空間/模式之中。如下圖所示。
這種多租戶模型下,不同租戶的數據邏輯上相互隔離,安全控制相對簡單。不同租戶有不同的模式,可以簡便的滿足不同租戶的特定需求,靈活性高。對資源管理能力要求高,以避免不同租戶競爭資源。結合 Greenplum 的 filepace 和 tablespace 特性,可以把不同租戶的數據存儲在不同的磁盤上,降低了對磁盤IO的競爭。運維和管理較復雜,不易實現大量租戶的跨租戶分析。適合租戶數目適中的場景。
2.3 全共享方式
不同租戶共享同一個數據庫、同一個名字空間。不同租戶的數據在同一組表中共存,通過租戶id標記和訪問不同租戶的數據(應用需要調整訪問數據的SQL以包含租戶id)。如下圖所示。
這種多租戶模型中,不同租戶的數據物理存儲在一起,對系統的資源隔離和安全隔離要求很高。運維相對簡單。擴展能力好,可以支持較多數量租戶。由於租戶數據存儲在一起,跨租戶數據分析和優化非常簡單。成本低,可以較低的代價支持更多的租戶。
全共享模型中,很多數據庫采用添加大量自定義字段的方式滿足不同租戶的特定需求,以提高靈活性。這種方式有諸多局限性,譬如字段數目不能太多、管理復雜等。Greenplum 自 5.0 開始支持更多半結構化數據,包括JSON、Hstore 等,通過這種半結構化數據,可以更靈活、高效、便捷的滿足不同租戶的特定需求。
2.4 混合模型
這種模型不是一個新的實現方式,而是混合前面介紹的三種模型以滿足不同用戶的服務級別需求。譬如對於最大的少數幾個租戶采用一租戶一數據庫的模型,其他租戶采用全共享方式。或者對資源隔離級別要求高、服務響應時間要求高的客戶采用一租戶一數據庫的模型,其他租戶采用一租戶一名字空間方式或者全共享方式。
2.5 對比
下表列出了不同模式的特點。混合模型兼具不同模型的優缺點,不再單獨列出。根據不同需求可以采用不同的實現方式。
特性 | 一租戶一數據庫 | 一租戶一名字空間 | 全共享 |
擴展性、租戶數量 | 低 | 中 | 高 |
安全隔離 | 物理隔離 | 邏輯隔離 | 依賴數據庫和應用安全控制 |
資源隔離 | 若用不同集群,則高;否則依賴數據庫資源管理特性 | 依賴數據庫資源管理特性 | 依賴數據庫資源管理特性 |
靈活性 | 高 | 高 | 通過JSON等半結構化數據類型提供較高靈活性 |
跨租戶分析 | 很難,需要跨庫查詢 | 難,需要跨模式查詢 | 容易 |
運維管理 | 復雜度高 | 復雜度中 | 復雜度低 |
對應用影響 | 低 | 低 | 較高 |
成本 | 高 | 中 | 低 |
3. Greenplum 資源管理
上面提到,不管使用何種多租戶模型(除非是不同的物理集群),否則都涉及到資源管理的問題,以滿足不同租戶的不同資源使用需求,避免某個租戶過度使用資源,影響其他租戶。
Greenplum 5 設計實現了一個全新的基於資源組的資源管理器,相比之前的資源隊列,可以做到靈活高效的資源管理。
下表對資源組和資源隊列進行了對比:
特性 | 資源組(Resource Group) | 資源隊列(Resource Queue) |
並發控制 | 事務級別 | 語句級別 |
死鎖 | 無 | 極端情況下會出現 |
CPU 管理 | 基於比例、基於cgroup | 基於粗粒度的優先級 |
CPU 空閑利用率 | 可以充分利用空閑CPU | 部分利用 |
內存限制 | 精細 | 粒度粗 |
組內內存共享 | 是 | 否 |
動態修改資源配置 | 是 | 部分 |
排隊 | 無並發槽位或者內存配額時 | 無並發槽位時 |
管理DDL、Utility語句 | 是 | 否 |
Segment級別監控管理 | 是 | 否 |
基於規則的資源管理 | 是 | 否 |
Greenplum 可以實現細粒度的資源管理,在雲上多租戶場景下,非常適合實現租戶的資源隔離,避免某個租戶過度占用資源,確保資源合理使用。
有關更多細節,請參考官方文檔 https://gpdb.docs.pivotal.io/580/admin_guide/workload_mgmt_resgroups.html
4. 總結
多租戶是雲數據庫的基本要求,本文介紹了Greenplum的四種多租戶實現方式,並對之進行了對比。還介紹了 Greenplum 新的基於資源組的資源管理器,以實現多租戶的資源共享和隔離。