NoSQL非关系型数据库 笔记
2014-06-23 11:27
274 查看
首先,老规矩,出处:http://www.sigma.me/2011/06/11/intro-to-nosql.html
在计算机科学中,非关系型数据库(NoSQL)是一个和之前的关系型数据库(RDBM)有很大不同的另一类数据结构化存储管理系统。非关系型数据库通常没有固定的表结构,并且避免使用join操作。和关系型数据库相比,非关系型数据库特别适合以SNS为代表web
2.0应用,这些应用需要极高速的并发读写操作,而对数值一致性要求却不甚高。
关系型数据库最大特点就是事务的一致性:传统的关系型数据库读写操作都是事务的,具有ACID(原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability)的特点,C就是一致性(Consistency),这个特点是关系型数据库的灵魂(其他三个AID都是为其服务的),这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中,如典型的银行系统。
但是,在网页应用中,尤其是SNS应用中,一致性却不是显得那么重要,用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的,或者说,两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的,因此,关系型数据库的最大特点在这里已经无用武之地,起码不是那么重要了。
相反的,关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差,而像微博,facebook这类SNS的应用,对并发读写能力要求极高,关系型数据库已经无法应付(在读方面,传统上为了克服关系型数据库缺陷,提高性能,都是增加一级memcache来静态化网页,而在SNS中,变化太快,memcache已经无能为力),因此,必须用新的一种数据结构化存储来来代替关系数据库。
关系数据库的另一个特点就是其具有固定的表结构,因此,其扩展性极差,而在SNS中,系统的升级,功能的增加,往往意味着数据结构巨大改动,这一点关系型数据库也难以应付,需要新的结构化数据存储。
于是,非关系数据库(NoSQL)应运而生,由于不可能用一种数据结构化存储方式应付所有的新的需求,因此,非关系型数据库严格上不是一种数据库,应该是一种数据结构化存储方法的集合。
必须强调的是,数据的持久存储,尤其是海量数据的持久存储,还是需要关系数据库这员老将。
由于非关系型数据库本身天然的多样性,以及出现的时间较短,因此,不像关系型数据库,有几种数据库能够一统江山,非关系型数据库的非常多,并且大部分都是开源的,这里列出一些:Redis,Tokyo
Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable,Riak,Tin,
Flare,Lightcloud,KiokuDB,Scalaris,Kai,ThruDB…
这些数据库中,其实实现大部分都比较简单,除了一些共性外,很大一部分都是针对某些特定的应用需求出现的,因此,对于该类应用,具有极高的性能。依据结构化方法以及应用场合的不同,主要分为以下几类:
面向高性能并发读写的Key-Value数据库:Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo
Cabinet,Flare就是这类的代表。
面向海量数据访问的面向文档数据库(Document
store):这类数据库的特点是,可以在海量的数据中快速的查询数据。典型代表为MongoDB以及CouchDB。
面向可扩展性的分布式数据库(Object
Store):这类数据库想解决的问题就是传统数据库在可扩展性上的缺陷,这类数据库可以适应数据量的增加以及数据结构的变化,Google
Appengine的Big Table就是这类的典型代表,并且,BigTable特别适用于Map
Reduce处理。
这里只对这几类数据库简要的介绍,需要详情可以看:http://en.wikipedia.org/wiki/NoSQL
在计算机科学中,非关系型数据库(NoSQL)是一个和之前的关系型数据库(RDBM)有很大不同的另一类数据结构化存储管理系统。非关系型数据库通常没有固定的表结构,并且避免使用join操作。和关系型数据库相比,非关系型数据库特别适合以SNS为代表web
2.0应用,这些应用需要极高速的并发读写操作,而对数值一致性要求却不甚高。
关系型数据库的特点
关系型数据库最大特点就是事务的一致性:传统的关系型数据库读写操作都是事务的,具有ACID(原子性Atomicity、一致性Consistency、隔离性Isolation、持久性Durability)的特点,C就是一致性(Consistency),这个特点是关系型数据库的灵魂(其他三个AID都是为其服务的),这个特性使得关系型数据库可以用于几乎所有对一致性有要求的系统中,如典型的银行系统。但是,在网页应用中,尤其是SNS应用中,一致性却不是显得那么重要,用户A看到的内容和用户B看到同一用户C内容更新不一致是可以容忍的,或者说,两个人看到同一好友的数据更新的时间差那么几秒是可以容忍的,因此,关系型数据库的最大特点在这里已经无用武之地,起码不是那么重要了。
相反的,关系型数据库为了维护一致性所付出的巨大代价就是其读写性能比较差,而像微博,facebook这类SNS的应用,对并发读写能力要求极高,关系型数据库已经无法应付(在读方面,传统上为了克服关系型数据库缺陷,提高性能,都是增加一级memcache来静态化网页,而在SNS中,变化太快,memcache已经无能为力),因此,必须用新的一种数据结构化存储来来代替关系数据库。
关系数据库的另一个特点就是其具有固定的表结构,因此,其扩展性极差,而在SNS中,系统的升级,功能的增加,往往意味着数据结构巨大改动,这一点关系型数据库也难以应付,需要新的结构化数据存储。
于是,非关系数据库(NoSQL)应运而生,由于不可能用一种数据结构化存储方式应付所有的新的需求,因此,非关系型数据库严格上不是一种数据库,应该是一种数据结构化存储方法的集合。
必须强调的是,数据的持久存储,尤其是海量数据的持久存储,还是需要关系数据库这员老将。
非关系型数据库分类
Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable,Riak,Tin,
Flare,Lightcloud,KiokuDB,Scalaris,Kai,ThruDB…
这些数据库中,其实实现大部分都比较简单,除了一些共性外,很大一部分都是针对某些特定的应用需求出现的,因此,对于该类应用,具有极高的性能。依据结构化方法以及应用场合的不同,主要分为以下几类:
面向高性能并发读写的Key-Value数据库:Key-Value数据库的主要特点就是具有极高的并发读写性能,Redis,Tokyo
Cabinet,Flare就是这类的代表。
面向海量数据访问的面向文档数据库(Document
store):这类数据库的特点是,可以在海量的数据中快速的查询数据。典型代表为MongoDB以及CouchDB。
面向可扩展性的分布式数据库(Object
Store):这类数据库想解决的问题就是传统数据库在可扩展性上的缺陷,这类数据库可以适应数据量的增加以及数据结构的变化,Google
Appengine的Big Table就是这类的典型代表,并且,BigTable特别适用于Map
Reduce处理。
这里只对这几类数据库简要的介绍,需要详情可以看:http://en.wikipedia.org/wiki/NoSQL
相关文章推荐
- 非关系型数据库“NoSql”之Apache Cassandra
- 数据库nosql 笔记
- 执行数据库命令(Command对象)——ADO.NET学习&应用笔记之三
- 非关系型数据库NoSql之mongo
- NoSQL数据库探讨 -- 非关系型数据库
- JAVA学习笔记4——JDBC方式连接数据库
- NoSQL数据库探讨 -- 非关系型数据库
- NoSQL非关系型数据库
- 关注'非关系型数据库'
- 为什么要用非关系型数据库nosql
- NoSQL数据库探讨 -- 非关系型数据库
- NoSQL 非关系型数据库
- NoSQL数据库探讨 -- 非关系型数据库
- 数据库技术发展与非关系型数据库NoSQL
- 高性能NOSQL数据库redis结合谷歌开源tcmalloc库的安装笔记
- facebookde 的 NoSQL数据库cassandra的配置与调用(java&&c#)
- NoSQL数据库探讨 -- 非关系型数据库
- .net 通用数据库概念
- NoSQL数据库之MongoDB学习笔记
- SQL Server 重建索引|索引重组|索引的碎片检查 (MSSQL个人笔记之数据库优化之路 六<SQL2005以上>)