GreenplumはMPPは、プラットフォームの上にビッグデータ、クラウドの時代へと進化したデータウェアハウスから、開発の15年後、最高のオープンソースのデータベースです。
記事のこのシリーズは、クラウドのすべての側面のためのGreenplumはサポートをご紹介します。マルチテナントに焦点を当てBenpian。
1.マルチテナントは何ですか
これは、複数のテナントをサポートできるマルチテナントシステムを指します。テナントは、典型的なテナントが同じ組織や企業内の複数のユーザーで、通常、同様のアクセスモードと権限を持つユーザーのグループです。
マルチテナントを実現するには、あなたが最初に考慮する必要があることは、マルチテナントのデータレベルです。マルチテナントモデルデータ層は、上位マルチテナントサービスと達成するためにアプリケーションに顕著な効果を持っています。この記事では、さまざまなマルチテナントモデルのデータ層マルチテナンシーとGreenplumはデータベースのサポートに焦点を当てています。
マルチテナントの異なる実装を計量、以下の要因を考慮してください。
- スケーラビリティ:テナントレベルの数だけでなく、今後の動向
- セキュリティ:テナント要件の間のデータの分離レベル
- リソースの共有:マルチテナント、通常はリソースの共有のいくつかのフォームを持っている、悪いテナントSQLを回避する必要性は、システムリソースを食べて、他のテナントの応答時間に影響を与えます
- 柔軟性:別のテナントが異なるニーズを持っていることがあり、特定のテナントのためのスケーラビリティの需要
- クロステナント解析と最適化:すべてのテナントや複数のテナントのためと行動のデータ分析機能
- 運用・保守・管理:モニタリングを含む安価で操作および保守管理の複雑さ、データベース・スキーマを変更する、索引を作成し、統計を収集し、データローディング、等
- 費用:総所有コスト、プログラムの導入コスト、運用・保守費などを含みます
2.マルチテナントモデル
マルチテナント・モデルは、テナントとテナントのデータとの間のマッピングを記述します。異なるマルチテナント・モデルは、データベースとアプリケーションの設計、管理、メンテナンスに影響を与えます。
複数のマルチテナントモデルを使用して、3つあります。Greenplumは、これら3つのモデルは、優れたサポートを持っています。
2.1テナントデータベース
マルチテナントを実現する最も簡単な方法は、Greenplumは、以下に示すように、各テナントのクラスタを作成することです。各アプリケーションは、テナントのテナントIDが割り当てられ、各テナントのための適切な接続情報データベース(等IP、ポート、を含むデータベース)を設定されています。アプリケーションは、テナントIDに従って割り当てデータベースに接続します。
このデータ・モデル異なるテナント物理的な分離、高いセキュリティレベル。各テナントGreenplumはクラスタが異なるハードウェアを使用している場合は、それらの間のリソースの使用を物理的に分離され、テナントGreenplumはクラスタは、ハードウェアの同じセットを共有している場合、あなたは相互作用を避けるために、適切な資源配分と管理を必要としています。別のテナントは(そのような追加フィールドの必要性など)異なるテナントの特定のニーズを満たすために別のデータベース、柔軟性、および使いやすいを使用しているため。影響力は、障害が発生した場合をファセット。欠点は、データベースのその多数、メンテナンスの複雑さ、所有コストが高いことです。テナントシーンの適した比較的少数。
2.2テナントネームスペース(スキーマ/名前空間)
複数のテナントが同じデータベースを共有し、各テナントは、別個の名前空間(またはモード)を有します。各アプリケーションは、テナントIDを割り当て、割り当てられた名前空間/モードでの各テナントのためのすべての動作制限されます。図に示すように。
データ・ロジックの異なるテナントに互いに分離このマルチテナントモデルにおいて、安全制御は比較的簡単です。別のテナントが簡単に別のテナント、および高い柔軟性の特定のニーズを満たすことができ、異なるモードを持っています。別のテナントを回避するために、高い資源管理能力の要件は、リソースの競合します。Greenplumは組み合わせfilepaceと表領域のプロパティは、あなたはディスク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、ユーティリティ文 | それはあります | ノー |
セグメント・レベルの監視および管理 | それはあります | ノー |
ルールベースのリソース管理 | それはあります | ノー |
Greenplumは、シーンにマルチテナントクラウドにきめの細かいリソース管理を実現することができ、それは、資源の合理的な利用を確保するために、資源の過剰消費を避けるために、テナントリソース隔離テナントに適しています。
詳細については、公式ドキュメントを参照してください https://gpdb.docs.pivotal.io/580/admin_guide/workload_mgmt_resgroups.html
4.まとめ
マルチテナントは、基本的な要件のクラウドデータベースで、Greenplumは記事には4つのマルチテナント実装を説明し、それを比較しました。Greenplumはまた、リソースの共有やマルチテナントの分離を実現するために、新しいエクスプローラベースのリソース・グループを導入しました。