编者按：
本文作者系Scott（中文名陈晓辉），现任大连华信资深分析师 ，ORACLE数据库专家，曾就职于甲骨文中国。个人主页：segmentfault.com/u/db_perf ，经其本人授权发布。
今天想聊一下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）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:
代码语言：javascript复制* 一致性(Consistency) (所有节点在同一时间具有相同的数据)
* 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
* 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
代码语言：javascript复制* CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
* CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
* AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
那为什么最多只能同时较好的满足两个原则呢？
可以读一下 阮一峰的 Blog(CAP 定理的含义：https://www.ruanyifeng.com/blog/2018/07/cap.html)，写的深入浅出，很精彩。
