HANA与PostgreSQL的多租户方案的对比
前言
前几天，韩峰老师在他的文章数据库租户能力大调研 【https://mp.weixin.qq.com/s/v4FXliZNFFEfJCTTG7YMWA】里非常详细的介绍了几种数据库的多租户能力及相应的大致实现方案。
涉及到：Oracle、PostgreSQL、OceanBase、TiDB、PolarDB-X。
当然，那些基本上也都是云上的多租户能力及方案，这里有感而发，也说说HANA DB以及PostgreSQL (AWS, Azure, GCP)他们在云上如何处理比较合适的处理多租户。
简单对比
About HANA
HANA在最初几年，也是以Tenant DB的形式来处理多租户的，但是每个 TenantDB配置的资源较重。相应的物理配置以及维护性任务自然就重。对于本地系统，支持多个客户共享一个HANA服务，还是可以的。但是一旦碰到大量的租户，就有些显得笨拙了。当然好处也如上前文所说，隔离性好，备份与恢复也相对直观简单。租户之间完全感受不到其他人的存在。
后来，HANA搞了一个大杀器，那就是基于HDI Container技术（内部隐含schema based)的多租户实现技术。个人觉得它是目前最先进的面向多租户的实现方案之一。
1） 轻量级。一个计算单元配置单位（双cpu + 32G），可以直接配上很多个租户（50个起步）。每个客户都在自己的HDI Container当中。相互隔离。租户数量也是可以配置的。这种container可以动态创建和销毁。
2）高度安全性。同一个HANA实例，下边的container， 在配置完成之后，可以动态选择一个schema/container完全加密，加密级别是container级别的。并且加密的key完全由客户指定。
3）良好的隔离性。PITR可以做到container级别。就是说数据的恢复可以基于某一个container。而别的schema/container完全不受影响，业务照常运行。
4）基于container的资源可配置。管理员可以针对某些container, 根据实际情况，赋给较多的cpu/内存资源。也就是说在schema一级，HANA完全可以做到资源的可胖可瘦，满足实际不同级别的租户的资源需求。
这些东西，基本上都是围绕实际系统的一些痛点，有针对性的功能增强。
About PostgreSQL
相比而言，PG要做到以上几点，可能会有一些难度。
1） 一租户一库的方案，意味着一个实例，不会支撑太多的租户。对于有大量用户的公有云环境，更多的时候，采取的可能不是这个方案。
2） 一租户一schema，由于schema位于同一个数据库下边（节省资源），考虑到一个库下边的文件数量，也直接决定了schema下边的表的数量不宜太多。如果一个租户下边要有300张表，那么，20个租户（schema) 就可能达到6000张表。涉及到的文件数量，可以多达48000个。一实例，建多库，每库再多schema。似乎可行。但是目前，aws几家提供的PG都是一实例就一个数据库。这种方案其实性价比也不怎么样。与HANA相比，支持的租户数量有限。
3）多租户共享表，以列值区分。这种方案，从使用数据库的成本角度来讲，数据量不大的情况下，确实可以支持更多的租户。不便利的地方是应用端需要自己实现数据隔离（行级别安全性，虽然可以，但未必好实施）。数据量大的时候，保持满足客户要求的性能，也是有一定的挑占性的。数据备份与恢复而言，针对单个租户的数据的恢复，难度与复杂度会大大提高。实际场景：共享一张表的情况下，如何恢复某一个租户的数据，而其他租户不受影响？这些都是需要单独的技术去实现的。
从数据安全加密的角度来讲，PG如果面向共享表，那么面向单租户的加密处理，则更是有挑战性。面向schema，则可能相对简单，毕竟里边的表相对独立。
在实际的应用当中，PG可能会结合schema和共享表，比较重的租户，给他独立的schema, 一些小鱼小虾的租户，直接扔给他们共享表，达到一个动态均衡。生点考虑的地方是统一管理这些数据源。
也正因为有很多工作要做，基于PG的国产数据库如果能集中解决一些痛点，让它更好的处理多租户，并且总体成本可控，那就是一个很好的国产化方案。
小结
云上的数据库，多租户的数据存储与处理，刚开始的时候，可能就要规划好。这与传统的本地部署的服务于少量租户的情况，还是有很大不同的。同时，考虑到总的存储成本、维护成本，以及安全性，数据的备份与恢复，情况都有不同。
也正因为这样，PG还有很长的路要走。对于广大PG相关的DBA以及架构人员而言，也未尝不是一件好事。
