阅读笔记：Multi-tenant SaaS database tenancy patterns

https://docs.microsoft.com/en-us/azure/sql-database/saas-tenancy-app-design-patterns
之前一直认为所谓的cloud版本的数据库和线下原版的数据库应该没啥区别（除了提供一些基于cloud 的API调用），但是看了这篇文章之后觉得，cloud版本的数据库还是大有不同的，更加的复杂，但是所有的考虑都是来源一个--成本。

多租户的概念，一开始搞不明白，以为就是数据库中不同的帐号，每一个帐号拥有不同权限来执行不同的智能罢了，但是实际上在cloud这个范畴里面，租户可不是普通的数据库里面的帐号，而是代表的使用云数据库的用户。比如说小王买了一个cloud数据库服务，小张也买了一个，那么小王和小张就是两个租户。这个在普通版的数据库使用中很少出现的情况 ，一般就是一个客户使用一套数据库部署而已。

正因为在cloud版本的数据库中拥有多租户的概念，所以在为你的应用购买cloud数据库的时候需要更加仔细一下，了解一下对于多租户模式，云厂商是否提供了多种使用模式，避免以后发现不合适，还要进行切换，这种切换一般都是要收费的。

下面就介绍一下集中多租户的cloud数据库使用模式：

1. 单租户模式：一个租户独享一个数据库实例
2. 多租户模式：多个租户共享一个数据库实例，但是每一个租户使用自己的schema。
3. 混合租户模式：多个租户不但共享一个数据库实例，而且还要共享一个schema
   上面三种，成本由高到低，隔离由高到低。

怎么对上面三种模式进行选择呢，下面有几个参考：
一般不管是哪种模式，应用的使用方式上面一般都是没有影响的。只是在其他的，比如性能，管理，监控方面会有比较大的影响，相信这些东西应该在你的数据解决方案里面也会有着比较重要的位置吧（好多开发者都会忽略掉这个方面，而只是关注业务共嗯那个，这样后面会吃大亏的）

1. 扩展性
   o 你会有多少个租户（有的业务可能会把每一个自己的用户都对应一套数据，以此进行数据上面的隔离，比如wordpress之类的博客系统，每个用户在自己的库里面各自玩，不影响别人的数据）
   o 是否需要每一个租户都独自用一套存储
   o 存储上面是否由混合使用的需求
   o 负载

2. 租户隔离：数据隔离和性能（一个租户的使用会影响到另一个租户的性能）

3. 租户成本

4. 开发复杂度：
   o 是否需要对schema等概念进行代码修改
   o 是否需要在查询里面做一些特殊的改动以适应多租户环境

5. 运维复杂度
   o 监控和性能的管理
   o schema的管理
   o 租户数据的重新部署
   o 灾难复原

A. 单租户单实例模式
这种模式就是，对每一个租户，都独立运行一套数据库系统，肯定多个租户之间不会有什么相互影响的，这个跟我们一般的数据库使用方式一样的。这种模式不管什么监控，性能，管理等方面也是跟现在的一般的数据库实践都是一致的，但是问题就是成本太高，想想一个租户就要使用独占一组进程，一套自己的共享内存，如果大部分时候这个业务不是那么繁忙，那么云厂商肯定会动他的主意的，除非租户说我就是人性，然后给足够的钱，这当然没有问题。

B. 多租户单实例
这种模式是，多个租户启动一个数据库实例，但是给每一个租户分配一个schema，以此实现数据的隔离。这种方式显而易见，启动一个实例，那么就意味着共享一组进程资源了，共享一套共享buffer了 ，虽然存储方面不见得会省。性能方面虽然进程方面是共享的，但是还是可以根据租户区分出来的，让租户独立使用一些进程计算资源，但是共享buffer就完了，所有的租户肯定要一起争抢了，另外数据库中的什么WAL日志，数据落盘，MVCC的一些记录优化任务都要共享了，性能方面肯定是不如单租户单实例模式了。但是有一点还算可以欣慰的是，数据库还是提供了schema层面的监控数据的，比如transaction的执行时间等等都是schema区分，意味着你的监控工具还是可以像单实例模式下一样使用的。
这种模式需要一个实例能够支持非常多的schema，这个估计原版的代码是不能够很好支持的，至少需要改一下，但是估计也不难，一般这种模式都要支持个100,000个schema吧。另外还有其他的一些资源也会暴增，比如索引，都需要单独的优化一下。

C. 多租户单数据库
这种模式是，一个实例中，每一个schema可以支持多个租户，同时还可以有多个这种schema同时存在，想想知道，实现的时候肯定是在schema里面添加的租户标识字段了，这种模式肯定要牺牲掉隔离性了，一个schema本来是一套存储文件，现在这些文件中混杂了多个租户的数据，反正从文件层面是区分不出来租户了，同样，什么性能监控也不用想了，因为数据库对transaction的状态的粒度都是schema级别的。
这种模式的存在就是成本，低廉的成本，所有租户的计算都控制在了一组资源里面，而且在进程利用率方面，实际上没法区分租户的，基本上都是共享。
用户选择这种模式，一个是看重的低成本，第二，因为这种模式能够实现非常多的租户（是用schema中一个字段来标识租户数 ，肯定比实例中的支持的最大数据库数要多很多）。

考虑sharding的情况
上面每一种模式会有一些响应的sharding的情况，大多就是根据租户标识进行sharding，实际上也没少好说的 ，顶多就是一个租户的数据最好shard到一个存储节点上面的一些优化方法。sharding是一个双刃剑，做shard肯定就需要维护一些mapping，这就要看业务具体的情况了，业务设计者多操心吧。

最后是一种多种模式融合的场景：
一个业务，比如wordpress博客之类的 ，或者在线ERP之类的等等，首先提供一个免费注册体验的业务，即用户注册之后，免费获得一个临时使用机会，这个时候就可以给这个用户在第三种模式中分配一个租户，让他随便去用好了，但是不提供性能保证。如果这个用户购买了一般性的服务，那么就给他转移到第二种模式下去，如果这个用户购买了最高级别的业务，那干脆把这个租户放到第一种模式独享资源好了。想想这种设计还真的是很不错的，如果自己搭建本地的数据库服务的话还真的很难实现这种场景。感谢云数据库。

Over