随同着云计算、大数据技术的倒退，传统信息技术及利用受到了微小冲击，数据库作为根底软件也迎来了新的挑战和时机。同样数据应用场景出现多元化趋势，数据规模也随之爆发式增长。海量异构数据的爆发式增长，对数据库的存储和计算能力提出了更高的要求。
将来，传统的基于单物理服务器节点的数据库将在更多的场景下被分布式数据库取代，分布式数据库利用前景将越来越广。
《对话 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 产品的时候，也提出了一种翻新技术——数据飞梭。很简略，你要做这件事，可能不须要全量的数据做大规模的同步，可能只须要某一批数据，而后传来传去，无需做成全世界的统一同步，节约很多工夫去等网络，而是能够在某些数据或业务、计算场景中做不同维度的数据跨域或者跨区间。此刻要思考得就不是即时同步了，而是最终的一致性；不是即时计算，而是依据工夫配置的工夫窗口的计算。我感觉关键点还是在于网络的问题，就是网络延时是影响所有需要的实质问题。