【编者按】DTCC 2019已经结束，云栖社区沉淀了很多阿里巴巴所分享的优质演讲整理稿件。这篇转载自IT168&ITPUB执行总编老鱼的公众号，分享给大家。
李飞飞，现任阿里巴巴集团副总裁、高级研究员，阿里云智能数据库事业部总负责人。加入阿里巴巴之前为美国犹他大学计算机系终身教授。研究成果多次获得了IEEE ICDE、ACM SIGMOD最佳论文奖等重要学术奖项。
2018年，李飞飞加入阿里巴巴达摩院，带领团队投入到具有自主知识产权的研究当中。目前，带领的阿里云智能数据库事业部所研发的新一代分布式数据库系统，支撑了阿里巴巴集团的复杂业务、海量数据和双11交易洪峰的挑战，已经被应用于多个城市的智能城市交通网络管理，并服务了金融、零售、物流、制造等行业企业。
2018年，阿里云数据库成功进入Gartner数据库魔力象限，这是该榜单首次出现中国公司，近日，阿里云数据库再次入选Forrester数据库评估报告，成为国内首个获得两大顶级机构认可的科技公司。
2019年5月10日，DTCC 2019(第十届中国数据库技术大会)在北京举办，李飞飞来到现场发表了精彩的主题演讲，并在大会期间接受了IT168&ITPUB执行总编老鱼的深度专访，众多独特观点精彩纷呈。
透露两条信息：
1、PolarDB从去年10月开始商业化到目前，已经成为阿里云上增长最快的数据库产品；
2、AnalyticDB已经通过TPC-DS打榜，做到了世界第一，性价比第一，数据在TPC-DS官网上已发布；
部分精彩观点摘录：
1、目前市面上所有的自研云原生数据库并不是真正意义上的分布式数据库，只能称之为分布式存储的数据库，因此，在下半场这或许会是一个突破点；
2、NoSQL和传统关系型数据库的边界会越来越模糊；
3、有很多厂商说自己的数据库是NewSQL，严格来讲，其实只是在某些维度实现了一到两个点，并没有完美解决NewSQL所有的技术挑战；
4、MongoDB协议修改得非常巧妙，其目的是为了获取云厂商的托管平台去做自己的云托管服务。
5、上半场各云厂商核心的竞争力其实是底层的托管平台，因此，云厂商绝对不可能去托管修改协议后的最新版开源数据库，让自身管控平台开源；
6、下半场两个发力重点：一个是不断地提升托管平台竞争力，二是一定要有自己自研的数据库内核，这是为什么大家都在自研数据库的原因，因为，仅仅靠托管平台的竞争力是拉不开身位差距的；
……………………………………………………
以下是专访原文，为了便于阅读，在不影响原意的前提下，略做修改。
问：请从阿里云数据库产品线重要的产品节点和突破，来谈一谈阿里云在数据库领域的竞争力？
答：众所周知，数据库市场主要分为了以下几个板块，一个是传统的OLTP，即所谓的RDBMS线上交易系统。最经典的商业的有Oracle、SQL Server，开源的有MySQL、Postgresql，OLTP是阿里云很大的一个板块。
第二个板块是OLAP在线分析，如Teradata，AWS Redshift都属于这个板块。
第三个板块是非结构化、半结构化数据处理需求带来的NoSQL数据库，如Hbase, Cassandra以及现在非常火的MongoDB、Redis都是属于这个板块。
最后一个版块是工具类生态的产品、数据传输、数据备份以及数据管理板块。四大板块下面，又有运维管控平台，也就是俗称的云数据库托管平台，这几个模块就构成了云数据库体系和架构。
以上是数据库市场较大的板块，下面来讲讲阿里云在每个模块里最核心的一些产品和技术积累。首先，是最重要的OLTP板块，可以细分成两类：
一类是托管产品，即第三方的商业数据库和开源数据库，比如像SQL Server、MySQL、Postgresql等，主要是为了给客户提供丰富的选择，使客户可以无缝地把线下数据库迁移上云。
第二类是自研云原生数据库，这里面最主要的重量级产品就是PolarDB。PolarDB是一个基于分布式共享存储的云原生数据库，利用分布式共享存储，带来的好处是存储和计算进行了分离、解耦，解耦以后可以在存储和计算分别进行弹性扩容，做到极致的弹性，对云上客户极具吸引力。因为，云上客户需求一个很关键的点就是按需按量使用，同时进行按需按量计费。
除此之外，PolarDB还有很多技术，比如高可用，利用三副本及分布式数据一致性协议，Parallel-Raft做到金融级高可用的性能，使客户不用担心RPO、RTO的问题。另一个就是在分布式存储以及上面一写多读的多计算节点再上层又做了一个智能化的代理层，可以做到智能、自动的Low balance，计算节点之间的负载均衡分配技术等。这些结合起来，使得PolarDB在云原生上的OLTP数据库处理上具有很大的优势。
比如说，PolarDB可以做到分钟级的弹性缩扩容，从2个Core弹到32个Core只需要大概五分钟，从2个节点弹到4个节点也只需要几分钟，缩扩容从几个TB支持到一百个TB都没问题，可以支持单机点百万QPS处理性能，对云上客户、对弹性、高可用、负载均衡等等都有非常好的解决的方案。在云上的应用是非常有竞争力的，相对于传统On- Premise数据库的架构，PolarDB有非常大的竞争力。
我可以非常自信地说，在阿里云上的PolarDB，无论是从性能、技术上，都已经达到甚至在某些地方超越了AWS Aurora。阿里云也在国际顶级的技术分享会议如SIGMOD、VLDB发表了论文介绍阿里的技术。
从商业上来讲，从去年10月开始商业化到目前，PolarDB已经是阿里云上增长最快的数据库产品，实际使用PolarDB的客户从新零售到金融，再到传统的制造业，各个行业都有，非常多的企业开始将数据库应用迁移到PolarDB上面，这是OLTP板块的情况。
在OLAP板块，我们一样也会分成托管产品和自研产品。托管比如说像传统的BI工具Tableau等，自研最主要的产品是AnalyticDB分析型分布式数据库，其主要特点是行列混存，能够做到多表复杂的中文查询，在秒级甚至毫秒级进行响应。
技术细节不展开讲，讲两个具体的例子，一个是最近做的TPC-DS打榜，TPC-DS大家知道是业界公认的对分析型数据库非常重要的一个Benchmark，我们有一个好消息，AnalyticDB已经通过TPC-DS层层考验，做到了世界第一，性价比第一，这个数据在TPC-DS官网上已经发布。另外，介绍整个AnalyticDB系统的论文，也会在今年的VLDB上宣讲，这两方面都可以从技术上来证明它的先进性。
从业务上来讲，AnalyticDB支持了从税务、城市大脑到公有云，从金融到地产等一系列各行业对海量数据高并发秒级在线分析的诉求，与PolarDB形成了一个天然的互补，从OLTP到OLAP形成了完整的数据链路。
最后,阿里云在NoSQL和工具类方面也有很强的技术布局，主要是通过集团的应用多年锻打出来的一些核心产品。比如，在工具方面我们有DTS数据传输，在不同的库之间，云上云下以及云上不同实例之间进行实时的数据增量一致性备份传输等等，这样可以使得客户快速的进行数据库的迁移，还有数据备份DBS服务。这一系列的产品都是从客户的角度出发，客户需要什么？客户的痛点是什么？我们拿到客户的需求来反推我们技术上要做哪些东西，做到了今天这样一个状态。
问：PolarDB对标的是Aurora，AnalyticDB对标的是Redshift，那么，阿里云数据库研发是有着自己既定的研发策略，还是采取的跟随策略？
答：从客观上来讲，在云上，不仅是数据库板块，从IaaS到PaaS，AWS绝对是先行者。他们的先进经验以及他们避免走过的弯路，我们没有必要一定要走完全跟他们不同的道路，我个人认为还是要集百家之长，要有一种开放的心态。
所以，回答您刚才的问题，我觉得我们一开始是一个Follower（跟随者），这个没什么不好意思承认的。但是我们要从Follower做到超越者，做到leader。通过几年的努力，我们现在已经做到了能够走出一条不同的路，做到了leader位置。那是怎样从Follower变成Leader的？核心诉求是从客户的需求出发。
阿里云有什么优势？阿里云的优势是能接触到中国广大的客户需求。AWS主要的市场在美国，美国客户需求和中国的客户需求有相同的地方，但也有不同的地方，比如说，很多大中型国有企业，美国没有这种组织架构，其需求和美国的商业公司肯定有不同。这是一个很具体的例子，会对我们的技术演进之路提出一些新的思考、新的挑战，也就会使我们最终会走出一条不同于Aurora的技术之路。
另外，我们背靠阿里巴巴集团，身处复杂的生态环境，从电商到线下的新零售，像盒马以及线上娱乐如优酷等等，不仅对我们的技术提出了非常大的挑战，也提供了极为丰富的练兵场。这是我们能够持续走下去并不断衍生出新技术的一个核心保障。
问：到目前为止，阿里云数据库产品线服务总计有多少个？
答：我们现在从托管产品到自研产品，加起来在16个产品左右。这些产品分成四大个板块：OLTP、OLAP 加NoSQL加工具，最后还有一个用户看不到的底层托管平台。底层托管产品不是独立的产品，它就是一个隐形存在。
从数据库产品数量上讲，大家其实大同小异，基本上都是在同一数量级，没有太大的差别。核心的差别是在OLTP和OLAP 板块。
阿里云已经从Follower做到基本与AWS持平，甚至在技术上某些领域做到了领先。比如说刚才讲的OLAP ， AnalyticDB的性能已经在TPC-DS上打榜，并排到了第一。通过和AWS官方Redshift对比（在AWS上去买Redshift跑同样的Workload），在TPC-DS的很多的Query，AnalyticDB的性能都是要优于Redshift。
另外，在某些领域，我们也做到了人无我有，即AWS不一定有，阿里云有。比如，在分布式数据库板块，因为集团的“双11”场景需求，我们需要做share-nothing的架构。因此，我们在PolarDB基础上做了PolarDB-X。这样一个share-nothing的分布式架构来支持“双11”海量高并发数据的应用场景支撑。
从AWS的角度看，没有和我们对标的产品。所以，现在云数据库时代是百花齐放、百家争鸣的状态，全球各个厂商，包括阿里，AWS、 Azure和Google大家在某些领域都有各自领先的地方，但在其他领域可能另外一个厂商又有领先的地方。客观来说，阿里云的数据库在国内无论是从市场、技术还是产品方面，都绝对处于领先地位，在国际上也完全是跟AWS拉齐的水平。希望后续竞争到下半场，我们能够在某些领域真正的做到领先者地位。
问：我们知道，像MongoDB等好几家开源数据库厂商都修改了许可协议，主要针对的就是云计算厂商，您觉得，未来两者之间会是一个怎样的关系？这是否是云厂商纷纷发布自研云原生数据库背后的推力之一？
答：这是个非常好的问题，我把这个问题延伸一下，不仅是开源数据库厂商会有动力和压力去做云原生方向的转变，传统的巨头如Oracle也绝对是不遗余力的要去往云原生云数据库这个方向去发展。
云原生数据库有很多技术点，最重要的是弹性、存储计算分离、隔离、多租户还有很重要的一点，要有自己的云托管平台。像Oracle或MongoDB要在云上提供服务，就必须要依赖于云厂商的管控平台，这也是为什么去年MongoDB修改协议的原因。
其实，MongoDB的协议修改得非常巧妙。它允许对MongoDB开源版本进行托管服务，但是如果要基于以后的版本继续提供服务，那么，下面的托管平台就必须要开源。也就是说，如果AWS或者阿里云要继续托管MongoDB的最新版本，底下的管控平台就要开源，开源以后MongoDB可以拿去做自己的云托管服务。事实上MongoDB也是这么做的，研发了自己的Atlas。从MongoDB最新的财报就能看到，其Atlas的增长已经达到了40%多，市场份额从去年年初只有百分之十几，到去年年底，Atlas云托管服务已经增长到MongoD整个营收的30%多。
MongoDB的思路很简单，比起让云厂商提供托管服务并基于MongoDB开源版来占领市场份额，它更希望自己做托管服务，加上自己的内核，来把蛋糕整个切下来，把云厂商定位成只是做IaaS（Infrastructure as a Service)的一层。MongoDB是一种策略，其他的开源数据库厂商包括商业数据库Oracle、SAP， Oracle做Oracle cloud，SAP也做自己的SAP Cloud，它们背后的思路和逻辑都是如出一辙。
云厂商的应对策略也很简单，继续托管产品，但只托管以前版本的产品，即对托管平台没有要求的开源版本，绝对不可能去托管最新版让自身的管控平台开源。云数据库之战上半场各个云厂商核心的竞争力在哪里？其实就是在底下的托管平台。因为，在上半场大家主要还是靠MySQL、PG以及商业的SQL Server这些数据库，来拉动线下的on- premise数据库市场往云上迁移，这是最核心的竞争力。
用户上云有两种选择，要么用托管的MySQL和PG或者SQL Server，或者就是在虚拟机里面自建。
这两个选择对客户来讲，云厂商的价值就是在托管平台来体现的。因为在内核上跟自建完全没区别。托管平台最核心的就是SLA的保证，Service-Level Agreement、RTO、RPO能够做到比自建要好很多或者说和自建SLA一样，但是成本要比它低。
对用户而言，可能需要强大的DBA团队，才能做到与托管平台一样的SLA保证。这可以极大减少运维的投入，这是上半场的态势。
下半场如果MongoDB等厂商做了自己的云托管服务，就会倒逼原来上了云托管服务的客户，回到虚拟机里面自建，把云厂商彻底地定位成IaaS。因为,现在对客户而言，比如说客户用MongoDB的Atlas，那相当于拿到了AWS或者阿里云托管平台提供的SLA的能力，但又不需要给云厂商直接付费，成本上有优势，可能就会去选择自建。
那云厂商怎么应对呢？有两点：第一是不断地提升托管平台竞争力。比如说我们阿里云上有一个叫SDDP的自动驾驶云托管平台，它是利用机器学习人工智能的技术，来对云托管平台上的数据库实例进行自动运维、自动优化等等，来确保托管平台的竞争力。第二个从内核的角度来说，为什么亚马逊、阿里和Google，都在自己做自己的云原生数据库？因为大家意识到，仅仅靠托管平台的竞争力是拉不开升位差距的，所以一定要有自己的自主可控的内核，而且这个内核能够和传统的on- premise DB有性能上的差异。针对云原生的一些特点，能够吸引客户从MySQL、PG、Aurora和MongoDB等迁移到自主开发的云原生数据库上来。
AWS是最典型的，率先推出了Aurora。在NoSQL领域又推出了DynamoDB，在分析领域推出了Redshift。MongoDB修改协议以后，它又推出了自己的DocumentDB。这一系列动作背后的逻辑，和前面讲的是一样的。我个人认为，这场比赛已经进入了下半场。总结来讲，作为云厂商，我们需要在两方面发力，一个是管控平台，通过智能化的手段，提高它的运维能力和效率，另外一个要提升它的安全可靠、可验证。AWS去年推出了QLDB、Quantum Ledger Database，利用区块链里面的Merkle tree技术，对数据库的运维日志进行验证。这样客户上云以后可以来验证运维日志，来确保做到了SLA的保障，这些是从管控平台要做的一些差异化。另外是从内核的角度，不断地去投入内核的研发，以能够和传统的数据库或者新生的像MongoDB数据库内核，进行差异化的竞争。以上是我认为的云数据库战场下半场的一些比较精彩的看点。
问：您提到了云原生数据库，我最近也总是听到几个词，云原生分布式数据库，分布式中间件等。如何去鉴别真正的云原生和伪云原生？
答：这个问题很好，传统的数据库架构是什么？是一种share-everything的架构，比如说一个本地磁盘上面可能有比较大的内存，可以插多个内存条，有比较大的内存池。再上面是计算，有共享的计算状态，有多个 Core。但是很关键的一点是transaction，或者有很多个 query进来，这些transaction和query在整个数据库从存储到内存，再到 Core都是共享状态的，这个就叫share-everything架构，也是传统的数据库架构，像Oracle、SQL Sever都是这种架构。
这种架构有它的优势，是共享状态所以Coordination比较容易做。但缺点是Scalebility（扩展性）会受很大的限制，所以就衍生出了分布式这个概念，分布式最核心的挑战就是要提供Scale Out以及Scale Up的能力。
Scale Out怎么做呢？比较经典的像Google Spanner的做法，是做一个share-nothing，然后做分库分表，做partition，做sharding。在shard之间如果有跨shard的查询和事务，就需要做分布式的查询和分布式的事务处理。这个就是分库分表、Spanner的架构，也是PolarDB-X的架构。这是一种，在share-nothing上面有两个分支，一个是原生的分布式架构。也就是说，实际上在底下是做了sharding和partition的，但客户不需要去感知。对客户来讲，业务逻辑不需要改，如果有分布式的事务处理，分布式查询就会自动搞定。客户不需要去担心怎么去分库分表，去拆分业务逻辑，这是一种。
还有一种就是您刚才问题里面提到的，利用中间件的形式做一个分库分表的解决方案，这个对业务逻辑是有侵害的。这需要数据库的服务商，或者是客户自己要对业务逻辑有很清晰的认识。比如说库存、订单，这两个库是分开的，平时也不会有交集。所以，在业务逻辑上，把它拆分成两个库，这两个库存在不同的节点，这就是一种中间件的解决方式，业界有很多这样的解决方案。
这种方案的好处是比较简单，劣势就是它没有像原生分布式数据库那样，对客户的业务逻辑有侵入式的改造。另外就是，它对事务分布式查询的支持，无法做到像原生的分布式数据库那么好。以上是关于share-noting分布式数据库。
现在，大家讲的所谓叫云原生分布式数据库。我认为这是一个伪命题、伪概念。实际上，现在所有的厂商在云数据库上还没有一个真正的分布式的架构，大部分都是利用分布式存储做共享存储，然后在上面做一写多读。比如PolarDB， Aurora都是这样的架构。它实际上是分布式的共享存储，上面做一写多读存储计算分离，这个是我认为现在所谓的云原生数据库或云原生分布式数据库最典型的一个架构，分布式利用RDMA快速网络做一个分布式共享存储。它看起来像一块盘，实际上它是一个分布式的磁盘，但对上层的kernel来讲，它看起来像一块本地盘。它带来的好处就是物理数据只有一份，它避免了像MySQL、PG这种传统的主备，需要在主库和备库之间做这种物理数据的备份的挑战。主库、备库写的节点和读的节点是一份物理数据，这样就带来很多很多好处。但严格来讲，它是一个分布式存储的数据库，不能把它叫一个分布式数据库。这和我们经典定义的分布式数据库还是有一些区别的，但是现在大家把这个叫云原生数据库或云原生分布式数据库。
在下半场再往前发展会出现一个什么现象？我个人认为，下半场可能会比较有突破点的地方，就是把刚才所说的真正的分布式架构通过shardin架构和云原生分布式共享存储的shared-storage架构（云原生分布式数据库从架构上来讲叫共享存储shared-storage架构）结合起来。这个结构的好处是什么？因为shared-storage用的是RDMA，RDMA是有限制的，比如跨AZ或者说更严重的情况，要跨区的时候，它不可能无限的扩，RDMA共享存储可能只能做到十几个节点、几十个节点。因为一旦跨了network swich以后，RDMA的性能损耗非常大，远程访问不可能做到和本地访问一样快，这样shared-storage架构就有限制。
最经典的Oracle RAC做到 10个节点、20个节点就没办法再往上了，但如果并发高到一定程度或者数量大到一定程度，只能再往上扩，Scale Out要一直往下该怎么办？这时候一定要做分布式partition、sharding这种架构，但是partition、sharding如果不用共享存储的话，带来什么影响呢？每个shard不能做太大，因为单节点就只能存这么多数据。也就是说可能要分很多个shard，分布式的transaction非常多，一旦有distributed commit，性能损耗是非常大的。所以这两个如果能结合起来，有一个好处就是还是可以Scale Out，因为我上面有share-nothing这一层，底下是共享存储的节点，每个shard就可以做得非常大。也就是说对同样的数据来讲，我只需要很少的shard就可以来支持。很少的shard也就意味着分布式跨shard的这种处理会大大减小，分布式的能力会大大提升。所以这两个结合起来，我觉得会是一个比较新、比较有意思的挑战。
问：接下来的一些问题，其实也一直比较困扰我。刚刚您说了分布式，其实过去还有一种分类，比如说SQL、NoSQL、NewSQL，那NewSQL和分布式数据库之间到底是一个什么关系？过去我会把它理解成SQL、NoSQL之外的就是NewSQL，分布式数据库和NewSQL之间是一个包含关系还是其他的关系？
答：这也非常好的一个问题，数据库的同仁和朋友很多时候会有一些混淆的地方。首先NoSQL虽然叫NoSQL，但它实际上含义并不是不要SQL，它是Not Only SQL的缩写，取了个巧叫NoSQL，但它实际上是指不仅仅是SQL的意思。NoSQL的最早发展是怎么来的？实际上来源于传统的关系型数据库，关系型数据库里面因为要保障强一致，也就是ACID，所以Scale Out能力是受到限制的，所以在做Atomicity、 Consistency、Avilability、Durability这些保证的Isolation的时候，和分布式fundamentally是有冲突的，当时的硬件技术、软件技术没有使得传统关系型数据库能够无限的水平拓展。
但以Google为代表的很多互联网公司，在当时确实需要数据和事务处理、查询处理能够无限的水平拓展，因为数据量太大了，每天运行的数据都要存，这是个无限增长的过程。而且这些数据还有个特点，它不一定是结构化的，它可能是半结构甚至非结构数据的，所以，就衍生出NoSQL这个概念。总结来讲，NoSQL最核心的理念就是把传统的关系型数据库里强一致的需求弱化，比如说Isolation level,传统关系型里可能要snapshot isolation，现在只要做到ReadCommitted就行了，只要没有脏读就可以。其它的应用，如果应用层需要更高的隔离机制，那就在应用层去写逻辑，用external Consistence的方法来解决，在数据库层面只需保证没有脏读，牺牲一定的数据一致性，换来几乎无限的水平拓展。这类系统最经典的就是Hbase、Google的BigTable、Cassandra等等，这就是NoSQL的来源。
总结来讲，就是为了提供无限的水平拓展Scale Out的能力，牺牲一定的一致性保障，主要是在Consistency 和Isolation上做一些牺牲，换来无限的水平拓展Scale Out的能力。
NewSQL怎么来的？在NoSQL大概发展了有十年左右，大概是在2008年、2009年那时候出来这个概念，到现在接近10年了。大家发现把一致性等推到应用逻辑层去写还是很多困难的，而且大家发现慢慢地发现对非结构化、半结构化数据也是有强一致性需求的。不是说传统的transaction事务处理只对结构化数据有需求，对非结构化、半结构化没这个需求。所以大家就发现NoSQL系统也得去保证ACID guarantee，所谓的eventual consistency，weak consistency guarantee在很多应用下不适用，所以还是要去做snapshot Isolation，在NoSQL的场景下，这是从事NOSQL的朋友发现有这个需求，从事关系型数据库的朋友发现了什么？比如说MySQL从5.7开始，PG11.0、11.2版本都加入了对Json的支持。典型的半结构化的数据结构，也就是说传统的关键性数据库仅仅支持结构化数据也不行了，它必须也要提供非结构化、半结构化数据的支持，也就是说两边都开始往中间靠。一个有强一致的guarantee，但是它只支持结构化数据，Scale Out能力有限。另外一个支持半结构化、非结构化数据，Scale Out能力很好，但没有一致性保证。两边都牺牲了一些东西，换来自己想要的，但后来越来越发现牺牲的东西客户也是需要的，不仅限于自己所保留的，所以两边都开始补齐缺失的功能。
两者都要有，就变成了“既要......又要......”的状态，这就变成了两方的结合，也就是NewSQL。所以最终我个人认为，如果NewSQL真能发展到最后变成比较常见的一个态势，传统的NoSQL和关系型数据库的边界就会越来越模糊。
也就是说,NewSQL它不等于分布式数据库，分布式数据库可以是NewSQL数据库。NewSQL里面很重要的是Scale Out能力，它首先肯定是一个分布式存储的架构。也就是说它不一定是分布式共享存储，但它肯定是有shard的，有partition。像HBase、MongDB都是shard default的最常见的一个态势。但分布式的数据不一定是分布式的数据库，这要看它是不是真正做到了分布式查询和分布式事务。因为有可能它做了shard，分布式的数据，但是查询和事务是所谓的叫perfect shardable workload。这个事务和查询只用看第一个shard就完成了，另一个查询只看第二个shard。所以虽然它有很多个shard，也有很多个查询和事务，但是具体到每一个查询和事务，都是单个shard搞定的。严格来讲，我认为它不是一个分布式数据库，只是对业务逻辑进行了比较巧的一个partition，使得它可以就完美地去并行处理。
真正的分布式数据库有两个特点：第一，数据肯定是分成了多个shard；第二，它的查询和transaction是有可能产生cross shard这种查询和cross shard transaction，这种叫分布式。传统的NoSQL只支持第一个特点或只支持第二个特点的。支持第二个特点的是牺牲了数据一致性(isolation level)，换来了它能够支持分布式事务、分布式查询的能力。
关于NewSQL，我个人认为一个真正好的NewSQL数据库，它必须是支持结构化、半结构化、非结构化数据，这第一点。
第二点是，优秀的NewSQL数据库要有非常好的水平拓展的能力和Scale Out能力，支持分布式查询、分布式事务，同时在单节点上又有非常好的弹性和Scale Out的能力。目前来看，还没有一个数据库可以做到完美的解决所有问题，还有一些其它的技术点像HTAP（混合的事务和分析处理）、读写并存怎样高效的去处理？还有多模multimode、多种数据形态在一个库里，怎样在统一界面去查询？如果能够完美地解决所有这些问题，我认为它就是一个比较优秀的NewSQL数据库。
目前来看NewSQL只是从技术概念上出现的一个东西。严格来讲，有很多厂商说自己的数据库是NewSQL，他可能只是在某些维度实现了一到两个点，但并没有完美解决我们刚才提到的NewSQL所有的技术挑战，所以我觉得，目前我们还是有比较长的路去探索的。
本文作者： 老鱼笔记
原文链接
发布于“ 老鱼笔记”，了解相关信息可以关注 老鱼笔记”。
来源：https://www.cnblogs.com/zhaowei121/p/11103441.html