关系型数据库尚能饭否？NoSQL、NewSQL谁能接棒？

数据的积累是当今各行各业巨头的企业财富，数据库则是数据存储的重要途径。在大数据和微服务大行其道的今天，传统的关系型数据库也将迎来变革。云原生的数据库架构受到越来越多的关注，所以我想和大家一起来聊聊云原生数据架构。本文作为上篇，会先对当下各类数据库发展现状进行分析。

一、关系型数据库尚能饭否?

关系型数据库出现至今的几十年时间里，一直是数据库领域的佼佼者。下图是全球较为权威的DB-Engines的统计排名，排名主要依据Google以及Bing搜索引擎的关键字搜索数量、从业人数信息、职位搜索量、Stack Overflow上提问关注数量等：

DB-Engines 2018年6月公布的数据库排名

截止至2018年6月，排名前6位的数据库，仅有排名第5的MongoDB是文档型数据库，其余全部是关系型数据库，且前3位所占有的比重远远领先于其后的其他数据库。

1、优势

关系型数据库在经过大数据、NoSQL以及NewSQL等技术革新的轮番轰炸之后依然坚挺，与其固有的优势密不可分。它的优势主要体现在对开发人员、运维人员以及系统本身这3个方面的影响。

开发优势

对于开发人员来说，关系型数据库的首要优势是面向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+tree索引大幅提升了查询的效率。面对数据这样的关键节点，谨慎的选用关系型数据库是架构师们的首选方案。

基于ACID的事务是关系型数据库带给应用系统的又一强力保障。ACID指数据库事务能够正确执行的四个基本要素的首字母缩写。它包括原子性、一致性、隔离性和持久性。只有支持事务的数据库才能最大限度的保证数据的正确性和完整性：

• 原子性(Atomicity)。位于同一事务中的所有操作，要么全部完成(提交)，要么全部不完成(回滚)，不能停滞在某个中间环节。如果事务在执行过程中发生错误，数据将会恢复到事务开始前的状态。
• 一致性(Consistency)。非只读的事务应封装数据库的状态从一个一致状态转变为另一个一致状态。一致状态是指数据库中的数据应满足完整性约束，并且事务的中间状态不应在事务之外被感知。
• 隔离性(Isolation)。多事务并发执行时，不应相互影响其他事务，就像只有这一个操作在并行的被数据库执行一样。
• 持久性(Durability)。事务完成后，该事务对数据库的所有更改将持久的保存在数据库中。

在编程中使用事务也并非难事，各类如Spring之类的开发框架已经在面向切面(AOP)层面将其做的十分简单和优雅了。

2、不足

关系型数据库的性能和访问承载能力，在面向单一数据节点的企业级应用时代是无可挑剔的。但在访问量和数据量急剧膨胀的今天，关系型数据库已经很难再像以前那样成为如此巨大规模系统的底层支撑，甚至成为了应用系统的瓶颈所在。

关系型数据库主要有以下三处不足：

• 单节点并发访问量受限。在服务任意扩容和拆分的同时，由于数据库中存储的数据是有状态的，因此很难像服务一样任意拆分和扩容。单一的数据库节点承载大量的服务节点的查询和更新请求，这并非一个对等的架构部署模式。
• 单节点数据承载量受限。单一数据库节点对数据的承载能力是有限的。数据量越大，用于查询数据所创建的索引的深度就越深。索引深度决定IO访问的次数，索引深度越深，查找越慢。
• 分布式事务性能衰退严重。将数据库拆分之后，需要使用分布式事务代替本地事务。基于XA的分布式事务采用两阶段提交，在准备阶段即锁定资源，直至整个事务结束。在系统并发度增加时，性能会急剧衰退。

综上所述，关系型数据库的不足，归根结底是设计初衷导致的。它并非分布式的产物，对分布式系统的天生不友好，导致它很难适应互联网的架构模型。面对可以随时弹性扩容的无状态服务，关系型数据库已经略显笨重。

二、未达预期的NoSQL

随着关系型数据库的不足之处暴露得越来越明显，NoSQL的出现成为了有益补充。不过NoSQL并非为了取代关系型数据库，而是指Not Only SQL，提供了在SQL之外的另一种选择。

NoSQL有很多种分类，大致包括键值数据库、文档数据库、列族数据库以及图数据库等，用于解决各异的场景。

1、键值数据库

键值数据库的代表是Redis。它在很多场景下都作为缓存使用，但Redis也同样提供落盘功能。面对通过主键查询的场景，Redis的效率非常高，但对于内容的查询，则无能为力。

（编辑：青岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!