对话ACE第四期：分布式数据库未来发展的挑战和机遇

伴随着云计算、大数据技术的发展，传统信息技术及应用受到了巨大冲击，数据库作为基础软件也迎来了新的挑战和机遇。同样数据使用场景呈现多元化趋势，数据规模也随之爆发式增长。海量异构数据的爆发式增长，对数据库的存储和计算能力提出了更高的要求。

未来，传统的基于单物理服务器节点的数据库将在更多的场景下被分布式数据库取代，分布式数据库应用前景将越来越广。

《对话ACE》第四期活动便围绕“分布式数据库未来发展的挑战和机遇”为背景，邀请到极数云舟创始人&CEO、Oracle ACE Director 周彦伟，OceanBase 产品和解决方案部高级总监王南共同探索“分布式数据库未来发展”，以此推动分布式数据库技术更好的发展。

以下为对话实录：

📣OceanBase产品和解决方案部高级总监 王南

Q：OceanBase 完全自研的国产分布式数据库，在设计之初，会有哪些难点？

对于 OceanBase 而言，并非从设计之初就考虑到要解决更长期阶段的问题和难点。这其中有一个决策和立项的过程，包括能够解决什么问题，产生什么样的价值，需要多大的投入，需要多长的时间和代价才能解决这样的问题。早期是基于场景和问题去逐步解决的，间接的分阶段完成整个认知过程。

第一个阶段源于淘宝的场景，解决的是核心数据规模和数据量，包括数据访问的吞吐在不断增长的情况下能够应对业务增长。第一步解决的还是分布式的问题，是没有关系模型的一个分布式的 NoSQL。随着淘宝场景的问题解决后，更多的业务场景同样存在扩展性的诉求。很多场景本就是基于关系型数据库去做支撑的，对于数据库的诉求，部分业务是可以通过应用层改造来解决，但大量的业务如果要走向通用场景的话，关系模型还是一个很必要的诉求。

第二个阶段在解决分布式的问题后，逐渐完成关系模型，支持SQL能力。随着 OceanBase 从蚂蚁和支付宝内部开始走向通用市场，可以看到很多业务场景既有基于 MySQL 开源生态的，也有基于 Oracle 商业生态的，所以应用如何能够迁移到新的分布式数据库上来？其实有一个很大的问题。

第三个阶段就是能做到很好的兼容，对于用户来讲，在应用层包括迁移过程中的成本和代价是什么样的，OceanBase 在解决了 MySQL 兼容性后又完成了 Oracle 的全面兼容，包括语法、语义和存储过程等等。

再之后会遇到关键问题和挑战就是随着数据量的增长达到一定规模后，对于 AP 的能力的诉求还是比较强的。HTAP 的能力在当前阶段，是一个关键的难点和技术挑战。同样随着云计算的发展，对于云基础设施甚至跨云异构云的支持，也会有很多客户的诉求。

所以在设计之初包括发展过程中的技术难点，其实是在支持和服务客户的过程中逐步去发现的。

Q ：在银行、保险等金融场景很多企业已经选择分布式数据库作为核心首选，那么未来在哪些场景内还会存在类似的情况？

之前 OceanBase 在金融场景应用会更多一点，近两年时间除了金融之外，我们已经在通用市场的很多企业里面开始应用了。这个问题有比较多的影响因素，今天我主要从产品和技术这个视角来去探讨和分享一下。

在目前已经大量应用的分布式数据库的核心场景来看，他们选择分布数据库。其实有几大类的原因，大家都是基于几大类的这种不同的诉求和考虑来去选择的。

第一，有核心系统迁移需求的用户。这些用户往往不是从业务诉求驱动，因为这种场景下，用户选择一个什么样的架构，是集中式还是分布式，不是特别强的一个强约束，而是更关心在 Oracle 的兼容、切换和替代过程中，是否能够高性价比的平滑迁移。

第二，解决连续性问题的用户。对于数据库的供应、购买、包括数据库服务能力等面临越来越多的这种挑战，所以连续性可能也是重要原因之一。

第三，有真正业务诉求的用户。因为选择的本质最后还是要回到商业，或者回到市场，来选择一个产品到底是不是经济、划算、正确。从这个视角来看，无论是客户业务量的迅速增长，然后导致的对于数据库或者数据管理这一层扩容、扩展的诉求，还是因为数据量的过大，集中式的架构没有办法承担未来业务诉求和数据量。这类用户其实他的诉求是更刚需的，也是更迫切的，也是能够触动和驱动用户真正下决心去做技术升级改造的很核心的因素。

这个过程里面，用户关心的关键因素除了数据库自身能力，包括功能、性能、规格、安全这些能力是否满足之外，还有一个比较大的因素就是应用迁移的成本和代价。数据库作为基础软件和应用有很大的差异，替换时对于比较复杂的各种业务系统，影响和代价比较大。

所以说对于什么场景会选择分布式和什么场景会选择一个新数据库，其实是两个概念。对于选择数据库，大家更多地考虑数据的安全性和规格是不是能满足。但是对于是否选择分布式，这里面需要有一些核心诉求的：要么是原有的单一金融系统没有办法能够满足诉求；要么是我为未来做一些技术上的升级和储备。最终未来可能还会有哪些场景会选择分布数据库，还是要回到真正这个市场选择本身这个话题上来。

Q ：关于分布式数据库产品的运维或者大规模智能化运维，有什么好建议？

其实一个产品，它的应用规模越大，其诉求、挑战会更高。因为产品没有被规模应用的时候，无论他怎么去做，哪怕是人肉支撑，也能够把运维很好的支撑起来。但是一旦放量之后，这个运维就是很大的挑战，特别是数据库产品，它和普通的应用有很大的差异，在运行时会影响到各种因素的影响。比如软硬件故障，这也是为什么有 DBA 这样一个专业方向的群体来去专门做这个数据库的运维。传统数据库经过几十年的发展，已经形成比较成熟的 DBA 群体，除此外，分布数据库相对于集中数据库来讲，其实还是有不同的挑战的。

首先是技术架构，它本身就带来了更高的复杂度，相对于集中式数据库来讲，分布式对于高可用故障恢复以及执行计划的各种调优，它会有更高的对于能力上的诉求。对于一个新的产品和架构，要去学习理解，再形成普遍的认知，还有使用它的熟练度，其实需要很长的过程。这个可能不是说针对某一个数据库，而是因为分布式的架构和技术特点决定了会有这样的一个过程，而且其实我们在运维的问题上面，也有几个层面在实践和探索。

第一个层面是产品能力。除了数据库的内核之外，要真正把一个产品用起来需要考虑产品化配套相关的各种工具，整个集群管理运维监控、全链路的诊断，还有自动的优化器、功能调优、自助运维，所以用工具去解决这个问题非常关键。当然这里面肯定是需要 DBA 和人去培养这样的能力，但是如果你有比较好的工具或者比较完整的工具能力做支撑，有比较好的技术去提供这种支撑和查询，其实是很大的一个帮助。所以从产品能力上来讲，我们要去构建这样的一些能力支撑和底座。

第二个层面是整个用户层面的认知，包括运维人员体系的培养。OceanBase 现在正在通过开源去培养一些用户，我们也建议大家都用起来，知道数据库有什么特征，会遇到什么问题。更多人去用，在运维上更多人才会去理解它、用它。同时参加一些培训认证，像OceanBase 现在的 OBCA/OBCP/OBCE，针对不同的人群，不同的特点去打造全认证体系，让更多人能够快速学习、使用和了解的这个分布式数据库。这不单单针对 OceanBase，而是想要对于整个分布式数据库的运维、调优去培养这样一些人才基础。

第三个层面是我们在市场化和交付的过程中，慢慢体会和理解到整个数据库的运维问题。这点只靠我们自己远远不够，像 Oracle 这么成熟的一个产品和公司，它的运维也是靠大量的第三方专业服务公司以及 DBA 群体一起去搞定的。对于分布式数据库来讲，OceanBase 属于一家创业公司，现在规模不大，后续一旦规模应用到更多行业和用户场景，仅靠原厂去支持服务很难。所以对于数据库运维，我认为要把第三方的各种专业服务公司、生态、包括 DBA 的能力都综合利用起来。

除此外大家也会有一些探索。像资质能力、包括 AI 也是未来我们的一个探索框架。我认为在目前这个阶段，刚刚提到的三个层面是我们重点要去发力和投入关注的。

Q ：国内很多新兴的数据库产品研发参考 Google Spanner的论文，您觉得国内与国外在分布式数据库技术上，还有哪些差距？

之前在传统的数据库的架构下边面临着业务的一些挑战，如数据规模的快速爆发、分析类的诉求，在这样的场景下面，给大家带来了很多不同的在技术上创新性的思考,这种思维上的突破和启蒙有很大的意义。以Google 为例，它起源于自身的业务，因为 Google 本身就是全球化、跨地域，又有非常大的业务规模，它基于自己的业务场景诉求，在解决自身问题的过程中积累了一些技术方案和能力，然后进行了一些输出。

再比如说 Spanner 这样的架构，就是解决这类问题的一个方向，但效果很难说，起码现在看来可能还远远没有到很完善的阶段，包括Google 自身数据库的市场化或者商业化能力，也很难说是比较成功的，就像他提到的一些核心技术，True-Time API 和全球化的这种能力，是不是适用于所有场景，其实也不一定。

不同企业的诉求和场景有很大差异，不管是国内还是全球范围内对分布式数据库的推动，背后主要还是几个云大厂。因为云大厂的特征和Google 自身的业务特征有一定的共同性，即足够大的规模和数据的大集中，这样的场景会对于分布式数据库有一些核心诉求，但是它会带着浓厚的厂商色彩，如何满足多元化场景，有很重要的现实意义。

所以是不是要基于云厂商或者聚焦互联网大厂的数据集中化诉求，或者说 all in cloud 来做分布式数据库？其实不然，比如说在国内，它会有更好的土壤来促进和发展多元化的场景支持，而不是大家都聚集到一条路上去做这种全球化，或者是公有云原生的解决方案。

综合来说，我们相对于国外的技术差距没有那么大，因为不同的场景都需要去解决，我们有我们的优势，在早期他可能也有他的一些优势。只能说现在这个阶段，从技术先进性和技术实力、能力上来讲，我们有足够的自信来面对任何的场景，包括现在国内的大规模挑战和全球化诉求的挑战，我们都有足够强的自信心来解决这些问题。

Q ：在当前云原生大趋势下，分布式数据库技术的发展还有哪些突破点？

当下的数据库是百花齐放的状态，我们的坚持就是我们要做一款对于用户应用透明的分布式关系数据库。这句话听起来很简单，但实际上里面有几个关键要素。

第一，我们要去做应用透明。不需要在应用层去感知解决问题，也不是中间件的方案，而是要在数据库层解决问题。换句话来说，就是把复杂留给数据库，把简单留给用户。

第二，严格的 ACID 保证。数据库一定要保证数据的正确性。换句话来说，就是 OceanBase 一直坚持立足于 HTAP，不断地支持和扩展我们的 AP 分析能力，而不是说我们在 AP 的基础上来去支持严格的 OLTP，这个是我们在分布式这个方向上坚持的核心要素之一。

除了支持这两个技术挑战之外，我更想讲的是另一个话题，分布式数据库在走向市场化应用的过程中，最大的问题和挑战还是摸清客户到底遇到了什么问题，需要解决哪些问题，除了分布式数据库在技术上的竞争力和优势之外，产商真正要从天上回到人间，让大家都用起来，这里也有几个关键点。

第一，对于大规模的分布式事务，能够支持和保证事务的一致性。在正常的状态下，我相信很多人能解决，但是在出现故障或者各种软硬件故障异常的情况下，去做好恢复，同时恢复过程能够不影响业务，这个对于生产系统来说是一个巨大的挑战。从用户视角来讲，非常关注的就是分布式技术体系能不能解决这个问题。

第二，是否能够平滑迁移。当大量的应用从原来的系统迁移到分布式的时候，是否能够有一个通用的方案。另外的现实情况是我们要解决大量不同的行业、场景，海量应用的迁移，也是很多大型用户关注的一个要素。

第三，如果我们把这个范围扩展或者泛化来看，其实不同的用户场景或者说同一个用户它的应用场景非常复杂。它可能会有不同的基础设施（私有云、公有云、混合云），而且大量的系统不是一次全部切换，这个风险的代价太高了，所以肯定是渐进式的。有这样的一个场景的话，就会带来大量的这种不同的基础设施的支撑、异构部署的诉求，这个也需要数据库层提供一致的能力体验和能力支撑来保障。

最后，我想说的是 HTAP，就是 TP 和 AP 的能力是不是能够融合起来，一开始，其实二者没有分离这个概念，后来随着数据量的增大和分析诉求的增强。原有的数据库能力无法满足，所以才分离出来。现在的架构也带来很多问题，包括用户需要在这个应用上，去构建不同的业务系统，来做日常生产的交易，以及这种角色的分析。

在应用复杂度上和客户的投入成本上来说，还是回归到 IT 的本质，就是对于算力和存储的资源消耗，它都是不经济的。所以有一个方案能够同时解决 TP 和 AP 的融合，且有很好的负载资源的隔离，让他们互相不受影响，这是有巨大的现实和经济意义的，这也是 OceanBase 下一步要去重点投入和发力的关键突破点。

📣极数云舟创始人 周彦伟

Q：如何快速理解什么才是真正的分布式数据库？

这个问题如果比较简洁的回答，可以分两段。分别是什么是分布式和什么是数据库。

首先数据库是解决数据存储与计算的问题。其次分布式就是用多种资源去解决大规模的数据的存储及计算，把它从原来单台服务器的资源和计算分摊到多台服务器，这是分布式数据库的字面意思，但是这样的产品是否就是真正的分布式呢？我觉得也不尽然，它只能算作一个学术理论类产品，并没有从实际需求场景来考虑。

分布式数据库除了要解决计算能力和存储能力的资源分摊的问题之外，还要看实际需求中对于数据库的能力与诉求等等，另外分布式可以认为是对于各种不同资源的分摊。比如说，非对称分布式。大多数时候，大家关注的是在对等条件下，然后用分布式集群进行数据的存储和计算的分摊，但是在一些产品需求当中，例如对于边端边缘计算是需要在远端直接计算结果，再把这些结果和中心端关联起来，对于这么一个场景，显然资源的配比是不对等的，但还是需要把分布式数据库的技术从远端到终端的数据结合起来，然后进行某种运算并得出结论，这算不算一种分布式数据库呢？如果设计好的话，当然算是一种分布式，这是第一个例子。第二个例子就是不对等计算的分布式，就像经常看到的 HTAP 这种多样的计算类型，数据会存放在不同的存储，不同的环境中采用不同的结构，有不同的计算需求或者算法，那么要做一个分布式系统的话，要解决计算能力和分摊的问题，不同运算及算法的分摊，如果把系统设计的很好的话，这同样应该也纳入到分布式数据库的范畴。

Q：分布式数据库近些年还挺火的，但是海外的一些主流数据库厂商（Oracle，IBM）并没有大肆推广，也有一些言论指出，由于亚洲人口多，数量大，所以分布式数据库对国内而言更适合，这点您怎么看？

过往像 IBM，Oracle，SQL Server 主推的核心产品还是单机版，分布式数据库并没有作为他们的主流来推广或研发。另外一个角度来讲，关于数据量的大小，我认为主要不是来自于人，而是来自于机器和设备。

分布式数据库和数据量之间没有本质的联系，那么为什么主流厂商不去做这件事（分布式），这点我也有过一些思考。聚焦做分布式数据库大致来说可以分成两类，一类偏学术类型的理想主义团队，从理论的角度去提出，然后去做分布式数据库，希望对数据库未来会产生一个什么样的结果或更好的产品。另一类并不太懂数据库或者叫初生牛犊不怕虎，先规划远景蓝图，并知道结果，同时烧的也是别人的钱。

为什么这么说？就是数据库首先解决的是数据绝对正确的问题，其次才要考虑各种性能和能力的支撑，但是分布式就意味着要在各种跨网络的资源上，保证各种计算或数据的一致性，这些才是数据库的基本要保证的能力，那么主流的数据库厂商，基于商业和社会责任的需要，首先要充分保证数据存储的正确性，同时也要考虑到性能，投入产出比，再其次才是考虑是否做分布式，换句话说，如果用单机部署或集群能够在一定程度上解决数据的计算、存储能力分摊等问题，或者在数据库内核不包含分布式计算架构就能解决问题的话，也能为数据的安全性和一致性保证获取更好的收益，那这样也许是主流数据库不去做分布式数据库的一个重要原因。

随着硬件和网络以及分布式数据库存储能力的不断发展，资源能力的分摊对于分布式也分成几种。从计算能力来看，可以基于 CPU/GPU 分摊，但是由于摩尔定理的限制,计算能力在单机上的提升会慢慢地逐步降低，但跨网络的物理硬件的分布式会逐步加强。网络已经出现了这种类似于 RDMA 之类的高速访问。我不知道未来会不会出现跨 CPU/GPU之间硬件的融合，但目前从存储上已经看到了一些。原来我们用 RAID 把多个存储盘连起来形成一块，这样数据库直接部署在做了 RAID 之后的单机上，这是一种存储扩展形式；还可以基于智能网卡把存储从硬件角度直接扩大成一个跨网络和跨机器的一个统一硬存储的范畴。

也就是说分布式存储可能从硬件角度去解决了，那么你的数据库还要不要去解决这个问题就需要慎重考虑一下了，因为数据库的本质的还是要保证数据的存储与计算，特别是数据存储与计算的正确性。看起来上面说的 Oracle，IBM 等对分布式在软件层面实现有惰性，可能有这么一个考虑。

如果 CPU 和内存未来也能做成基于智能网络、智能交换机、跨主机的统一 CPU 和内存，将其都做成一个基于硬件的分布式。如果有这些资源的话，那么只要关注存储计算问题本身，就不一定需要考虑分布式。虽然现在还不成熟，但我已经看到有些科研在做了，未来可能还有这种产品出现。所以分布式我觉得还会去做，但我说的一样，那种不对等、不同质化计算的需求，也许对于数据库是一个新的挑战。这就是我们实现的 Data Fabric 要解决的事情了，是跨环境维度，跨数据维度的广义分布式系统。

这个争论可能会再延续一段时间，软硬件之间是相互迭代促进发展的，等硬件分布式做的足够好了，再用软件分布式说话，只不过范畴不同罢了。相信在不久的将来，会是广义分布式一统天下的局面。

Q：关于分布式数据库有几种形态（中间件、NewSQL、分布式架构+企业级内核、计算+存储分离架构）？关于这几种形态能否分析下他们优劣势？

这是一个很基础的话题，从我的角度来讲，我们可以从分布式的几个场景来分析优缺点。我个人认为分布式有三个层次，即用户的交互、数据的计算、数据的存储。我们可以从分布式发生的三个层次去看：

第一，路由层。当 SQL 写进来，需要写数据库，如果做中间件的话，那是中间件的路由层要解决的事情，很早之前，我们做的分库分表、中间件，甚至数据中台，可能都有这么一个中间件的组件，用来解决这个 SQL 的分发、分摊、数据的缓存计算以及重组，这是分布式发生在路由层的情况。

第二，计算层。如果说路由层是在隔靴搔痒，是最早期、最低端的形式，那么在计算层的分布式就真正涉及到了数据库的内核，它需要的技术能力、以及软件的成熟的时间也会更长，这是一个体系。

第三，存储层。刚才提到的共享存储，或者是最早期的云原生思想，比如那套基于AWS的理论体系，我认为它的难度介于路由层和计算层之间，但也是考量了各种安全性、性能平衡的结果。我们来分析一下这三种形态的特点。

路由层在以前，比方说十几年前的人人网，淘宝等，以路由层为主要形式。最早期的开源中间件，也是由阿里开源出来的，这是一个最早的形式。到现在为止，还有一些商业化的中间件也是这样的形式，但是我认为这种形式是早期技术发展过程中的一个产物，是为了解决当时的一些问题，但是又找不到更好的资源分摊的方法，然后做了一种以后端分库分表，用中间件来协调，进而解决了这个资源分摊的问题。一旦我们的技术突破了当时遇到的技术壁垒的时候，这个方案很快就会被淘汰掉。因为中间件要解决各种数据的融合计算，要缓存各种各样的数据，要兼容各种各样的语法、以及数据的一致性，这些都是它的问题，并且有些问题根本解决不了，所以我们会陆续看到，基于这种架构的分布式到现在越来越少，或者慢慢的会被技术的大浪一点点给盖过去。基于中间件的分布式是完全没有未来的。

另外两个主流应该是分布式领域的主要发展方向——分别是计算层的分布式与存储层的分布式。在计算层执行分布式计算，底层可能是数据的分片存储，这种形式可以说是一个分布式比较理想的形态，它很理想化的解决了各种资源分摊的问题。我觉得在这个层面上，OceanBase算是这种分布式的一个形态，这是它的优点，但它也有一些缺点，缺点在哪儿呢？其实我们可以考察一下数据库对于数据的计算，因为刚才说解决的核心诉求是计算的正确性，数据的安全性以及计算的效率，其次是怎么考虑资源分摊。

如果在把资源更好的分摊的情况下，为了保证数据的安全和效率，那么我会牺牲一些东西。如果是做彻底的分布式事务，就意味着在某些极端性能上，应该不跟跟单机相比，就是不会高于单机。这是一个简单的计算模型，比如MySQL会比分布式快，这是因为它简单，所以它高效，可以做得更好。所以从这个角度而言，基于计算机硬件与计算形态的分布，它可以达到一个比较理想状态，但是它实现的复杂度会提升，大大提升了数据库本身程序的复杂度以及数据库成熟的难度，另外就是它对于一些数据的安全、计算性能可能都会有影响。

和上一个话题连起来，为什么 Oracle 不会发展这样的产品？为什么 IBM 的 DB2 在这个产品都是以单一库为主的，我认为真正做数据库的人考虑的是绝对的数据安全和性能提升，以及在性价比之间择优。

再说到存储层分布式形态，这是一个现在看起来很理想，虽然不算是终极形态，但是是一个非常聪明的做法。也就是说如果我们要把数据库能力分摊的话，那就要分成计算与存储两个方向，进而才有计算与存储分离这样的概念，因为他们确实可以拆开的。而且你要做真正的大规模数据支撑的话，就得首先实现计算存储分离，只有实现计算存储分离之后，才可以分别在存储层和计算层分别考虑应该怎么做。只有具备这样的条件之后，我们才可以想，在存储层做分布式存储和原来单机一样，我就不用考虑数据的安全性、即时性的问题了。

当然也不排除说我们要做更理想化的，更极端的产品。但是做技术研发要跟实际的需求结合起来，实际需求用得上我们就干，反之产品很好，实际需求不大，它可能不排除作为一种科研产品持续存在，等待未来应用，但是从商业化角度来看，可能不只是追求技术完美，而是追求技术能不能覆盖需求，保证高效、安全。我觉得这可能也是很多老牌数据库厂商设计产品的思路。

另外，结合对未来硬件发展趋势的预测，如果在硬件层面把分摊资源的问题解决了，那完全有理由不去自找麻烦，而是基于硬件的实现，把数据库本职工作干好。

对于分布式的几种形态，我觉得很多应该超不出这三个层面。而且每个层面这样来区分的话，每个层面的特点应该都比较鲜明、优缺点一目了然。所以说我们到底选型去部署、应用哪个产品，要根据实际的需求以及社会发展阶段来去定义。

Q：分布式数据库的存算分离对于业务有哪些价值？

我对这个看法可能比较极端，所谓要做分布式数据库，必须要做存算分离。存算分离是一种手段，它的目标是为了解决这个分布式的问题，只有存和算分开了才能在“存”的角度去考察分布式扩展、扩容，以及分布式的一些高用、副本之类的问题，以及在“算”的角度去考虑如何实现高弹性，提升资源使用率，按需所取，并行计算等问题。

对于存储的是什么内容我不用考虑，因为在做完存算分离之后，这部分对于用户来讲是透明的。另外还有对于整个系统的透明化、高可用的建设。对于一个传统的数据库架构，每一个节点都是带着存储和计算在一起的。你想要做个业务切换是很难的。在做了存储与计算分离之后，几乎可以做到一个 server-less 架构了，这样对于切换的逻辑上是非常容易的，业务层完全无需考虑某个节点的切换情况。这一点对于业务的开发、运维、扩展都是非常有价值的，所以我的观点比较极端——计算层和存储层分离，分别做不同的分布式，才算一个真正的对于业务有价值的分布式。

Q：分布式数据库的学习与实践，平时应注意哪些方面？

我觉得有两点，第一，知其然，也要知其所以然；另外一点，实践出真知。

知其然也要知其所以然，解释一下就是如果是我们在用一套复杂系统的时候，系统做得越优化、越简单，里面隐藏的东西反而越多。因为所有个性化的东西都是做了包装的，如果你一直停留在表面上去使用它的话，那你可能在它出问题的时候无法解决。

我举个例子，我在去哪儿网的时候，比较疯狂的推荐一个 MySQL 的组件叫 Galera。因为在一段时间之内，它用小而美的方式解决了多节点同步写的问题，我觉得挺有价值，但这样的产品，我也看到了很多人抱怨这个架构不好用、这个开源组件不好用、有什么什么的问题。但我在线上弄了几百套都没有问题，而且后来我还把它写成书，放在了《MySQL 运维内参》里。

为什么会这样呢？除了产品能力本身的问题之外，也要看使用者对它的理解，以及对它的掌握能力。如果你只是基于表面上去做一些事情，很难知其所以然地用好这个产品。所以我们在使用分布式数据库这种极复杂、且经过封装的情况下，还是要去了解本质。

第二，实践出真知，强调的是要给自己犯错的机会。也就是说只是纸上谈兵没有任何用，你要实际去做一两年，如果有机会的话，也可以在线上环境去做。但是这个线上环境分几种，需要选择不会影响线上业务的。使用起来去了解数据库产品的差异，它是动态的体系、是不断运转的过程，运转之后，它或多或少的会出各种各样的问题，只有带着问题去爬，才能让你了解的更深刻，才能让你去读源代码的时候，该往哪读，让你对于产品或者系统本身有更深入的了解。

Q&A

Q：分布式数据库对数据库的可用性、完整性有没有特别好的保障，能不能像 Oracle 那样，被大量用于金融、运营商行业？

王南

这个问题其实就是我们的理念和定位之一，我们的目标就是要去解决这个问题。简单来说，OceanBase 就是要进入到这个企业核心场景里面，然后把这种应用的带来的各种诉求，包括功能、性能安全、数据的一致性、完整性、正确性的保障都在数据库这一层去构建起来。

有很多用中间件的方案对于应用有依赖、约束，比如说跨节点的两阶段这种事物，在出现故障的时候，对于事物的一致性，包括回滚的残留状态没有完整保障，需要在应用层做约束或处理，才能够保证数据正确性，OceanBase 绝对不会将这种问题抛给用户，而是在数据库层面去解决。金融和运营商核心场景的关键技术就是对于数据的可靠性、安全性、正确性这里的诉求，跟这种互联网，这种场景，它的容纳容忍度和成熟度是不一样的。OceanBase 从数据库的安装部署、开发、运维、监控、故障的处理。

Q：Arkcontrol 是否有计划接入支持 OceanBase？

周彦伟

Arkcontrol 是我们产品体系的一个组件，它存在的意义是两个方向。

一是为了向用户提供我们整个产品体系的一个管理层，他负责对于云舟数据经纬平台（DTArk）的运维，监控，数据备份等的管理。

二是为了满足用户的需求，建立在用户需求之上，然后去解决用户层面上多种数据库的融合管理等问题。我的用户可能除了自己的产品之外，在数据库层面上还有MySQL、MongoDB、Oracle、Redis，我可以给他提供一个统一的平台去做统一管理，它属于一个便利化的工具，其核心意义是管理。

至于会不会去接受 OceanBase ，我想这需要回归到市场，看用户部署了什么产品再去做决定，假设很多用户的 IDC 里面已经部署了很多 OceanBase产品的话，我们也希望为了方便用户，去支持 OceanBase 的一些体系。我一直秉承一种观点，就是要深入内部去做事情，而不是浮于表面与外围。当然在支持的过程中希望 OceanBase 能给我们开放更多的接口，让管理做得很好。

Q：分布式数据库的性能要求都很高，有没有计划说普通的 PC 或者是降低性能能够跑起来的方案？

王南

说实话，我们已经关注到，而且已经努力了一段时间。首先在公有云上，有大量这种中小客户会有这样的刚需，特别是对于小型客户，他其实不太需要性能特别强劲的服务器去解决当前的问题，或者说有很多这种开发者、个人用户可能是想拿一个小的场景，甚至在自己的基础上去测试或者使用一下。

这个问题我们现在有几个方向在努力：首先是对于资源的消耗，接下来OceanBase会推出更低资源消耗的产品。目前应该是对于 8C 64G 这样的内存诉求，在今年我们会把这个对于资源的开销去降低到 4C，未来会推出 2C 甚至 1C。同时，为了更多的客户可以更便捷的使用和体验，对于单个节点的规格场景，我们现在也在做一些探索。

除此以外，公有云上可以考虑用多租去解决用户的成本问题，因为大量的小的用户如果都是独占这种方式，会带来成本上的开销。如果是对于非核心业务，客户可以在资源上降低一些诉求，去得到经济投入上的一些回报，这种多租比较好。我们现在在多租的内核能力已经具备，再去做存储计算和内存的资源隔离能力，支付能力未来我们也会通过这个云这种形态去发布，让用户来快速体验，对于这个问题我们再总结一下，就是对于这种小规格诉求，降低规格这种诉求已经在做，而且在今年我们就会看到很大的进步，未来 OceanBase 也会持续做这件事。

Q：HTAP 中间状态怎么理解？

周彦伟

理解可能有很多种，作为产品设计人员，要从一个更高远的目标去考量。什么叫高远的目标呢？HTAP——TP 与 AP 融合的形态，这也是数据库的两种基本能力的结合。如果你去设计一款这样的产品的话，那么你这个状态是不是终极状态呢？显然不是的，因为数据的计算除了 TP、AP 以外，还有边缘的计算、检索的计算，图的计算等，由于这种计算需求的存在，才使我们的市面上有着形形色色的数据库。HTAP 可能是把原来 TP 型的和后来以大数据为主的 AP 打通，是 1+1 的模式，那能不能合三为一、合四为一呢？产品的设计决定了产品的实现，如果你只考虑 HTAP 的二维中间状态，实现出来的产品以后想再扩展的话，就非常困难。

所以在产品设计思路上，如果能够解决多维计算的产品形态，那可能反过来再看 HTAP，它就是个中间状态，是我们从一维到二维迈出的很重要的一步。但这一步不是一个终点，它只是个起点，未来我们还有很多事情要做。我们站在这个角度去看，如果我们设计产品的时候，设计一种框架能够去支撑二维、三维乃至多维那最好，所以做技术的人反过来再做产品经理，可以从产品的需求和产品实现的角度同步考虑。如果你的眼光只盯着这个维度去做的话，那么未来我们再去看更高的一个产品需求的时候，可能你现在写的很多代码就要推翻重来。我们又不愿意这么做，只好考虑得更全面，做更大的框架，能够去把这个二维实现，同时也能够去兼容未来多维的需求，这样才是最理想的场景。

我们的 DTArk 就是基于这样的思考，目前已经实现了 TP/AP/FP 的融合计算，估计很快还会支持图计算，这种多维可扩展的架构跟直接去思考实现一个 HTAP 是完全不同的，换句话说，现在的 HTAP 产品要进而实现更多维度的融合的话，可能都要推翻重来，代码重新写过。

Q：有全球同服的分布式数据库推荐吗？覆盖亚、美、欧洲的那种？

王南

我相信提问的同学可能不是在说有没有一个数据库能够适配这些区域，“全球同服”可能在问公共云上是不是有这样的一个数据库能够在全球的不同区域分别提供一致性能力去支撑这种全球化应用和数据上的部署诉求，现在确实还是比较有挑战的。

这里面还有一个隐含的诉求：同一个云在全球的区域都能够提供这样的能力？还是有很多客户不想被某家云绑定的诉求。简单去看，有没有分布式数据库或者云服务能够在全球提供服务，这个其实还是比较多，可能能力上会有一些差异，包括几个大的云厂商，其实在全球各个区域的云上，都有包括 RDS，共享存储服务、AP 的产品，如果是跨云诉求不被一家云绑定，特别是大型客户。

如果只能在一个云上去做应用的基础设施，其实存在很多风险。包括技术、业务安全上、成本上的风险。对于跨云这块的诉求目前有很多人提出，但不是所有人都能够解决，因为云厂商能够解决的还是基于基础设施如何提供全球跨区域的服务。但是对于跨云，可能还是要靠独立的数据库产品、厂商去解决这个问题。OceanBase 现在正在考虑、解决，大家会很快能够看到我们有一些产品和服务。

周彦伟

如果从纯技术的角度来回答，肯定有，比如依托网络的分布式，在不考虑性能容忍度、时间成本的话，分布式全球快速部署没有问题。换句话说，全球部署的瓶颈，我认为在于网络和权限，只要跨越这两点都可以。

在实际操作上，真正既要考虑跨中心、跨云、跨全球化，又要考虑性能的结合，现在看起来其实有难度，因为网络一定有时效，光速很难突破。所以退而求其次，在分布式上可以只做共享存储，或者说既做分布式，也做共享存储，主要看业务对你的计时或者是性能容忍的程度。我们在实现 DTArk 这样的 Data Fabric 产品的时候，也提出了一种创新技术——数据飞梭。很简单，你要做这件事，可能不需要全量的数据做大规模的同步，可能只需要某一批数据，然后传来传去，无需做成全世界的一致同步，浪费很多时间去等网络，而是可以在某些数据或业务、计算场景中做不同维度的数据跨域或者跨区间。此刻要考虑得就不是即时同步了，而是最终的一致性；不是即时计算，而是根据时间配置的时间窗口的计算。我觉得关键点还是在于网络的问题，就是网络延时是影响所有需求的本质问题。