共计 2380 个字符，预计需要花费 6 分钟才能阅读完成。
明天想聊一下 ORACLE 数据库之外的数据库产品。
话说关系式数据库的巨头们（ORACLE，SQL SERVER 还有 DB2 等等）在景色了二三十年之后，遇到的本人的瓶颈。
第一，数据库自身的性能遇到了挑战。
因为关系数据库诞生在上世纪 70 年代，受到科技倒退和人类意识的局限性的限度，包含像埃德加·弗兰克·科德（EdgarF.Codd）这样的数据库实践先驱或者埃里克森这样的商业奇才都没有意识到即便在摩尔定律的加持下，计算机硬件的倒退在互联网时代中爆炸性增长的数据量下显得那样楚楚可怜。
这里讲一个小故事。
在 2006 年，作为 ORACLE 在亚太地区的最大客户，阿里巴巴面临一个前所未有艰难，就是已有的 IT 设施应用达到瓶颈，如果再以目前的架构继续上来，为了可能反对流量的承载，阿里巴巴购买服务器、数据库产品的收入足够让阿里巴巴破产。于是，聪慧的阿里工程师想到了一个古老的战术：人海战术。
当然不是用人去堆，而是用 PC 机。
也就是用数量宏大 PC 机，运行小规模的 Mysql 数据库，用集群战术反抗大量的小计算量的事物解决。这和像 ORACLE 一样竭力打造一台超级数据库解决所有解决的传统关系数据库走的路线有很大不同。用一个比喻就是，一个用一匹强健的大马拉一台设计精密，价格昂贵的马车，另一个是用一群小马，每一匹小马来一台设计简略，价廉物美的小车。
这样益处是，前者是即便再强健的大马，甚至火车头，也有拉不动的大车。然而后者却能够无限量的横向扩大，（实践上）再多的货物也能够解决。
第二，数据库表（Table）的记录达到一定量的数量级后，表构造的批改是 COST 将异样低廉。因为关系数据库的表是通过严格设计的，以行为单位的存储在数据块（Data Block）中的。这意味着批改表构造（例如减少列）须要批改所有的数据块，还有可能因为批改后的数据不能存储在原有的数据块中，产生大量的行连锁和行移行。这还不包含如果列之间存在束缚或者外键之类的 Check 解决和关联索引的保护所须要的 Cost。
当意识到传统的关系数据库遇到的下面的两个瓶颈，并且简直是没有能力在本人的畛域内解决问题之后，人们就开始思考其余的解决办法：
非关系模式的新的数据库模型 – NoSQL。
这里的“NoSQL”不是“Not a SQL”, 而是“Not Only SQL”。
NoSQL 这个术语最早是在 1998 年被 Carlo Strozzi 提出。用来命名他开发的轻量的，开源的关系型数据库上；
在 2009 年再次被 Eric Evans 提起，探讨分布式开源数据库的问题，这是的 NoSQL 次要指的非关系型，分布式的，不提供关系型的 atomicity(A)，consistency(C)，isolation(I)，durability(D) 即 ACID 的个性的数据库；
紧接着 2009 年在亚特兰大举办的 nosql 讨论会，确定了最广泛的 NoSQL 解释为非关系型的，强调 Key-Value 和 Document(文档)数据库的长处，并非单纯的拥护关系型数据库；
所以，咱们总结一下 NoSQL 数据库的特点：
非关系型的（non-relational），分布式的（distributed），开源的（open-source），可程度扩大的（horizontally scalable）下一代数据库（Next Generation Databases）。
NoSQL 数据库次要有上面几个倒退方向：
键值 (Key-Value) 存储数据库
这一类数据库次要会应用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。Key/value 模型对于 IT 零碎来说的劣势在于简略、易部署。然而如果数据库管理员 (DBA) 只对局部值进行查问或更新的时候，Key/value 就显得效率低下了。
列存储数据库
这部分数据库通常是用来应答分布式存储的海量数据。键依然存在，然而它们的特点是指向了多个列。这些列是由列家族来安顿的。
文档型数据库
文档型数据库的灵感是来自于 Lotus Notes 办公软件的，而且它同第一种键值存储相相似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格局存储，比方 JSON。文档型数据库能够看作是键值数据库的升级版，容许之间嵌套键值，在解决网页等简单数据时，文档型数据库比传统键值数据库的查问效率更高。
图形 (Graph) 数据库
图形构造的数据库同其余行列以及刚性构造的 SQL 数据库不同，它是应用灵便的图形模型，并且可能扩大到多个服务器上。NoSQL 数据库没有规范的查询语言(SQL)，因而进行数据库查问须要制订数据模型。许多 NoSQL 数据库都有 REST 式的数据接口或者查问 API。
以下是各种数据库的比拟：
最初，咱们聊一下数据库畛域里驰名的”CAP“实践。
CAP 定理（CAP theorem）
在计算机科学中, CAP 定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer’s theorem）, 它指出对于一个分布式计算零碎来说，不可能同时满足以下三点:
* 一致性(Consistency) (所有节点在同一时间具备雷同的数据)
* 可用性(Availability) (保障每个申请不论胜利或者失败都有响应)
* 分隔容忍(Partition tolerance) (零碎中任意信息的失落或失败不会影响零碎的持续运作)
CAP 实践的外围是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需要，最多只能同时较好的满足两个。
因而，依据 CAP 原理将 NoSQL 数据库分成了满足 CA 准则、满足 CP 准则和满足 AP 准则三 大类：
* CA - 单点集群，满足一致性，可用性的零碎，通常在可扩展性上不太强大。* CP - 满足一致性，分区容忍性的零碎，通常性能不是特地高。* AP - 满足可用性，分区容忍性的零碎，通常可能对一致性要求低一些。
那为什么最多只能同时较好的满足两个准则呢？
能够读一下 阮一峰的 Blog，写的深入浅出，很精彩。
