应该说，现在是国产分布式数据库发展的利好时期。在讨论发展前景前，首先要先看看分布式数据库的发展方向。
大家把传统关系型数据库称作oldSQL，给人感觉要被淘汰似的。但其实数据量不是很大或者事务处理的场景夏，关系型数据库的还是占优的。
关系型数据库的主要问题在于：
性能瓶颈，
单一模型（关系模型），只适合OLTP
应对业务的灵活性不够，
弹性扩充能力不够，
两地三中心和双活等问题上不足。
随着互联网和手机的飞速发展，无论从用户规模、使用频率、还是场景多样性都使得这些问题浮出水面。其实Oracle在92年就开始尝试转向分布式，还当时引起了业界的巨大争论，最后失败。更何况过去CPU、内存、存储、带宽的高成本导致分布式数据库的性价比并不高，只能停留在学术阶段，限制了分布式的发展。
新分布式数据库首先是要避免和传统关系型数据库的竞争，这是明智的选择，能够轻装上阵。因此从几个方面入手，应对海量数据处理、分析、缓存、流式处理、开发模式等等。相对应列式，KV，Document等多种存储数据结构。
所有这些都被称为NoSQL数据库，放弃ACID和事务能力还换取性能。然而，NoSQL又收到了大量的批评反对意见，主要是说把数据库应该处理的问题交还给了开发是种发展的倒退。这些问题包括，索引、版本、SQL支持、事务支持等等。市场上超过90%的开发员都需要SQL，而且SQL也是非常有效和成熟。于是大家无论底层是什么存储结构又开始支持SQL，形成了NewSQL。
这里插一句题外话，在硅谷已经不再用SQL、NoSQL、NewSQL来划分数据库了。理由很简单，SQL是一种语言，从来没有SQL数据库的说法，自然也不应该有NoSQL数据库的说法。NewSQL数据库就更不合理，用的SQL并非什么“New“的新东西。所以专业上用关系型和非关系型数据库来划分，分布式数据库主要都是非关系型数据库。
回过头来看国内分布式数据库市场需求，中小企业不满足Mysql的性能，分库分表又很难搞，也不彻底；大型企业被Oracle等垄断支付高额成本，而且又不解决实际碰到的瓶颈问题。因此，用户都在寻找新的解决方案。小型用户、云计算的用
再加上国产自主和去IOE浪潮，更加推动了国产分布式数据库的发展利好。值得注意的是，数据库研发是个严肃的事情，没法短平快。
存储是个技术钻研的方向是不错，不错拿来创业的确不是一门好生意。我国是不可能出现像cloudera 这一类的公司的。在国内做基础软件基本上是没有商业前途。阿里方面，是做了一些基础技术开发，不过都是基于自己的业务特点而做的。就拿他们得dubbo框架来说，最晚的一次commit实在两年前，据说团队解散了。想表达什么意思呢！完全从社区孵化出来的和从大公司内部孵化出来的在国内看来还是有很大区别的。 国内的做的比较好的供存储服务的公司也不多，七牛，金山云。 所以，对于个人而言就看你怎么权衡了。
分布式数据库需要在高可用(比如paxos,raft)，高性能存储(比如LSM Tree，mvcc)，分布式一致性(比如2pc,HLC,truetime)，集群管理，多租户，分布式sql plan等方向都做出技术突破，目前来看oceanbase是分布式数据库方向的领先者，是金融级的分布式RDBMS，他们在工业上实现的一些技术，从各厂近期的技术分享来看，在工业界至少要领先2年的，甚至有一些方向，在学界也是领先的，最近读了张晓东教授小组的一篇paper，提到的技术，ob在3年前就实现了类似的方案。
基础软件创业其实我觉得是个好生意，尤其是数据库，但是前提是确实在技术上有所创新，这么一来技术壁垒就巨高，这就是护城河。如果只是去模仿 Oracle，是没有太大前途的（当然靠关系那种就另说了，反正我本人不认为这样是正确的价值观），想想人家 O 记在这个领域做了 30 年，你走人家的老路凭什么干得动人家？ 目前来说我觉得之所以国内还没有太大成功的公司涌现说到底还是因为技术不行或者路子不对或者客户的历史包袱太重，拿个 Hadoop 改改就是大数据了吗？真正的 OLTP 业务敢碰吗？所以就造成了做项目挣快钱攒方案搞数据分析的公司扎堆，真正在 OLTP 端的创新没人敢碰。另外一个重要的问题就是，国内几乎没人懂开源。最近几年重要的基础软件创新都在开源社区，比如 Docker / Kubenetes (Mesos) / Spark ...凭一个公司的力量是很难跟上社区的发展速度的。国内的大多数开源项目不管是代码质量，用心程度，设计的视野上都太弱了，连最基本的英文交流都很少有开源项目注意，更不用说生态了。不过，还是有希望的，至少学术界最近几年的进展，让我们看到了在分布式 OLTP 系统 (NewSQL) 上的一些希望，而且这块在全球范围内都是一个蓝海。基于这个背景，我们创立了 PingCAP，从零开始抛开一切历史包袱去实现一个全新的数据库 TiDB，TiDB 的目标就是瞄准世界顶级的通用分布式数据库开源项目和未来的行业标准去的。虽然这个东西确实很难, 但我也不觉得我们会比硅谷的顶级基础软件公司差:)，不客气的讲，我们在这个领域也远远走到了各个友商的前面，另外一方面如果不难也没有做它的价值，如果未来的数据库还是需要像现在分库分表中间件 Oracle，我觉得就太无趣了。就说一个 Cloud-Native，目前来说基本没有 OLTP 的数据库能搞定。
阿里云曾经选取了三款典型的国产分布式数据库进行全方位对比压测，测试结果如下，供大家参考：
TiDB：
1. 开启了实验室特性(plan cache)，不建议生产直接使用。生产环境默认不开启的话，point_select性能会有60%左右的性能下降，100核左右的资源点查场景只有36万QPS；
2. sysbench测试场景中，会有比较大量的where id between xx and xx，但在实际业务中单纯基于用户id或者交易id的范围查询意义并不大，更多是在时间范围的查询。TiDB基于Range的分区策略，在between的分区裁剪可以做到只访问1个数据分片，而PolarDB-X和OceanBase基于Hash的策略会访问5个数据分片，因此TiDB的数据结构会在sysbench单纯指标能力上占一定的优势。ps. 针对Range 和 Hash分区的性能差异，在PolarDB-X上基于read only场景下跑了下Range分区的对比测试，Range相比于Hash分区差不多有45%左右的性能提升(28万 vs 19万)；
3. TPC-C场景下，整体劣势比较明显；
4. TPC-H场景下，在tilfash模式下性能表现不错，但在普通的tikv模式下，部分SQL跑不出结果；
5. 特殊场景下，加索引的DDL性能有待提升，支持json但不建议生产使用，以及在热点行更新下有明显瓶颈。
OceanBase：
1. 非分区表(通常理解的单表)，在OceanBase内部会在分布式多个节点上做表级别的均衡，一张表的数据只在一个节点，不同表可以在不同的节点，在非分区表下比较考验纯单机的能力。针对sysbench场景下的多张表在测试过程中是完全独立的，这样可以充分利用"多个单机"跑出一个更好的总吞吐值。这样的模式下，相比于TiDB会有30%~70%的优势，多个独立的单表模式在真实业务场景中一般需要配合业务端的分库分表；
2. 分区表，在OceanBase内部支持将一张表的数据分布到多台机器上，实现行级别的水平扩展能力，在分区表下会存在分布式事务、分片聚合查询等额外代价，是最考验分布式能力的地方。分区表和非分区表在sysbench的性能测试结果上，两者的性能差异巨大。尤其在写入和混合读写场景，分区表只有单表测试的1/5左右，分布式事务的性能还需要有进一步的提升空间；
3. TPC-C场景下表现优秀。在TPC-H场景下，通过并行计算+行存整体表现不错；
4. 特殊场景下，不支持json，以及在热点行更新下有明显瓶颈。
PolarDB-X：
1. 非分区表(通常理解的单表)，PolarDB-X上支持通过locality模式将表分配到不同的节点，一张表的数据只在一个节点上，比较考验纯单机的能力。针对纯读和混合读写场景，相比于TiDB会有2~2.5倍的性能优势；
2. 分区表，在PolarDB-X内部支持将一张表的数据分布到多台机器上，实现方式和TiDB、OceanBase分布式表基本一致，在write only上整体性能会比TiDB好一些；在最常见的业务场景read write下，分区表和单机表性能都比OB要好很多，非分区表比TiDB有明显的性能优势，分区表跟TiDB基本保持一致；
3. TPC-C场景下表现优秀。在TPC-H场景下，通过并行计算+行存整体表现不错；
4. 特殊场景下，快速加列DDL需要优化，支持json，以及针对热点更新的优化明显。PolarDB-X对分区规则变更支持最好，基本支持所有常见的分区变更策略。
总结
1. PolarDB-X/OceanBase/TiDB在分布式水平扩展的性能上大同小异，区分度并不大；
2. TiDB有一些不错的实验性质的功能(比如plan cache、json)，对性能和功能易用性帮助比较大，但眼下生产不推荐使用；
3. OceanBase的模型比较复杂，测试场景需要充分理解分区表和 非分区表(单表)。在非分区表(单表)模式下，性能表现不错，重点考察的是纯单机能力，性能尚可，略低于MySQL。但分区表模式下，性能下降比较多，需要业务区分来看；
4. PolarDB-X功能性和易用性比较不错，json、大事务、热点更新支持比较完整。在非分区表(单表)模式下，纯MySQL单机的能力表现突出，在分区表模式下，可以通过分布式能力进一步扩展性能，对分区表的变更策略支持最完善。