数据的积累是当今各个行业巨头的财富，而数据库是存储数据的重要方式。在大数据和微服务流行的今天，传统的关系型数据库也将迎来变革。云原生数据库架构越来越受到关注，所以想和大家聊一聊云原生数据架构。作为本文的第一部分，我们先来分析一下目前各种数据库的发展现状。1.关系型数据库还可用吗？几十年来，关系数据库一直是数据库领域的领导者。下图是全球比较权威的DB-Engines的统计排名。排名主要依据Google和Bing搜索引擎的关键字搜索次数、员工人数、职位搜索次数、StackOverflow上的问题和关注次数等：DB-Engines20186AsofJune2018年Top6数据库中，只有排在第5位的MongoDB是文档型数据库，其余均为关系型数据库，前3名的占比遥遥领先于之后的其他数据库。一、优势关系型数据库在大数据、NoSQL、NewSQL等技术革新的冲击下依然强大，这与其先天优势是分不开的。它的优势主要体现在对开发人员、运维人员以及系统本身的影响上。开发优势对于开发人员来说，关系型数据库的首要优势是面向SQL。SQL是一种用于关系数据库的结构化查询语言。尽管不同的关系数据库有不同的SQL方言，但大多数关系数据库都支持基于ANSI标准的SQL。而SQL是一种面向数据库的访问语言，可以方便地对数据库进行增、删、改、查、授权和管理。SQL的查询灵活性非常高，在联机事务处理（OLTP）和联机分析处理（OLAP）之间切换非常方便。另外，SQL是应用开发工程师必须掌握的编程语言。很吃香，招到一个完全不会写SQL的应用开发程序员的概率很小。因此，SQL大大降低了开发人员招聘成本。除了SQL语言本身，各种开发语言也对关系型数据库有着完善的支持。以Java为例：JDBC是Java语言访问数据库的标准接口，各关系数据库厂商都提供了实现JDBC接口的驱动程序。使用Java语言开发的工程师不需要感知不同关系型数据库之间的差异，只要按照JDBC接口进行编程即可。由于面向关系的数据库存储和面向对象的Java程序不容易一一对应，因此许多对象关系映射（ORM）框架被用来简化关系对象模型的阻抗不匹配，例如JPA及其官方实现了Hibernate、MyBatis、Jooq等，进一步简化了应用工程师的日常开发工作。大多数ORM框架都是由JDBC封装的，对各种关系型数据库的兼容非常好。运维优势关系型数据库由来已久。对于每一种常见的关系型数据库，都比较容易招聘到相应的数据库管理员（DBA），以保证关系型数据库的稳定性、安全性和完整性。性能和性能，同时保证对关系数据库系统瓶颈的监控和分析以及设计的合理性。成熟的关系型数据库有自己完整的生态系统，用于保证高可用、数据备份、性能监控分析等成熟的配套工具。较大的企业和重要的业务系统一般都需要专门的DBA进行运维。系统优势只有时间才是检验技术成熟度和稳定性的标准。关系数据库经过几十年的考验，已经大规模使用，其存储引擎非常成熟。基于MVCC的数据库引擎在性能和正确性之间取得了很好的平衡，通过B+树索引大大提高了查询效率。面对数据等关键节点，慎重选择关系型数据库是架构师的最佳方案。基于ACID的事务是关系型数据库给应用系统带来的又一有力保障。ACID是数据库事务必须正确执行的四个基本元素的首字母缩写词。它包括原子性、一致性、隔离性和持久性。只有支持事务的数据库才能最大限度的保证数据的正确性和完整性：原子性。同一个事务中的所有操作要么全部完成（commit），要么全部未完成（rolledback），不能停滞在一个中间环节。如果在事务执行过程中发生错误，数据将恢复到事务开始前的状态。一致性。非只读事务应该封装数据库从一种一致状态到另一种一致状态的状态转换。一致状态意味着数据库中的数据应该满足完整性约束，事务的中间状态不应该在事务之外被感知。隔离。当多个事务并发执行时，它们不应该影响其他事务，就好像只有这一个操作被数据库并行执行。耐用性。事务完成后，事务对数据库的所有更改都会持久化到数据库中。在编程中使用事务并不难。Spring等各种开发框架在面向切面（AOP）层面已经做到了非常简洁和优雅。2、关系型数据库的性能和访问承载能力不足，在企业级应用面向单一数据节点的时代无可挑剔。但在访问量和数据量急剧膨胀的今天，关系型数据库很难像以前那样成为如此大规模系统的底层支撑，甚至成为应用系统的瓶颈。关系型数据库主要有以下三个不足：单个节点的并发访问数有限。而服务可以任意扩展和拆分，因为存储在数据库中的数据是有状态的，所以很难像服务那样??任意拆分和扩展。单个数据库节点承载大量来自服务节点的查询和更新请求，不是对等架构部署模型。单个节点的数据承载能力是有限的。单个数据库节点的数据承载能力是有限的。数据量越大，为查询数据创建的索引就越深。索引深度决定了IO访问的次数。索引深度越深，搜索越慢。分布式事务性能严重下降。拆分数据库后，需要使用分布式事务，而不是本地事务。基于XA的分布式事务采用两阶段提交，在准备阶段锁定资源，直到整个事务结束。当系统并发增加时，性能会急剧下降。综上所述，关系型数据库的缺点归根结底是设计初衷造成的。它不是分布式产品，天生对分布式系统不友好，很难适应互联网的架构模型。面对可以随时弹性扩展的无状态服务，关系型数据库已经有些笨重了。2、没有达到预期的NoSQL随着关系型数据库的不足越来越明显，NoSQL的出现成为一种有益的补充。但是，NoSQL并不是要取代关系型数据库，而是指NotOnlySQL，它提供了SQL的替代方案。NoSQL有多种类型，包括键值数据库、文档数据库、列族数据库和图数据库，用于解决不同的场景。1.键值数据库键值数据库的代表是Redis。它在很多场景下被用作缓存，但是Redis也提供了drop功能。面对通过主键查询的场景，Redis效率很高，但是对于内容查询就无能为力了。Redis提供了集群的能力，可以将数据分布到不同的节点上，有效的分散了单个节点的访问瓶颈。如果Redis的数据无法全部加载到内存中，磁盘掉线，Redis的性能就会下降。因此，在数据量很大的情况下，根据主键对Redis数据进行分片是一个很好的解决方案。Redis通过MULTI、EXEC、DISCARD和WATCH命令提供事务功能。Redis事务为执行命令提供了一种一次性的、顺序的和不间断的机制。但是，即使事务中的某些命令执行失败，也无法回滚，所以Redis事务与数据库域中的事务不是一对一的关系。2.文档数据库文档数据库的代表是MongoDB。文档模型更接近于面向对象的数据表达。它具有高度自由的Schema模型，可以很容易地与JSON数据进行映射。文档数据库的设计理念与关系数据库完全不同。它没有静态定义的表结构，但可以灵活地在文档中添加或删除属性，随意嵌入子文档和数组。因此，文档型数据库应用程序的设计应着眼于对象本身，而不是优先考虑数据库表结构是如何定义的。这样的设计使得开发工程师修改程序逻辑非常方便，无需考虑数据库表结构变化导致的表锁等问题。MongoDB的查询维度非常灵活，可以根据要查找的内容建立索引，提高效率。另外，MongoDB在分布式性能方面远强于关系型数据库。它可以自动对数据进行分片，并且可以透明地在分片之间进行负载平衡和故障转移。它还内置了GridFS，支持大数据集的存储。但是MongoDB不能像关系型数据库那样支持ACID事务，而是使用最终一致性事务。因此，不建议将MongoDB用于订单、交易、账户等非常关键的业务系统，而是用于论坛等数据交易。在要求较低层次的业务系统中。3、列族数据库列族数据库的代表是位于Hadoop大数据体系中的HBase。它是专门为处理海量数据而设计的分布式数据库。HBase通过行主键和列族来确定一条记录，每个列族中的属性不固定，类似于文档数据库。HBase还可以自动拆分数据，让数据存储自动横向扩展。HBase数据存储在HDFS等分布式文件系统中，是对海量数据最好的支持。HBase使用LSMTree(Log-StructuredMerge-Tree)。它将数据的变化放在内存中，在达到指定阈值后，将变化合并并批量写入磁盘，将单次写操作变成批量写操作，大大提高了写入速度。但是HBase在读取数据时，需要分别在内存和磁盘中查找数据，这对性能有一定的影响。因此Hbase更适合写多读少的应用。另外Hbase也不支持ACID事务，只能通过行键查询数据。图数据库是用于处理图关系的数据库，用于特殊场景，这里不再介绍。总的来说，NoSQL数据库有多种类型，适用于不同的场景。下面我们用下表来简单对比一下上面介绍的三种NoSQL数据库：虽然各种NoSQL数据库的使用场景有很大的不同，但是大多都支持分布式数据库所需要的分片和数据迁移功能。比传统关系型数据库对海量数据和大并发的支持更强。NoSQL数据库虽然可以提供很好的扩展性和灵活性，但是它们的缺点也很明显：不同的NoSQL数据库有自己的查询语言。与SQL相比，制定标准的应用接口更是难上加难。而且NoSQL不能提供ACID事务操作，所以很多企业不能安全地将NoSQL应用到核心业务系统中。正如NoSQL的定义所说，它们只是对基于SQL的关系型数据库的有用补充，而不是关系型数据库的替代品。3、崛起的NewSQL因为SQL和ACID事务太流行，分布式数据库的需求极其强烈，所以又一个数据库NewSQL应运而生。NewSQL是各种分布式和可伸缩数据库的缩写。它继承了NoSQL处理海量数据的能力，同时保持了传统关系型数据库对SQL和ACID事务的支持。NewSQL专注于混合数据库，他们更倾向于寻找不再区分OLTP和OLAP查询的多模式建库方案。2016年，AndrewPavlo和MatthewAslett发表了一篇论文：《What’s Really New with NewSQL?》，其中他们将NewSQL分为三类：NewArchitecture、TransparentShardingMiddleware和Clouddatabase（Database-as-a-Service）。论文参考链接：https://db.cs.cmu.edu/papers/2016/pavlo-newsql-sigmodrec2016.pdf1.新架构NewSQL是一种全新的分布式架构的数据库系统。它们通常采用无共享架构，支持多节点并发控制、高容错自动数据副本复制、流量控制和分布式查询处理等特性。由于它们本质上是为分布式多节点系统设计的，因此它们可以更好地处理查询优化和节点间通信协议。例如NewSQL数据库的多个数据节点可以不依赖中心节点直接通信。除了Google的Spanner，其他类似的数据库都需要管理数据在磁盘和内存中的存储和分布。这意味着这种类型的数据库系统负责向数据节点发送查询，而不是将数据复制到请求节点以减少网络流量。由于采用了全新的架构设计和存储引擎，还没有经过时间的充分验证，所以企业的技术选择者格外谨慎。同时，由于拥有新一代NewSQL运维经验的工程师相对较少，与关系型数据库相比，目前的用户也比较少。目前很多企业都在努力跟进NewSQL的新架构，但还没有对核心系统进行迁移。新架构类型最典型的产品是Google的Spanner和国产数据库TiDB。2.透明分片中间件透明分片数据库中间件允许应用程序将数据分片写入多个数据节点，但数据节点仍然使用关系数据库作为单个数据节点。透明分片中间件使用中央组件来路由数据操作请求、协调事务、管理数据分布和复制数据副本。整个集群对外是一个逻辑实例，应用往往不需要修改就可以流畅使用。透明分片数据库中间件的核心优势是兼容性。它可以低成本地在现有的单机关系数据库和分片中间件之间切换，而无需开发人员进行任何代码更改。它们旨在在分布式场景中充分合理地利用传统关系数据库的计算和存储能力，而不是实现一个全新的关系数据库。这样可以利用传统关系型数据库的稳定性和兼容性，在其基础上增加分布式场景的处理。在原有基础上增量而不是颠覆，是这类NewSQL产品的核心理念。由于开源和流行，基于MySQL协议的数据库中间件最为常见。由于传统的基于单数据节点的关系型数据库是为磁盘设计的，因此基于内存的存储管理和并发控制的效率不如重新设计的面向分布式的新架构NewSQL。此外，SQL解析、查询计划优化等工作会在中间件和数据库中重复进行，使得整体运行效率略低于新设计的NewSQL。这种NewSQL在国内大中型互联网公司中非常流行，每个公司基本上都有自己的数据库中间件。但由于与公司内部业务系统耦合度高，目前成熟的开源产品很少。后面我们要讨论的Sharding-Sphere生态中的Sharding-Proxy就属于这类NewSQL产品。3、云数据库NewSQL的最新型是云计算公司提供的云数据库产品。云数据库的使用者无需自行维护数据库及其硬件，所有数据都托管在云平台提供的服务上。用户通过数据库的URL连接到云端数据库，通过API或操作仪表盘对系统进行操作和监控。使用云数据库成本低，工程师无需考虑数据库的任何细节。对于中小型企业来说是一个理想的解决方案，但是对于数据量巨大的企业来说，前两种NewSQL开源或者自研的方案更为合适。亚马逊提供的Aurora就是这类NewSQL的典型应用。总的来说，NewSQL虽然还不成熟，但确实是对未来的一次正确尝试。三种NewSQL数据库的侧重点不同。新架构类型数据库的重点是彻底创新；透明分片数据库中间件的重点是增量；而云数据库更注重屏蔽用户使用细节。虽然不同的类型各有优缺点，但它们的核心功能是相似的。不管是哪种NewSQL，Hybrid数据库都会是未来的发展方向。当OLTP和OLAP不再区分时，开发成本将大大降低。至此，我们基本弄清楚了目前各种数据库的发展现状。在下一篇文章中，我将详细介绍云原生数据库的核心功能特性。也欢迎有相关想法的同学留言交流。
