标签：

1. 关系型数据库

关系型数据库，是指采用了关系模型来组织数据的数据库。

关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的，在之后的几十年中，关系模型的概念得到了充分的发展并逐渐成为主流数据库结构的主流模型。

简单来说，关系模型指的就是二维表格模型，而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。

关系模型中常用的概念：

• 关系：可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名
• 元组：可以理解为二维表中的一行，在数据库中经常被称为记录
• 属性：可以理解为二维表中的一列，在数据库中经常被称为字段
• 域：属性的取值范围，也就是数据库中某一列的取值限制
• 关键字：一组可以唯一标识元组的属性，数据库中常称为主键，由一个或多个列组成
• 关系模式：指对关系的描述。其格式为：关系名(属性1，属性2， ... ... ，属性N)，在数据库中成为表结构

关系型数据库的优点：

• 容易理解：二维表结构是非常贴近逻辑世界的一个概念，关系模型相对网状、层次等其他模型来说更容易理解
• 使用方便：通用的SQL语言使得操作关系型数据库非常方便
• 易于维护：丰富的完整性(实体完整性、参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率

2. 关系型数据库瓶颈

• 高并发读写需求

网站的用户并发性非常高，往往达到每秒上万次读写请求，对于传统关系型数据库来说，硬盘I/O是一个很大的瓶颈

• 海量数据的高效率读写

网站每天产生的数据量是巨大的，对于关系型数据库来说，在一张包含海量数据的表中查询，效率是非常低的

• 高扩展性和可用性

在基于web的结构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展 是非常痛苦的事情，往往需要停机维护和数据迁移。

对网站来说，关系型数据库的很多特性不再需要了：

• 事务一致性

关系型数据库在对事物一致性的维护中有很大的开销，而现在很多web2.0系统对事物的读写一致性都不高

• 读写实时性

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比如发一条消息之后，过几秒乃至十几秒之后才看到这条动态是完全可以接受的

• 复杂SQL，特别是多表关联查询

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品阶级角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能极大的弱化了

在关系型数据库中，导致性能欠佳的最主要原因是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。为了保证数据库的ACID特性，我们 必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一个格式化的数据结构。每个元组字段的组成都是一样，即使不是每个元组都需要所有的字段， 但数据库会为每个元组分配所有的字段，这样的结构可以便于标语表之间进行链接等操作，但从另一个角度来说它也是关系型数据库性能瓶颈的一个因素。

3. NoSQL

NoSQL一词首先是Carlo Strozzi在1998年提出来的，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。这个定义跟我们现在对NoSQL的定义有很大的 区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，我们要的不是“no sql”，而是“no relational”，也就是我们现在常说的非关系型数据库了。

2009年初，Johan Oskarsson举办了一场关于开源分布式数据库的讨论，Eric Evans在这次讨论中再次提出了NoSQL一词，用于指代那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。Eric Evans使用NoSQL这个词，并不是因为字面上的“没有SQL”的意思，他只是觉得很多经典的关系型数据库名字都叫“**SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同，就是用了“NoSQL“一词。

注：数据库事务必须具备ACID特性，ACID是Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性。

非关系型数据库提出另一种理念，例如，以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对，这 样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需要 像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供像SQL 所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数据，SQL数 据库显的更为合适。

4. 关系型数据库  V.S.  非关系型数据库

关系型数据库的最大特点就是事务的一致性：传统的关系型数据库读写操作都是事务的，具有ACID的特点，这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中，如典型的银行系统。

但是，在网页应用中，尤其是SNS应用中，一致性却不是显得那么重要，用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的，或者 说，两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的，因此，关系型数据库的最大特点在这里已经无用武之地，起码不是那么重要了。

相反地，关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差，而像微博、facebook这类SNS的应用，对并发读写能力要求极 高，关系型数据库已经无法应付(在读方面，传统上为了克服关系型数据库缺陷，提高性能，都是增加一级memcache来静态化网页，而在SNS中，变化太 快，memchache已经无能为力了)，因此，必须用新的一种数据结构存储来代替关系数据库。

关系数据库的另一个特点就是其具有固定的表结构，因此，其扩展性极差，而在SNS中，系统的升级，功能的增加，往往意味着数据结构巨大变动，这一点关系型数据库也难以应付，需要新的结构化数据存储。

于是，非关系型数据库应运而生，由于不可能用一种数据结构化存储应付所有的新的需求，因此，非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。

必须强调的是，数据的持久存储，尤其是海量数据的持久存储，还是需要一种关系数据库这员老将。

5. 非关系型数据库分类

由于非关系型数据库本身天然的多样性，以及出现的时间较短，因此，不想关系型数据库，有几种数据库能够一统江山，非关系型数据库非常多，并且大部分都是开源的。

这些数据库中，其实实现大部分都比较简单，除了一些共性外，很大一部分都是针对某些特定的应用需求出现的，因此，对于该类应用，具有极高的性能。依据结构化方法以及应用场合的不同，主要分为以下几类：

• 面向高性能并发读写的key-value数据库：

key-value数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的代表

• 面向海量数据访问的面向文档数据库：

这类数据库的特点是，可以在海量的数据中快速的查询数据，典型代表为MongoDB以及CouchDB

• 面向可扩展性的分布式数据库：

这类数据库想解决的问题就是传统数据库存在可扩展性上的缺陷，这类数据库可以适应数据量的增加以及数据结构的变化

1.实质。
非关系型数据库的实质：非关系型数据库产品是传统关系型数据库的功能阉割版本，通过减少用不到或很少用的功能，来大幅度提高产品性能。
2.价格。
目前基本上大部分主流的非关系型数据库都是免费的。而比较有名气的关系型数据库，比如Oracle、DB2、MSSQL是收费的。虽然Mysql免费，但它需要做很多工作才能正式用于生产。
3.功能。
实际开发中，有很多业务需求，其实并不需要完整的关系型数据库功能，非关系型数据库的功能就足够使用了。这种情况下，使用性能更高、成本更低的非关系型数据库当然是更明智的选择。

关系型数据库通过外键关联来建立表与表之间的关系，非关系型数据库通常指数据以对象的形式存储在数据库中，而对象之间的关系通过每个对象自身的属性来决定

关系型数据库和非关系型数据库应该怎样选择?

1.RDBMS都使用的比较多了,最近些年NoSQL也发展的比较快,相关的介绍:http://nosql-database.org/
2.至于如何选择,我觉得更多的还是看他们的区别和适用的场景,我建议混合使用,发挥每种数据库的优点;
3.其实这个问题可以转变成关系型数据库和非关系型数据库的差异和特点:
(1)关系型数据库的最大特点就是事务的一致性:传统的关系型数据库读写操作都是事务的,具有ACID的特点,这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中;所以说必须强调的是,数据的持久存储,尤其是海量数据的持久存储;
优点:

1)容易理解:二维表结构是非常贴近逻辑世界的一个概念,关系模型相对网状,层次等其他模型来说更容易理解;

2)使用方便:通用的SQL语言使得操作 关系型数据库非常方便;

3)易于维护:丰富的完整性(实体完整性,参照完整性和用户定义的完整性)大大减低了数据冗余和数据不一致的概率;
瓶颈:

1)高并发读写需求;2)海量数据的高效率读写;3)高扩展性和可用性
(2)但是有很多不需要关系型数据库的特性场景,可以采用NoSQLs:
1)数据模型比较简单;
2)要灵活性更强的IT系统;
3)对数据库性能要求较高;
4)不需要高度的数据一致性;
5)对于给定key,比较容易映射复杂值的环境;

什么是SQL

SQL指结构化查询语言,是一门ANSI(美国国家标准学会)标准的计算机语言,主要用来访问和操作数据库系统.某些关系型数据库要求在每个SQL 命令的末端使用分号，如MySQL（若不在命令末尾使用分号则报错），如果使用的关系型数据库是MS SQL Server或者SQL Server ，则不需要在每个SQL命令末端使用分号。

RDBMS

RDBMS指的是关系型数据库管理系统,RDBMS是SQL的基础,同样也是很多现在关系型数据库的基础,RDBMS的数据是存储在被称为表的数据库对象中,表是相关数据项的集合,由行和列组成,这也是关系型数据的典型特征.

DML和DDL

SQL分为两个部分：数据操作语言（DML）和数据定义语言（DDL）。

DML主要用于执行查询，更新，插入和删除的语法。SQL主要的DML语句有：

1）SELECT ----从数据库表中获取数据

2）UPDATE ----更新数据库表的数据

3）DELETE ----从数据库表中删除数据

4）INSERT INTO ----向数据表中插入数据

DDL主要创建和删除数据库或者表格，也可以定义索引（键），规定表之间的链接以及施加表间的约束。主要的DDL语句有：

1）CREATE DATABASE ----创建新数据库

2）ALTER DATABASE ----修改数据库

3）CREATE TABLE ----创建新表

4）ALTER TABLE ----变更数据库表

5）DROP TABLE ----删除表

6）DROP DATABASE ----删除数据库

7）CREATE INDEX ----创建索引（搜索键）

8）DROP INDEX ----删除索引   

主流的关系型数据库

Microsoft SQLServer,  IBM DB2,  Oracle, MySQL，  Microsoft Access，  Sybase，IBM Informix.

NoSQL

NoSQL,指的是非关系数据库。由上面的叙述可以看到关系型数据库中的表都是存储一下格式化的数据结构，每个元组字段的组成都是一样的，即使不是 每个元组都需要所有的字段，但数据库会为每个元组都分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系数据库性 能瓶颈的一个因素。而非关系数据库以键值对存储，它的结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加或减少一些自己的键值对，这样 就不会局限于固定的结构，可以减少一些时间和空间的开销。

NoSQL有那些

MangoDB，Membase，Hypertale，Apache Cassandra，BigTable，CouchDB，dynamoDB，SimpleDB, HBase（HadoopDatabase） ,Redis

 非关系数据库只实现了关系数据库一部分的功能，但因此很大程度上扩充了某些功能的性能。一般用关系数据库就够了。严格说mysql在关系数据库兄是实现得 也不是很完整的一类，从而在某些查询上，mysql有超出严格关系数据库很多的性能。具体应用需要权衡，特别是关联条件很多的数据，非关系数据库一般不合 适，有时候甚至mysql也不合适。

1. 非关系型数据库MongoDB  
2. 随着现在分布式数据库的崛起,部分的项目的后台已经渐渐的时候这种非关系型的数据库来设计了,那么这种数据库有什么样的有点呢?   
3. (1) 大 家都知道后期的数据库将是非常庞大的一个东西,好多的项目都是使用的关系型的数据库来支撑的,他们无疑是一个非常不错的选择,要考虑到后期程序的运行的效 率,那时候大家就会考虑使用程序来实现数据库的分布(或者使用非常好的服务器来支撑),但是后期发现的mongo确实可以帮助大家解决这种分布式所带来的 问题,mongo在设计出就是考虑到了这些问题,你只需建立一些引用的关系方可实现。 (2) Mongo 是一种面向对象的数据库，所以很适合面向对象的这种语言来使用(必须C#,java等高级语言),它原本只是被人们用来做缓存使用的数据库,就和 android的内置的sqlite一样,但是这并不会影响它的强大的锋芒,他们发现他们设计的这种思想非常的难得,就加以发展,也就是我们现在看到的 mongoDB。 (3) 强大的查询功能,mongo中的查询可以使用Pattern来查询,数据存储的时候可以存储json格式的数据,当然咋们查询的时候就可以xx.xx.xx=xxx这样的格式来匹配json格式的字段了。 (4) Mongo由于是非关系型的数据库,所以字段的存储也是非常的随便的,关系型数据库在设计的时候一般就会把所有的字段都确定好了,但是mongo不一样,在设计的时候前后台约定好哪些字段为必要的字段和类型。那么前台便可以很灵活的传一些字段到后台来。 (5) 但是mongo也有很多的缺点的,相对关系型数据库mongo的设计非常的复杂,甚至一个表中会出现多个表的引用而且这些引用都是多对多的关系，然而关系型数据库设计的时候通常会把多对多的关系转化为两个一对多来实现的。 (6) Hibernate框架，比如我们在开发jsp的一些项目的时候，可以使用到hibernate框架来影射数据库中的表与表之间的关系，但是mongo是做不到的，所以当设计到操作到多张表的时候就要自己动手敲代码了。(我做多写一个API写了300行涉及到了五张表联合操作,好多方法还封装了)。 (7) Mongo的存储非常的随便也导致了一些缺点，插入数据的时候字段可以随便的加没有任何的约束  

(1) 当需求提出来的时候，关系型数据库是通过主外键的关系来关联多张表的，虽然mongo中没有明显的主外键的关系但是我们可以通过对数据库的设计来实现这样 的关系。 Example：一个团队下面可以有多个业务但是一个业务只能归属一个团队。 我们可以这样设计，在业务表中加一个字段teamId类型为DBRef引用的类型，而团队的表中加一个字段taskId类型是一个 List<DBRef>的类型，这样就可以体现了团队和业务是一对多的关系了。 扩展：如果团队和业务的关系是多对多的关系的话，我们可以将业务中的teamId也换成List<DBRef>来方团队ID的引用集合。
(2) 关系型数据库在存放数据的时候尽量的做到分开来存放，但是mongo却不是这样的，设计的时候最好是遵循执行增加操作的时候繁琐一点没关系，但是查询的时候一定要简单，毕竟查询是sql语句中最长使用的。

从关系型数据库到非关系型数据库

 自1970年，埃德加·科德提出关系模型之后，关系数据库便开始出现，经过了40多年的演化，如今的关系型数据库具备了强大的存储、维护、查询数据的 能力。但在关系数据库日益强大的时候，人们发现，在这个信息爆炸的“大数据”时代，关系型数据库遇到了性能方面的瓶颈，面对一个表中上亿条的数据，SQL 语句在大数据的查询方面效率欠佳。我们应该知道，往往添加了越多的约束的技术，在一定程度上定会拖延其效率。

       在1998年，Carlo Strozzi提出NOSQL的概念，指的是他开发的一个没有SQL功能，轻量级的，开源的关系型数据库。注意，这个定义跟我们现在对NoSQL的定义有 很大的区别，它确确实实字如其名，指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷，CarloStrozzi也发觉，其实我们要的 不是"nosql"，而应该是"norelational"，也就是我们现在常说的非关系型数据库了。

       在关系型数据库中，导致性能欠佳的最主要因素是多表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询。 为了保证数据库的ACID特性，我们必须尽量按照其要求的范式进行设计，关系型数据库中的表都是存储一些格式化的数据结构，每个元组字段的组成都一样，即 使不是每个元组都需要所有的字段，但数据库会为每个元组分配所有的字段，这样的结构可以便于表与表之间进行连接等操作，但从另一个角度来说它也是关系型数 据库性能瓶颈的一个因素。

       非关系型数据库提出另一种理念，他以键值对存储，且结构不固定，每一个元组可以有不一样的字段，每个元组可以根据需要增加一些自己的键值对， 这样就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，用户可以根据需要去添加自己需要的字段，这样，为了获取用户的不同信息，不需 要像关系型数据库中，要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。但非关系型数据库由于很少的约束，他也不能够提供想 SQL所提供的where这种对于字段属性值情况的查询。并且难以体现设计的完整性。他只适合存储一些较为简单的数据，对于需要进行较复杂查询的数 据，SQL数据库显得更为合适。

       目前出现的NoSQL(Not only SQL，非关系型数据库)有不下于25种，除了Dynamo、Bigtable以外还有很多，比如Amazon的SimpleDB、微软公司的 AzureTable、Facebook使用的Cassandra、类Bigtable的Hypertable、Hadoop的HBase、 MongoDB、CouchDB、Redis以及Yahoo!的PNUTS等等。这些NoSQL各有特色，是基于不同应用场景而开发的，而其中以 MongoDB和Redis最为被大家追捧。

       以下是MongoDB的一些情况：

　　MongoDB是基于 文档的存储的（而非表），是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散， 是类似json的bjson格式，因此可以存储比较复杂的数据类型。模式自由(schema-free)，意味着对于存储在MongoDB数据库中的文 件，我们不需要知道它的任何结构定义。如果需要的话，你完全可以把不同结构的文件存储在同一个数据库里。Mongo最大的特点是他支持的查询语言非常强 大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

       Mongo主要解决的是海量数据的访问效率问题。因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统 GridFS，可以支持海量的数据存储。由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎。

关系型数据库和非关系型数据库的选择，以及替代方法(mysql替代mongodb)

我做的项目因为涉及到大量的历史数据增加而采用的非关系型数据（mongodb），但是在实际开过程中遇到了很多问题，有开发方面的，也有管理方面的，于是我思考了 用关系型数据库mysql代替非关系型数据库mongodb的思路 。

目前还没有实施，因为对项目的改动会很大，希望大家能看看我的思路，最好能提一些意见，谢谢各位了。

方案的 核心 在于 将目前一个数据库分割为两个数据库，一个当前交易库，一个历史数据查询库 。

---------------------------详细方案如下----------------------------------

建立两个mysql数据库，一个是当前业务库叫bussDB，一个是数据中心库叫datacenterDB。

 两个数据库如何运作： 

1、datacenterDB库和bussDB库表结构基本完全一致。bussDB库存放正在进行的交易，datacenterDB库存放当前正在进行的交易和所有历史交易。
2、业务后台管理系统和业务前台网站都直接连接bussDB库进行正常业务操作。
3、历史查询、分析统计系统连接datacenterDB库进行查询统计。
4、bussDB库按照适合oltp(交易型)的库进行数据库存储和建模的优化。
5、datacenterDB库按照适合olap(分析型、数据仓库)的库进行数据库存储和建模的优化，可以使用表分区和集群等技术。
6、每天晚上，自动定时通过ETL工具（数据库同步工具）将bussDB库中的信息自动同步到datacenterDB库中。
7、设置程序自动在交易完成后180天以后将交易信息清除，清除之后关于该交易的查询在datacenterDB库中查询。

为什么要分为两个数据库：

1、适合交易的数据库和适合分析的数据库建模有一定区别，bussDB是交易型，而datacenterDB是查询分析型。
2、bussDB库需要保证快速响应，不因为历史数据的不断增大而影响速度，因此需要定期清除数据和数据转存。
3、bussDB库是一个事务型的数据库，需要保证事务完整性，因此不适合做集群，应采取垂直扩展（高性能服务器）。
4、datacenterDB库是一个数据仓库的数据库，需要集群和水平扩展（廉价PC，做集群）。

  为什么要用关系型数据库而不用非关系型数据库。

1、在以上方式设计的bussDB库的状态下，对于增删改查操作，关系型数据库和非关系型数据库的性能开销基本一致，因为所有表的数据量都非常小，小于百万级，因为在千万级数据量以下，关系型数据库只要设置了索引，都是非常快的。
2、在性能方面一致的情况下，非关系数据库的缺点在于无法支持动态连接查询应用，即sql中的join操作，或者说是join效率不如关系型数据库高，另 外也不支持分组(group)和统计操作(count/sum/avg等)，在业务系统中存在大量的join操作，比如，报表打印、银行缴费对账、员工、 机构、角色、交易、科目、字典等复杂应用都涉及到大量关联，所以非关系型数据库在这些处理方面不如关系型数据库灵活和性能高，编写的代码可读性和健壮性也 较低。
3、关系型数据库的管理工具比如sqlyong，比非关系型数据库的管理工具更丰富，也更完善。对于数据库的DBA维护而言，关系型数据库的批量更新、导入、导出、备份、优化等方式和资料都丰富，对于开发人员的入门门槛，关系型数据库也比较低。
4、关系型数据库的发展历史和稳定性要超过非关系型数据库。
5、既然在性能一致的情况下为什么不用关系型数据库呢。
6、datacenterDB库就必须是用关系型数据库了，因为datacenterDB大量的统计应用都是基于sql中的统计函数的，比如查询交易业务 性别比例、学历分布等，都涉及到sql操作，比如，join,group by xxx,sum(),count(),avg()等，这些都是非关系型数据库不支持的。

 1.NoSQL与关系型数据库设计理念比较

3）能够适应现代网络对数据库高并发读写请求以及对海量数据的高速访问能力。

关系型和非关系型数据库——学习笔记

[导读]《连线》杂志对NoSQL的历史进行了追溯。介绍了最古老的NoSQL数据库之一CouchDB，创造者达卡茨的故事有助于帮助解释NoSQL运动的兴起，和这种数据库与竞争者的巨大的差异。

CouchDB的创造者达米安·卡茨（腾讯科技配图）

腾讯科技讯（童 云）北京时间12月6日消息，《连线》杂志网络版近日刊载文章，对NoSQL（非关系型数据库）的来源与历史进行了追溯。文章主要介绍了最古老的 NoSQL数据库之一CouchDB，这种数据库的创造者达米安·卡茨受到了在线协作平台Lotus Notes的启发，他的故事有助于帮助解释NoSQL运动的兴起，及为何这种数据库与以往的数据库存在如此巨大的差异。

以下是这篇文章的全文：

在追溯NoSQL运动的源头时，大多数互联网人士都会想到谷歌(微博)和亚马逊。

随 着自身网络服务日益取得巨大而成功的增长，谷歌和亚马逊需要新的方法来存储不断增加的服务器所带来的数量庞大的数据，于是两家公司都为此而创造了一个新的 软件平台——谷歌构建了BigTable平台，而亚马逊则构建了Dynamo平台。在这两家互联网巨头发布研究论文来描述其各自的数据存储平台以后，其他 许多公司也都寻求进行复制。

其结果是，一支NoSQL（非关系型数据库）“大军”就此产生，这种数据库是专为在数千台服务器之间运作而设计的。这些新时代的软件平台——包括Cassandra、HBase和Riak等——对数据库市场进行了改造，不仅有助于Facebook和Twitter等诸多互联网巨头的运作，同时也涵盖了更多的传统业务。

“如 果你看看市场上所有的NoSQL解决方案，那么就会发现每一种解决方案都能追溯至亚马逊Dynamo论文或谷歌BigTable论文。”云计算公司 Joyent首席技术官贾森·霍夫曼（Jason Hoffman）说道。“如果谷歌或是亚马逊没人曾写过一份学术报告（来描述NoSQL平台）的话，那么今天的世界将会是个什么样子呢？”

好 吧，如果真是那样，那么世界还将拥有另一种最古老的NoSQL数据库之一，那就是CouchDB。CouchDB的创造者达米安·卡茨（Damian Katz）并未受到谷歌、亚马逊或是其他任何网络巨头的启发，而是受到了在线协作平台Lotus Notes的启发，这个平台最初是在二十世纪七十年代和八十年代开发的。

虽然 Lotus Notes以身为一个电子邮件系统而闻名于世，但事实上它并非只是个电邮系统，同时还是构建依赖于数据库的应用的基础——换句话说，是有组织的信息集合。 通过使用Lotus Notes这个平台，企业能构建从开支申报应用到IT帮助桌面工具等所有东西。卡茨就是构建这种应用的人之一，他从1995年开始就为Lotus开发 Notes应用。他表示，即使是在那时，这个平台也已经展示出一些特性，而正是这些特性让今天的NoSQL数据库取得了如此之大的成功。

正 如其他NoSQL后继者一样，Lotus Notes也同样来自于关系数据库的“领地”。关系数据库是建立在关系数据库模型基础上的传统数据库，借助于集合代数等概念和方法来处理数据库中的数据。 “那是一个复杂的系统，能通过关系数据库让原本难以做到的事情变得简单。”卡茨说道。

从 很多方面来说，卡茨的故事都有助于帮助解释NoSQL运动的兴起——以及为何这种数据库与以往的数据库存在如此巨大的差异。虽然这场运动毫无疑问是取得了 成功，但NoSQL数据库的概念仍旧很难确定下来——“NoSQL意味着如此之多且各有不同的事情，要看你正在讨论什么而定。”谷歌杰出工程师安德鲁·菲 克斯（Andrew Fikes）最近曾这样对我们说道——在整个科技行业中，还有很多人尚未把握到这些新数据库的重要性。

“NoSQL” 其实该算是用词不当，因为NoSQL数据库并不是为了摒弃SQL（Structured Query Language，结构化查询语言，这是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统，同时也是数据库脚本文件的扩展 名）；更好的名称本来应该是“non-relational database”（非关系型数据库）。NoSQL数据库不使用为关系数据库提供支撑的整齐数据图表。

NoSQL数据库拥有两种基本特性：首先，这种数据库能在许多服务器之间延展——允许用户在必要时候扩大运算，甚至是在不同的地理位置之间也可以——其次，这种数据库能给用户带来按自己喜欢的方式架构数据的自由度，正是这第二个特性与Lotus Notes非常相似。

柏拉图式的理想

Notes 平台是受PLATO Notes的启发而创造出来的，后者是一个在伊利诺斯大学PLATO主机上运行的在线社区。PLATO Notes的创造者大卫·伍利（David R. Woolley）曾在1994年写道，这个项目始于1973年，当时还只是一个简单的报错系统。在最开始的时候，人们通过编辑一个文本文件的方式来报错， 但这种方式带来了一些问题。

“那样做根本没有安全性可言，想要确切地知道是谁写了一份报错文件是不可能做到的。”伍利说道。“大多数人都会报错时签上名字或至少是名字的首字母缩写，但没有什么东西能强制他们这样去做。有些时候，会有爱开玩笑的人觉得，删除整个文件是件很有意思的事情。”

因 此，当时年仅17岁的伍利就被分配到了一项任务，那就是创造一个更具结构性的系统来报错。他开发出来的工具允许用户将其报错报告输入到一个应用中去，该应 用会把报告保存为文本文件，并加上用户的姓名和提交日期。然后，支持部门的员工能分屏显示和查看这些文件，就像我们今天的电子邮件客户端一样：报错报告列 表在上面，报告文本在底下。

随后，所有这些信息会被保存为一个大的文本文件，而不是关系数据库。今天，我们将其称为“文件数据库”（document database）。

你可以把一个关系数据库看作一个庞大的电子表格，数据以图表、行和列的方式组织起来。如果你想要增加一个域，那么就新增一列，这一列会在表格的每一行中出现，从而让你的数据变得结构化和统一化，但管理许多无结构性的数据或是以多种方式构建结构的数据则要困难一些。

文件数据库更像是文件的集合，每一个“入口”都是一个文件，而且都能拥有自己的结构。如果你想要对一个“入口”添加一个域，那么这样做的同时不会对其他任何“入口”造成影响。

不久以后，PLATO开发者就添加了更多的Notes应用。到二十世纪七十年代末，他们拥有了一个电子邮件应用，一个一般用途留言板，以及网络游戏等，诸如此类。

在 1984年，雷·奥兹（Ray Ozzie）——一名Lotus开发者，在伊利诺斯大学上学时曾在PLATO工作过——离开了Louts，自己开创了一家名为Iris Associates的公司。随后，Lotus对这家公司进行了投资，双方签署了一项协议，内容是Lotus将拥有使用Iris旗舰产品的独家权利：一个 基于PLATO的企业用系统。

时至今日，许多人都认为Lotus Notes是一个过时的系统，应该像WordPerfect和Novell Netware那样被扔进同一个垃圾桶。但是，Notes为它之后的几乎所有类型的企业通信和协作应用铺平了道路，从微软Outlook电子邮件客户端到Jive Software等社交网络工具再到CouchDB数据库都是如此。

卡茨与CouchDB

1995年时，卡茨以夏季实习生的身份加入Lotus；大约就在同一时间，Lotus被IBM收购。卡茨在Lotus Notes顾问部门工作了一段时间，然后又回到这家公司，加入了Iris团队，当时Iris已被Lotus正式收购。

在 Iris，卡茨对Lotus Notes的精髓作出了改进。他重写了为Formula提供支持的引擎，这是用来开发Notes应用的脚本语言。卡茨表示，当时他远不能胜任这项工作，但 他同时认为自己天生就是要写代码的人。“每完成一个@function，我就跟打了一针毒品似的；我就像是个瘾君子，在不停地寻找下一个需要修补的地 方。”他后来在自己的博客中这样写道。

卡茨在2005年离开Lotus，加盟了一家名 为Koobie的创业公司；但在不久以后，他就启动了一项事业，目标是将Lotus Notes的思潮带入现代社会，这最终演变成了CouchDB。卡茨曾在一篇早期的博客中谈到这个项目，当时他写道：“Couch就是为网络而从头开始构 建的Lotus Notes。”

最初版本的CouchDB使用一种类似于 Formula的编程语言，但不久以后卡茨就带领这个项目走向了新的方向，从平台转变成了一个专用的数据库。“MySQL是其人气度达到顶峰的产物。”卡 茨说道。“当时如果你告诉人们说，你在开发某种类似于Lotus Notes的东西，那么就会让他们发出惊叹的声音。”

在 这条发展的道路上也存在不少坎坷。在2007年初，卡茨到了Sun Microsystems的MySQL团队工作，放弃了构建CouchDB的工作。但是，这个开源项目吸引了其他的开发者坚持不懈地为之努力，其中著名的 有詹·雷纳德（Jan Lehnardt）和诺亚·斯莱特（Noah Slater）等。斯莱特推出了JSON，在当时以文本文件来对数据进行结构化的新格式。在Sun休陪产假时，卡茨最后替换了整个CouchDB存储引 擎，用XML取代了JSON。在那时，卡茨认识到与使用Formula式的引擎相比，使用网络应用标准语言JavaScript可能是一种更好的想法。 “一旦我们推出JavaScript以后，”他说道，“这个项目就真正腾飞了起来。”

Couch的商业化

在 2007年，“复活”后的CouchDB受到了IBM的关注。不久以后，卡茨的名字回到了这家公司的工资单上，负责全职开发CouchDB。最为关键的 是，IBM同意将这个项目捐给非营利组织Apache基金会（Apache Foundation），这意味着IBM还不得不向开发者和CouchDB用户授权使用该公司的相关专利。这也就是说，IBM将无法起诉CouchDB侵 犯了与Lotus Notes相关的专利。

与此同时，NoSQL运动则全速展开。谷歌和亚马逊的论文令这种模式——此前已经有开源开发者倡导这种模式——变得流行起来，同时也为如何让其在现实世界中运作起来提供了某种深刻的理解。

一 家名为10gen的公司从2007年开始致力于开发一个名为MongoDB的NoSQL文件数据库，用BigTable作为参照模式。“那是完全独立 的，MongoDB、Couch和Lotus Notes两两之间没有太多的平行之处。”10gen创始人德怀特·梅里曼（Dwight Merriman）说道。一年以后，Facebook开放了Cassandra的源码，那是一个NoSQL数据库，整合了来自于Dynamo和 BigTable的概念。到2009年，随着CouchDB、Cassandra、MongoDB及其他NoSQL数据库加速发展，科技博客 ReadWriteWeb提出了一个问题，那就是关系型数据库是否已注定灭亡。

与此同时，当时供职于Last.fm的约翰·奥斯卡森（Johan Oskarsson）主持召开了首次NoSQL会议，无意中给这场原本定义松散的运动起了一个名字。

在 形势一片大好的大肆宣传浪潮中，卡茨、雷纳德和克里斯·安德森（J. Chris Anderson）创立了Couch.io，来对CouchDB进行商业化。到这个时候，一个由麻省理工学院物理学家组成的团队已经开创了一家名为 Cloudant的CouchDB公司，致力于开发自己版本的数据库，这个数据库名为BigCouch。虽然Couch.io（后来更名为 CouchOne）难以在现实世界中找到自己的位置，但很快就通过与另一家NoSQL公司Membase合并的方式找到了自己的立足点。

Membase 需要一名新的首席技术官，而CouchOne则需要一名首席执行官；Couch需要一种更好的方式来将规模扩大至大量的服务器，而这正是Membase所 能提供的；Membase需要一种更好的数据结构，而CouchDB能提供这种结构；很可能最重要的是，Membase拥有被卡茨认为是能够持续运营的商 业模式。在合并以后，新公司和新的数据库都被命名为Couchbase。

但是，此次合 并交易所带来的一个麻烦的结果是与Apache基金会的关系破裂。“我们真的曾付出过很多努力来让这种变化同步发生。”卡茨说道。“但到最后的结果是，与 Apache项目所能达到的前进速度相比，我们需要的速度要快得多。”最终的结局是，卡茨决定放弃他自己创立的项目，全心致力于Couchbase的发 展。在2012年1月份，也就是合并交易完成的一年以后，他在自己的博客上发表了一封措辞强硬的“告别信”，写道：“CouchDB的未来是什么？那就是 Couchbase。”

斯莱特此时已经成为Apache的CouchDB项目负责人，他用一条简短的Twitter消息对此作出了回应：“CouchDB的未来还是CouchDB。”

卡 茨承认，他原本可以处理得更加老练一些，但说到最后，这个故事证明了NoSQL已经变得多么活力四射。开发者仍在顽强地致力于开发CouchDB，哪怕没 有卡茨的参与也还是坚持不懈。Cloudant也仍旧致力于开发CouchDB，承诺将把BigCouch的代码还给这个项目。

Couchbase也正处在发布2.0版本数据库的边缘，此前该公司已经争取到了NTT DoCoMo和AOL等大客户。文件数据库的想法在开发者的脑海中已经生根，这不仅要感谢CouchDB及其诸多分支，同时也要感谢MongoDB所带来的人气。

与此同时，IBM则将放弃Lotus这个品牌名；Notes则将继续生存下去，至少现在是这样。在它的背后可能是最好的年华，但它为未来更多的美好时光搭好了舞台。

附：数据库大事年表

1961年：通用电气着手开发Integrated Data Store（IDS，集成数据存储）。通常来讲，IDS被认为是第一个“完全的”数据库。在今天的NoSQL数据库出现的数十年以前，IDS所做的就是如今NoSQL和大数据的工作。

1967：IBM 开发出Information Control System and Data Language/Interface（ICS/DL/I，信息控制系统与数据语言/界面），这是阿波罗（Apollo）项目的分级数据库。ICS随后变 成了Information Management System（IMS，信息管理系统），与IBM的System360主机整合到一起。

1970年：IBM研究员埃德加·科德（Edgar Codd）发表题为《大型共享数据库的关系模型》（A Relational Model of Data for Large Shared Data Banks）论文，建立了关系型数据库所使用的数学基础。

1973年：大卫·伍利（David R. Woolley）开发出了PLATO Notes，用一个文本文件作为报错系统的数据存储方式。PLATO Notes对随后Lotus Notes的出现形成了影响。

1974 年：IBM着手开发System R，将科德的关系型数据库模型变成了现实，首次使用了SQL（结构化查询语言），随后这个系统演变成了商业化产品IBM DB2。在科德研究的启发下，伯克利大学的学生迈克尔·斯通布雷克（Michael Stonebraker）和尤金·王（Eugene Wong）开始开发INGRES，它随后成为了PostGreSQL、Sybase及其他许多关系型数据库的基础。

1979年：第一个公开可用版本的Oracle数据库发布。

1984年：雷·奥兹（Ray Ozzie）成立Iris Associates，创造了一个受PLATO Notes启发的组合件系统。

1988年：由文件数据库提供支持的Lotus Agenda发布。

1989年：Lotus Notes发布。

1990年：Objectivity发布了期间对象数据库。

1991年：Key-value类型数据库Berkeley DB发布。

2003年：Live Journal开放最初版本Memcached的源码。

2005年：达米安·卡茨（Damien Katz）开放CouchDB源码。

2006年：Google发表BigTable论文。

2007年：亚马逊发表Dynamo论文。10gen开始编制MongoDB代码。Powerset开放BigTable clone克隆版Hbase的源码。

2008年：Facebook开放Cassandra源码。

2009年：科技博客ReadWriteWeb提出一个问题：“关系型数据库是否已注定灭亡？” Redis发布。首次NoSQL会议在旧金山召开。

2010年：Memcached项目的一些负责人与社交游戏公司Zynga开放Membase源码。

sql,nosql

标签：

原文地址：http://www.cnblogs.com/timdes/p/4784061.html