sql,nosql

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、DB二、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也不合适。

 

 

非关系型数据库MongoDB
随着如今分布式数据库的崛起,部分的项目的后台已经渐渐的时候这种非关系型的数据库来设计了,那么这种数据库有什么样的有点呢?
(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能够支持复杂的数据结构，并且带有强大的数据查询功能，所以很是受到欢迎。

 

 自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。

 两个数据库如何运做： 

一、datacenterDB库和bussDB库表结构基本彻底一致。bussDB库存放正在进行的交易，datacenterDB库存放当前正在进行的交易和全部历史交易。
二、业务后台管理系统和业务前台网站都直接链接bussDB库进行正常业务操做。
三、历史查询、分析统计系统链接datacenterDB库进行查询统计。
四、bussDB库按照适合oltp(交易型)的库进行数据库存储和建模的优化。
五、datacenterDB库按照适合olap(分析型、数据仓库)的库进行数据库存储和建模的优化，能够使用表分区和集群等技术。
六、天天晚上，自动定时经过ETL工具（数据库同步工具）将bussDB库中的信息自动同步到datacenterDB库中。
七、设置程序自动在交易完成后180天之后将交易信息清除，清除以后关于该交易的查询在datacenterDB库中查询。

为何要分为两个数据库：

一、适合交易的数据库和适合分析的数据库建模有必定区别，bussDB是交易型，而datacenterDB是查询分析型。
二、bussDB库须要保证快速响应，不由于历史数据的不断增大而影响速度，所以须要按期清除数据和数据转存。
三、bussDB库是一个事务型的数据库，须要保证事务完整性，所以不适合作集群，应采起垂直扩展（高性能服务器）。
四、datacenterDB库是一个数据仓库的数据库，须要集群和水平扩展（廉价PC，作集群）。

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

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

 

 

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

 关系型数据库中的表都是存储一些格式化的数据结构，每一个元组字段的组成都同样，即便不是每一个元组都须要全部的字段，但数据库会为每一个元组分配全部的字段，这样的结构能够便于表与表之间进行链接等操做，但从另外一个角度来讲他也是关系型数据库性能瓶颈的一个因素。

非关系型数据库以键值对存储，他的结构不固定，每个元组能够有不同的字段，每一个元组能够根据须要增长一些本身的键值对，这样就不会局限于固定的结构可 以减小一些时间和空间的开销。非关系型数据库的要点是非关系的、分布式的、水平可扩展的，具备模式自由、支持简易复制、简单的API、最终一致性、大容量 数据等特性。除此以外还有文档型、列存储型、图形数据库、XML数据库等。

 

2.优缺点：

相对关系型数据库，NoSQL具备如下优势：

1）数据存储非结构化。非关系型数据库以键值对存储，它的结构不固定，每个元组能够有不同的字段，每一个元组能够根据须要增长本身的键值对，这样能够构造不固定的结构，从而减小时间和空间的开销。 2）可以运行在便宜的PC服务器集群上，能够经过物理性PC集群数据库服务器节点的扩充实现数据库水平拓展，使数据库拥有良好的横向和纵向扩展能力。

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

 

 

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

关系数据库（英语：Relational database），是建立在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。现实世界中的各类实体以及实体之间的各类联 系均用关系模型来表示。关系模型是由埃德加·科德于1970年首先提出的，并配合“科德十二定律”。现现在虽然对此模型有一些批评意见，但它仍是数据存储 的传统标准。标准数据查询语言SQL就是一种基于关系数据库的语言，这种语言执行对关系数据库中数据的检索和操做。
关系模型由关系数据结构、关系操做集合、关系完整性约束三部分组成。
实体关系模型:实体关系模型（Entity-Relationship Model），简称E-R Model，是陈品山（Peter P.S Chen）博士于1976年提出的一套数据库的设计工具，他运用真实世界中事物与关系的观念，来解释数据库中的抽象的数据架构。实体关系模型利用图形的方 式（实体-关系图（Entity-Relationship Diagram））来表示数据库的概念设计，有助于设计过程当中的构思及沟通讨论。
关系操做:
1）数据查询:
   A.选择
   B.投影
   C.链接
   D.并
   E.交
   F.差
   G.除 2）数据操做:
   A.增长
   B.删除
   C.修改
   E.查询
完整性约束包括：
   1）实体完整性
   2）参照完整性

   3）用户定义完整性

关系型数据库的特色：
   1）关系型数据库的最大特色就是事物的一致性，为了维护一致性所付出的巨大代价就是读写性能比较差
   2）具备固定的表结构，扩展性差
   3）数据的持久化须要关系型数据库
非关系型数据库：NoSQL，有时也称做Not Only SQL的缩写，NoSQL不使用SQL做为查询语言。其数据存储能够不须要固定的表格模式，也常常会避免使用SQL的JOIN操做，通常有水平可扩展性的 特征。NoSQL的实现具备二个特征：使用硬盘，或者把随机存储器做存储载体。 主要分为一下几类：    1）面向高性能并发读写的Key-Value数据库：Key-Value数据库的主要特色就是具备极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的表明。    2）面向海量数据访问的面向文档数据库：这类数据库的特色是，能够在海量的数据中快速的查询数据。典型表明为MongoDB以及CouchDB。

   3）面向可扩展性的分布式数据库：这类数据库想解决的问题就是传统数据库在可扩展性上的缺陷，这类数据库能够适应数据量的增长以及数据结构的变 化，Google Appengine的Big Table就是这类的典型表明，而且，BigTable特别适用于Map Reduce处理。

参考：

http://zh.wikipedia.org/wiki/NoSQL

http://zh.wikipedia.org/wiki/%E9%97%9C%E8%81%AF%E5%BC%8F%E8%B3%87%E6%96%99%E5%BA%AB

http://www.sigma.me/2011/06/11/intro-to-nosql.html

 

 

 

 

非关系型数据库NoSQL的崛起

2012年12月06日15:45腾讯科技[微博]童云我要评论(0)

字号： T|T

[导读]《连线》杂志对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源码。