举个例子，比如说上图中的右边是我们的数据，左边是我们的用户。

成都分公司总经理能够从级别这里看到所有的数据。但是他在目录这个级别的话，他只能看到成都的机密级别以下的数据。同时，因为他的组里面有工程部和人力资源部，他只有这两个，也就是说他能够看到工程部和人力资源部的成都的数据。对于总部的人力资源总经理的话，我们就会发现他能看到北京和成都的，也就是说能看到所有归属地的员工的人力资源里面的数据。对于董事长来讲，一般董事长的级别能够看到所有的安全级别的数据，他能看到北京和成都两地的数据。在组的关系上来讲，董事局一般是整个公司部门里面最高级的部门，所以他在组这个级别上，他就能看到他下属所有部门的数据，也就是说对钢铁侠来讲，他能看到整个公司全部的数据。通过这个安全规则我们就可以做到对数据做到行级的过滤、行级的保护。

2、TBase的列级安全规则。

在TBase中是通过访问控制列表来实现的，也就是说我们会在每一个列上加一个ACL的列表来指定这一列对谁有权限，谁没有权限。

比如：我们在薪酬上设定说普通员工是没有权限访问，对蜘蛛侠或者普通员工来讲的话，他看到的数据就只有他自己的数据。但是对于钢铁侠来讲，因为钢铁侠是董事局的主席，他能看到这两列所有的数据。通过行级权限控制和列级权限控制可以得出我们对表里面的数据能够做到行和列的任意访问的控制。

3、TBase数据脱敏和加密。

脱敏和加密面对的场景有一些差别，加密主要面对的是数据文件本身的泄露，比如我的文件被别人拖走了，然后他通过代码可以把数据解析出来。我们现在常见的数据库的存储格式基本上来讲是属于半公开的状态。也就是说大家只要拿到了数据库的数据文件，只要有一个数据程序就可以把它解析出来，我们要通过数据中心的加密防止泄露。脱敏主要指的是我的数据在访问的时候，有些数据的用户是没有权限去看到它的明文的，但是它还用一些运维的操作或者其他一些工作上的需要，他需要能访问这些数据，但是他不需要真正看到这些数据，这两个是完全不同的需求。加密在存储层的时候，存储的是密文，只有在执行这个程序的时候才会对数据进行解密和加密，然后把它反馈给用户。对于脱敏的话，存储的是明文，在buffer里面也是明文，只有在用户访问的时候，我们授权用户、非授权用户来进行公平的处理。对授权用户得到的就是完整的数据，对非授权用户得到的数据就是脱敏以后的结果。加密和脱敏可以进行混合的使用，也就是说我们既可以对存储内容加密，也可以针对不同用户采用用户的一个脱敏的规则，来保证我数据访问的一个隔离。

下面针对TBase MLS透明脱敏和透明加密举个例子。

我们有两个脱敏和加密的规则，也就是说我们会针对非董事长用户进行加密的脱敏。脱敏之后的数据，我们可以指定一个任意的值来展示给这个非授权用户。现在我们对于这个非授权用户，也就是说对于成都的分公司总经理和总部人力资源总经理，他们看到这两个数据，一个是0，一个是1。但是对于董事长来讲，因为他是超级用户，他是没有受到加密和脱敏的约束的，所以他看到的数据是正常的数据。通过这种方式我们就可以很好的来隔离系统里面不同等级用户对于同样一些数据看到的视图，达到一个隔离的效果。

另外，跟大家分享下TBase MLS的审计能力。

TBase具备完整的审计能力：1、语句审计，对特定的语句类型进行审计；2、对象审计，可以针对数据库的某个对象，比如说一张表，或者一个数据库，甚至一个索引来进行一个审计。3、记录用户审计，记录用户所有的访问。4、还有一个比较好玩儿的功能是TBase的一个系统的审计，我们可以做一些针对用户自定义的审计规则，比如审计的时候，我们判断如果用户的余额大于这个值的时候，我们就会把它的审计结果记录下来。同时我们还会自定义它的审计的一个动作，也就是说如果这个条件被触发了之后，我们会去做什么事情。比如说上面这个例子是我们会调用一个发文件的功能来做我们的审计。

PartⅢ TBase客户案例

下面介绍一下TBase的客户案例。

TBase最早是在2016年初的时候替换了微信支付原有的分库分表的MySQL集群。当时大概每天只有500万笔，后来支撑到每天数亿笔。整个过程中我们保证了微信支付业务的连续性和稳定性。

主要有几个策略：

第一个是大小商户策略。微信商户系统，商户业务不同于个人业务，存在大商户和小商户的区别。大商户像大型的网购平台，还有电商平台，它都属于大商户。小商户就是各种各样的小店，他们的数据量不一样的，所以我们需要对于不同的用户量来进行一个处理，来保证两边服务的质量。

第二个是冷热分离的策略，因为对于微信支付的系统来讲的话，它的冷热存活都是我们的订单数据，都是跟钱相关的东西。这一块来讲的话，跟我们相关法律的要求，这些数据我们需要存储四年以上。但是，其实对于其中的数据，绝大部分来讲，比如说三个月以前的数据访问量是非常低的，我们如果都使用相同的存储策略，我们整个集群有400多T的数据，如果都是用成本较高的SSD存储，效率和成本之间不是最优的结果。所以我们就需要一些针对最近3－4个月的热数据和4个月以前的冷数据采用不同的存储策略，来帮助业务降低成本，同时来保证我们业务的访问效率。

第三是我们还为业务提供了一个跨城容灾的能力，来保证业务的连续性。

由于来访问这个系统的业务有很多种，运维的同学也会有潜在的不同的各种各样的应用程序，我们需要针对不同的应用程序或者不同的用户，来提供不同的数据视图，来保证我数据整体的可靠性。这个是前面提到的第四是MLS的安全系统。

总结一下，微信支付整个集群大概是这么一个结构。

图中最上面是我们CLB，是腾讯内部的一个负载均衡的组件。CLB下面是我们的接入节点，我们在内部首先把数据会分为大商户和小商户，在下面可以看出来小商户热数据集群，小商户冷是商户冷数据集群，大商户热是大商户热数据集群，大商户冷是大商户冷数据集群。冷热集群之间的差别在于说存储设备是不一样的。热集群主要使用的是SSD的设备，冷集群使用的是普通的TS5的设备，降低存储成本。整体来讲的话，通过这种方式之后，我们就把我们整个集群的成本降低到了ICB存储的四分之一左右，全部使用ICB存储的四分之一。

在外部我们有一个比较大的保险公司，然后上线了200多个TBase实例在跑保险的核心业务，这里只展示了我们的部署架构。

我们上面分为两个平面，一个是读写平面，一个是只读平面。读写平面，业务通过VIP来提供读写能力。我们的只读平面通过业务VIP在多个节点做负载均衡，提供一个业务的只读能力。然后TBase的数据在生成之后，我们还需要把这个数据同步到我们其他的一些系统里面去，比如说ES、INFORMIX、MONGODB或者说MySQL，甚至同步到Oracle里面去。同步到Oracle和INFORMIX里面去主要是为了保证业务切换的可靠性，也就是我们把数据再回写回去，来保证这个切换过程中的稳定性。需要补充一下，TBase在往这个后面同步数据的时候，其实我们是先通过自己的逻辑解析的数据，把数据解析成了Json格式，通过Kafka同步过去。

PartⅣ 国产化能力建设

下面介绍一下TBase在数据库国产化方面的工作。第一个，在国产化平台上面，我们支持了国内主要的平台，包括华为的泰山，还有中标麒麟。在操作系统这一块的话，中标麒麟已经支持和UOS也在支持中。国产芯片这一块， X86和ARM我们是支持的比较好的。

在国产化计划这块，一定会提到数据库的异构迁移，TBase现在已提供了完整的数据库迁移服务。

主要分为两部分，一部分是工具，在工具这一块的话，我们有数据的迁移工具，数据迁移评估工具以及数据校验的工具。同时我们还提供了专门的专家咨询服务，专家咨询的话，我们会有一些迁移评估，方案设计，改造建议，优化建议等等。通过整体的解决方案，我们会把数据从原有的商业数据库，包括Oracle、MySQL等等可以把它很可靠的同步到TBase里面来，来解决数据库国产化替换的一个数据迁移的问题。

在硬件这一块的话，现在我们常见的几种硬件进行了性能的评测，下面是评测结果。

在前面提到的X86环境下的话，我们在服务器上跑了68万TPM。然后LinuxOne能跑127万，测试结果跟服务器的配置有关系。说到数据库的国产化替换，肯定是绕不开Oracle兼容的，Oracle兼容TBase做了相当多的工作，包括我们的对象的支持，数据类型的支持，函数，SQL特性和存储过程。这一块我们后续会进行一些增强和扩展，来提升我们的兼容度。

PartⅤ Q＆A

Q：分布式表的库备份，所有的DN都要独立备份一份吗？

A：TBase每个DN是整个数据库的数据的分片，所以说在备份的时候，至少每个DN是要备份一份出来的，但是它不是独立的一份，因为在备份逻辑里面会控制保障整个集群的完整性，也就是各个DN之间，每个DN都会有一个相应的副本存储到冷备里面去。

Q：冷备这块最大一致时间戳方式，会不会因为服务器之间的时间差异造成备份不一致？

A：冷备的时间戳问题，我觉得这个不用担心，分享中我提到有5种方式：1）分布式快照隔离；2）绝对物理时间隔离；3）硬件绝对物理时间隔离；4）本地时间隔离；5）逻辑时间戳的隔离。TBase使用的是逻辑时间戳，这个时间戳不是本地的时间戳，是TBase内部的时间戳，我们会保证它的稳定性和单向递增，它不会发生反转，也不会发生偏移，而且它有容灾的特性。即使机器发生故障，然后再把它拉起来，它也是能保证整个稳定性的。

Q：时间戳是个全局自增值吗？gtid？

A：至于说这个时间戳是不是一个自增值，简单理解上，说是自增值是没有问题的。但是核心问题是我们需要保证它，不能让它有全局瓶颈，不能让它因为一把锁，把它全局吞吐量都拉下降了。

Q：安全控制方式上，select 如何输入token？

A：TBase的安全控制方式更多的是通过用户的接口，比如说安全管理员，他会有自己的一套接口来创建自己的密钥，创建自己的安全规则。

Q：冷热数据分离是通过人工方式做的还是自动方式？判断冷热数据的标准是啥？有没有采用存储分层的能力自动来判断？

A：至于冷热分离的转储是存储层的设置策略还是在云数据库层去做，其实冷热转储这一块，冷热的访问逻辑和逻辑的定义是在数据库里面定义的，但是冷热的转储，是通过TBase的管控系统来做，这个逻辑相对来讲还是比较重，我们需要有一些专门的机制来保障它的可靠性和易用性，所以TBase整个把它移到了管控系统里面来。

冷热分离的方式是人工去定义的，我们根据的业务逻辑来定义哪个数据是冷，哪个数据是热的。但是它的判断，它下层的迁移的逻辑是自动的，只要把这个规则定义好了之后，整个系统会自动的运行，不需要人为干预。

判断冷热的标准是什么，举个例子，比如说微信支付是四个月的数据是热数据，四个月之前的数据是冷数据，其实是按照时间来判断的，我们取当前的时间往前面算，往前面偏移。超过了一定的阈值它就是冷数据。

关于存储分层之后，TBase更多是从数据库本身的能力来做。

Q：备份工具是原生内置的吗？

A：TBase的备份工具不是数据库内置的，是我们在管控里面做的，说句实在话，冷备这一块东西需要打交道的周边模块比较多。比如需要把冷备的数据同步到一个外部存储里面，外部存储有可能是一个磁盘阵列，有可能是一个HDFS，也有可能是一个其他的存储，这些东西放在数据内核里面不合适，太重了，冷备功能是我们提供的独立工具来做的。

Q：TBase本身就是一个数据库引擎，它不是一个数据库中间件？

A：TBase本质上是一个数据库引擎。今天我讲的PPT里面，大家可以看到，整个过程中其实我都没有提中间件，一直在讲数据库底层引擎的一个原理，比如说优化器的原理、执行器的原理，还有分布式优化逻辑，以及我们的分布式事务的逻辑，其实都是引擎里面的原理。中间件一般只会做SQL解析、SQL转发和结果的返回，很少涉及到执行计划。

Q：PUSH QUERY和PULL DATA如何选择？

A：其实PUSH QUERY和PULL DATA这个选择没有一个严格的界限，一般PUSH QUERY在数据量相对比较大的时候会比较有效一点，因为把QUERY下推之后，下层节点的执行会过滤掉大部分数据，拉取的数据量大大的减小。然后PULL DATA在一些简单的查询，表非常小的时候，把它拉回来算可能更快一点。这一块选择没有严格的标准，可以根据我们的场景决定。

Q：如果是从ORACLE转到分布式数据库有哪些知识需要补充？

A：说实在话， Oracle是一个发展了三四十年的数据库产品，整体的架构和功能都非常强大了。分布式数据库是一个新兴的领域，产品架构，包括它的生态也都是一直处于建设和完善中，因此在调优、使用和数据业务的建模这一块跟以前的Oracle还是有所区别的。从哪一块入手，我觉得这要看你使用的是哪些分布式数据库。如果是MPP的话，可能就需要了解一下MPP里面的关键点。比如数据的分片怎么分，跑SQL的时候，怎么去结合分布逻辑去很好的设计SQL，这个可能是在接触分布式数据库的时候需要考虑的一个比较重要的问题。

Q：两个大表分布在不同的DN，做HASH，如何保证选择正确的执行计划和高效率？

A：两个大表分布在不同的节点里面，我们要进行一个查询，如何提升它的效率。如果两个大表，首先第一个来讲，我们得搞清楚这些表进行查询的时候关联的KEY有哪些。比如说如果我们都是使用这一列进行关联，那是不是可以在设计的时候就按照性能这一列进行数据的分片，在进行查询的时候，就可以下推到每个DN节点来执行，换句话说每个DN节点的执行层是并行的，没有相互之间的交互，这样效率在分布式的时候是最高的。

如果这个表查询的SQL非常多，一张表有一两百个字段，但是关联的时候，有的是按照分布KEY进行关联，有的不是按照分布KEY进行关联，这个时候就得有一些取舍。要看一下，如果按照分布KEY进行关联效率会最高，而且可能会比不按照分布KEY的效率高不少，那么我们会选择优先的把我们业务里面用到的一些频率比较高的，要求比较高的一些SQL优先的按照那些SQL来设计表的分布方式。然后对于其他的一些SQL，对于那些JOIN的列进一步建索引，提升查询效率。

另外在写SQL的时候，尽量做到某个节点上进行查询的时候，能够通过我们表达式的过滤掉一些无效的数据传输，这样的话就可以保证一个相对比较好的效率。

Q：学习分布式数据库有哪些知识要补充？从哪里开始？A：至于说这些数据库知识有哪些需要补充，我觉得是这样的，数据库本身是一个比较古老的技术，如果说从哪里开始，有机会的话，从使用开始就最好了。比如说先做一些最简单的数据库的使用，建表、生成数据，最好有一个业务系统作为驱动，边用边学，这样上手更快一些。

Q：TBase代码开源了吗？A：TBase的代码已经开源，大家有兴趣的话，欢迎访问：https：／／github．com／Tencent／TBase。TBase预计今年年中左右会重新推动一个新的版本出来，大家敬请期待。

以上是今天的分享和Q＆A的解答，感谢大家的聆听。

TBase是腾讯TEG数据库工作组三大产品之一，是在开源的PostgreSQL基础上研发的企业级分布式HTAP数据库管理系统。通过单一数据库集群同时为客户提供高一致性的分布式数据库服务和高性能的数据仓库服务，形成一套融合完整的企业级解决方案。