RDBMS vs. NoSQL：反派为什么会得以存活并发展壮大

摘要：尽管数百NoSQL林立，尽管在不同的场景下NoSQL有着传统数据库无可匹敌的性能，然而在人气上，NoSQL也只能望其项背。所谓存在既有道理，这里一览如此强势RDBMS笼罩下，这个反派存在的原因。

在学习不同NoSQL系统的特性之前，了解一下NoSQL的发展史总不会错的；用一句话来说，NoSQL是天生的反派！

天生的反派NoSQL

这里我们不妨把NoSQL比作No SQL，它必须站在RDBMS的对立面，这里不妨通过逻辑流来解释一下这个观点：

RDBMS通过匹配关系数据（关系和表格）的数据操作方法定义SQL语言，并且支持ACID特性的事务。

横向扩展在数据处理前就会进行分配，用以满足网络服务的高吞吐量需求。当下RDBMS横向扩展的更趋向于维护关系模型的作业完整性，这和事务操作构成了RDBMS的核心。

然而在维护完整性的同时进行扩展是非常难得的，而在分配和复制数据时会出现类似的问题。所以在进行横向扩展之前，必须保证通过DBMS实现的基于ACID事务特性不那么严格，当然还有复制完整性也不能那么严格。

RDBMS的横向扩展

对RDBMS进行扩展是很难的。如果只是扩展到几千规模是很轻松的，类似Oracle 这样领先的数据库开发机构在很早之前就发布了一两个这样的产品。

这里不妨假设将RDBMS中的表格分配到几台主机上，而为了高可用性每份数据都会在存储前都会被复制。首先，在保证ACID进行扩展时执行分配操作就非常困难。

想实现ACID中的原子性，执行某个事务时，类似2PC这样的分布事务协议必须在所有系统中使用。

为了满足ACID特性中的隔离级别，数据通常都会被加锁。锁的级别可以是一条记录，一个表格或者是一个索引。

因此，为了在分布式环境中满足原子性和隔离需求，因此在分布式事务协议的处理期间，每个系统都会加上所有相关的锁；系统的负载越大，锁的竞争越繁重。这就是很难扩展的原因。

另一个横向扩展中必须面临的问题就是数据的复制和分配。

事务性复制使用了2PC方法，这里存在的问题就是：当与某个复制事务相关的任何系统出故障时，这个事务就会失败并变得不可用。此外，当复制事务同时涉及几个系统时，性能就会降低。

作为替代，将一个DBMS的WAL（Write Ahead Logging，预写式日志）数据传送给备份系统并让它使用。节点可以配置为master-slave或multi-master方式。

当使用master-slave类型时：这也是最常见的复制方法。复制过程的速度与系统中的从节点数量成反比。

当使用multi-master配置时：当同时存在几个主节点时，处理数据写入进程间的冲突是非常困难的，并且很难阻止这个情况发生。在《The Danagers of Replication and a Solution》一书中（曾获1998年图灵奖），Jim Gray对这个问题进入了深入研究。

通过开发者分片

通常来说，在满足ACID特性的数据库中进行扩展是非常难的。基于这个原因，对数据进行扩展，这个数据库本身就必须拥有简单的模型，将数据分割为N片，然后在单独的片中执行查询。

数据分割的单元被称为“shard”。将N片数据分配个M个DBMS进行操作。DBMS并不会去管理数据片，这需由服务开发者自行完成。

分片的方法由开发者决定，这里同样会有几个问题：

首先，分片必须被定义。

其次，分片映射：

RDBMS的基本储存单元是表格。鉴于一个表格可能会包含一个或多个分片，这里需要明白分片需要被映射到的数据库实例。应用程序也必须知道分片表格对应的位置。

最后，分片的分配和重分配：

鉴于吞吐量需求和数据体积，每个分片都不同。所以开发者必须从数据库中增加或者删除一个实例，并且手动重分配分片。这个过程非常繁琐。同时在这个过程中，修改的映射信息必须告知应用程序。数据修改后，还必须做相应的管理（比如，针对复制的配置）。

原文链接： RDBMS vs. NoSQL