什么是非关系型数据库，如何定义

随着互联网web20网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web20网站，特别是超大规模和高并发的SNS类型的web20纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

1、High performance——对数据库高并发读写的需求

Web20网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

2、Huge Storage——对海量数据的高效率存储和访问的需求

类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了25亿条用户动态，对于关系数据库来说，在一张25亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability——对数据库的高可扩展性和高可用性的需求

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

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web20网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1 数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2 数据库的写实时性和读实时性需求

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

3、对复杂的SQL查询，特别是多表关联查询的需求

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

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：

Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，

这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，我(robbin)也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。

mysql

最常用的主从复制就是读写分离的功能

数据有修改，会通过网络将执行的内容传输到从库，追加到从库的重做日志（replay-bin），然后再通过重做日志还原主库的 *** 作以达到同步的效果

---------------------------------------

oracle

常用的读写分离方案有DG（备库可读）

*** 作写入archivelog，再通过网络传输到备库，备库再用archivelog还原数据，已到达同步的目的。

数据库（Database）是按照数据结构来组织，储存和管理数据的仓库。 数据库通常分为层次式数据库，网络式数据库和关系型数据库三种。而不同的数据结构是按照不同的数据结构来联系和组织的。如今常见的数据库模型分为关系型数据库（SQL）和非关系型数据库（NoSQL)两种

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

关系就是二维表，并且有如下性质：

常见的关系型数据库：

关系型数据库的优缺点：

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

优点：容易理解，使用方便，易于维护

缺点：

1-数据读写必须经过sql解析，大量数据，并发下读写性能不足。硬盘I/O是一个很大的瓶颈

2-具有固定的表结构，因此扩展困难。

3-多表的关联查询导致性能欠佳。

NoSQL数据储存不需要固定的表结构，通常也不存在连接 *** 作。在大数据存取上具备关系型数据库无法比拟的性能优势

1-搜索键值存取数据库（key-value）：可以通过key来添加，查询或者删除数据库，因为使用了key主键访问，所以获得很高的性能及扩展性。对于IT系统来说优势在于简单，易部署，高并发。

2-列存储数据库：将数据储存在列族中，一个列族储存经常被一起查询的相关数据，比如我们经常查询人类的名字和年龄，而非薪资，这种情况下年龄和姓名放在一个列族中，薪资会放到另外一个列族中。

3-面向文档数据库：可以看做键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。面向文档数据库会将数据以文档形式存储。

在数据库中插入数据，实际上不是实时写数据到数据文件的，但要实时写事务日志文件到日志文件中，日志文件中的内容，你可以理解为就是sql命令的具体 *** 作，对事务型数据库，批量插入大量数据，最好是把事务日志暂停了，然后，在做 *** 作。

那样就会快很多。

你不在在生产库的生产过程中做这种 *** 作。

在生产过程中，你只能分时间段，分批量，用你的命令导入数据。

当然需要用数据库，这个系统是管理图书馆的，你肯定要把书籍的信息全部存到数据库中如果你是自己写着玩的话用ACCESS数据库就行了，有很多链接数据库的方法比如在windows平台用ODBC,ADO,等等都行

以上就是关于什么是非关系型数据库，如何定义全部的内容，包括:什么是非关系型数据库，如何定义、数据库的读写分离数据库是怎么同步的、何为数据库等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！