关系数据库与非关系型数据库

关系数据库、非关系型数据库。

1、关系数据库

特点：数据集中控制；减少数据冗余等。

适用范围：对于结构化数据的处理更合适，如学生成绩、地址等，这样的数据一般情况下需要使用结构化的查询。

2、非关系数据库

特点：易扩展；大数据量，高性能；灵活的数据模型等。

使用范围：据模型比较简单；需要灵活性更强的IT系统；对数据库性能要求较高。

扩展资料：

非关系数据库的分类：

1、列存储数据库

这部分数据库通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。这些列是由列家族来安排的。如：Cassandra，HBase，Riak。

2、文档型数据库

文档型数据库的灵感是来自于LotusNotes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档，半结构化的文档以特定的格式存储，比如JSON。文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB，MongoDb国内也有文档型数据库SequoiaDB，已经开源。

非关系型数据库（NoSQL）是一种不依赖于关系模型的数据库，它提供了一种更灵活、可扩展的数据存储方式。非关系型数据库主要包括以下几类：

列存储型数据库：这种数据库通常把数据存储在一列中，并支持快速的列计算和分布式计算。它适用于处理海量的结构化数据，比如日志、传感器数据等。

文档型数据库：这种数据库通常把数据存储在文档中，并支持对数据的灵活查询和复杂的聚

随着互联网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)也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。

谈到非关系型数据库设计的难点，朱海峰说：“我们可以从一些场景来看这个问题。一般数据库设计人员以前更多的是处理传统的业务应用，那么对于非关系型数据，可能是新业务的引入，也可能是一些新需求的提出，要求我们的IT系统能够支持更多数据类型的应用，从整个系统架构角度来看，可能更多的是要求系统架构师能够更好的适应和理解新业务的特点，那么相应的数据库开发人员所面临的新挑战，就是如何去支持系统架构师、程序员去实现新业务的需求。 比如说处理媒体数据类型、文档数据类型，以往关系数据库在很多场景中也能够提供这种支持，但是是在媒体数据类型相对比较少的情况下，那时存储成本也很高，信息处理速度也不那么快，这也就意味着储量的数据量并不那么大。然而IT发展到现在变化非常快，在我们业务处理过程中大量引入了流媒体、PDF、等等数据信息的处理，这就要求数据库或者数据库平台也能支持这样的处理性能。 数据库开发设计人员首先一个方面，他要能很好的理解业务需求，定位这种应用采取哪种数据类型才是比较适合它的业务特点，当然你可能会说我要支持所有的数据类型，但是实际上从系统架构角度来说，某些业务场合可能会有最佳适合这种业务类型，这是设计者和开发人员所要面临的问题。 那么从另一个方面，数据库的角度来看，开发和设计人员要更好的理解我们的数据平台，以及相关产品，并能够充分的理解其相应的新的功能特性，是怎样和它的业务结合在一起的，这也是一个最大的挑战，实际上功能都是有的，而且在一定程度是强大的，但是我们的开发设计人员怎么理解和应用这些新功能，就需要一定的时间去熟悉，熟悉完以后把这些新的功能引入到自己的系统中进行应用，更好的为应用系统服务。这两方面的结合才有可能成功。

关系型数据库的局限性有哪些

首先是不适合数据量大(PB级别)而增删改查又很简单的应用例如社交网络很多用的是NoSQL,BigTable这类非关系型数据库其次应该是不适合数据仓储,那需要进行反规范化(denormalize),即把拆得很细的,符合各种范式的表重新归并成大表

不过一般关系数据库还是使用最普遍的

我谈一点个人的见解吧。

记得之前看过一篇帖子，讲的是可能我们所说的非关系型数据库是我们翻译错了。年代久远，找不到原贴了，但是大概说的是非关系型数据库的名字叫Not Only Sql，我们简化过来就叫NoSql，所以看着就像是非关系型数据库，然后我们再顾名思义，就是数据之间没有关系的数据库，这个理解我不赞同。

如果从名字上来看，我觉得可以叫做不仅仅是关系型的数据库，更为恰当，当然，我们也不能否认，这类数据库确实在数据关联之间更为自由，约束条件更少，（甚至没有），但是这并不能阻挡它的发展，以“键值对”为基础的NoSql在性能上可以说是碾压对手，大家都知道NoSql不需要经过Sql层的解析的，相比关系型数据库数据之间的高耦合性，这让它具有更高的平行扩展性，当然这方面你需要去看一下相关的知识，高耦合低聚合等等概念需要理解一下。

大概就是我的理解了吧，关系型数据库就不用说了吧，我们常常用到，现在的主流数据库我们也都在接触，大到Oracle，小到Sqlite，相信你也比较熟悉，这些数据库都是支持事务和相当复杂的查询的，往往我们一条查询语句可以上百行（一子句一行）甚至上千行，这些都是NoSql做不到的，（注意我说的是一条查询语句），事务这个概念我也不多提了，这个网上就太多了，如果涉及到高并发之类的，可以多线程+事务，效率更高一些。

最后再补两句，好像现在的NoSql数据库的发展趋势很微妙，描述在往一些关系型数据库的基础模型延伸。

以上就是关于关系数据库与非关系型数据库全部的内容，包括:关系数据库与非关系型数据库、非关系型数据库主要包括几类各有什么特点、关系型数据库的局限性有哪些难以满足高并发读写的需求等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！