非关系型数据库
非关系型数据库,也称为NoSQL数据库,区别于传统的关系型(SQL)数据库。目前,对NoSQL没有确切的定义,较为全面的解释是“NoSQL主要是面向Web应用的下一代数据库,应该具备这几个特点:非关系型的、分布式的、开源的和可以线性扩展的。”这类数据库最初的目的在于提供现代网站可扩展的数据库解决方案。这种类型的数据库具有以下特点:数据模式不定、数据多处备份、简单的编程API以及数据的最终一致性等。
1、非关系型数据库简介
非关系型数据库,也称为NoSQL数据库,区别于传统的关系型(SQL)数据库。目前,对NoSQL没有确切的定义,较为全面的解释是“NoSQL主要是面向Web应用的下一代数据库,应该具备这几个特点:非关系型的、分布式的、开源的和可以线性扩展的。”这类数据库最初的目的在于提供现代网站可扩展的数据库解决方案。这种类型的数据库具有以下特点:数据模式不定、数据多处备份、简单的编程API以及数据的最终一致性等。
非关系型数据库提出另一种理念,例如,以键值对存储,且结构不固定,每一个元组可以有不一样的字段,每个元组可以根据需要增加一些自己的键值对,这样就不会局限于固定的结构,可以减少一些时间和空间的开销。使用这种方式,用户可以根据需要去添加自己需要的字段,这样,为了获取用户的不同信息,不需要像关系型数据库中,要对多表进行关联查询。仅需要根据id取出相应的value就可以完成查询。
NoSQL是一个云计算背景下蓬勃发展的分布式、非关系型数据库系统,支持半结构化、结构化数据的高并发读写,存储键值、列族、文档、图等多种数据类型。NoSQL具有良好的可伸缩性和可扩展性,能够有效利用云计算所提供的海量数据存储管理、分布式并行计算能力。NoSQL遵循CAP定理(即一致性、可用性、网络分割),提供比ACID(即原子性、一致性、隔离性和持久性)更松散的BASE(即基本可用、软状态、最终一致性)并发事务模型,实现数据库在特定领域应用。
目前,Google、Microsoft等大型云服务商都结合NoSQL技术,实现了海量栅格数据云存储并提供了自有的地图服务产品。BigTable是Google早期提出的一种高性能、高可用的分布式列族数据库管理系统,采用简单灵活、模式*和结构疏松的数据模型,并通过结合分布式文件系统GFS和并行计算框架MapReduce,实现了PB级别栅格数据的云存储、管理。
2、非关系型数据库发展
NoSQL的发展最早可以追溯到1991年BerkeleyDB第一版的发布。BerkeleyDB是一个Key/Value(键/值)类型的Hush数据库。这种类型的数据库适用于数据类型相对简单,但需要极高的插入和读取速度的嵌入式场合。
NoSQL一词首先是CarloStrozzi在1998年提出来的,指的是他开发的一个没有SQL功能,轻量级的,开源的关系型数据库。这个定义跟我们现在对NoSQL的定义有很大的区别,它确确实实字如其名,指的就是“没有SQL”的数据库。但是NoSQL的发展慢慢偏离了初衷,我们要的不是“nosql”,而是“norelational”,也就是我们现在常说的非关系型数据库了。
2009年初,JohanOskarsson举办了一场关于开源分布式数据库的讨论,EricEvans在这次讨论中再次提出了NoSQL一词,用于指代那些非关系型的,分布式的,且一般不保证遵循ACID原则的数据存储系统。EricEvans使用NoSQL这个词,并不是因为字面上的“没有SQL”的意思,他只是觉得很多经典的关系型数据库名字都叫“**SQL”,所以为了表示跟这些关系型数据库在定位上的截然不同,就是用了“NoSQL”一词。
NoSQL得到真正的快速发展开始于2007年,从2007年到现在,先后出现了十多种比较流行的NoSQL产品,从2009年开始,国内的NoSQL领域也开始活跃起来,豆瓣的BeansDB,人人网的Nuclear开源NoSQL产品以及盛大创新院的TCDatabase纷纷发布。
NoSQL发展到今天,已经覆盖了互联网的众多领域,像我们熟知的新浪微博、淘宝、优酷等等,都是典型的NoSQL产品。
NoSQL能够得到快速的发展,其主要背景在于Web2.0技术在网络中的广泛应用。在Web2.0环境下,用户对于数据库高并发读写的需求、对海量数据的高效率存储和访问的需求、对数据库的高可拓展性和高可用性的需求等,都对传统关系型数据库带来很大的困难。
3、非关系型数据库特点
可以处理超大量的数据
NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般MySQL使用QueryCache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了。
易扩展
NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。
击碎了性能瓶颈
NoSQL的支持者称,通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间,执行速度变得更快。
没有过多的操作
NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。
支持者来源于社区
因为NoSQL项目都是开源的,因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样,不得不从社区中寻求支持。
4、NoSQL数据库的类型
NoSQL可以大体上分为4个种类:Key-value、Document-Oriented、Column-FamilyDatabases以及Graph-OrientedDatabases。下面就一览这些类型的特性:
键值(Key-Value)数据库
键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据,鉴于使用主键访问,所以会获得不错的性能及扩展性。
产品:Riak、Redis、Memcached、Amazon’sDynamo、ProjectVoldemort
有谁在使用:GitHub(Riak)、BestBuy(Riak)、Twitter(Redis和Memcached)、*(Redis)、Instagram(Redis)、Youtube(Memcached)、Wikipedia(Memcached)
适用的场景
储存用户信息,比如会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩,这种情景下键值数据库是个很好的选择。
不适用场景
- 取代通过键查询,而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。
- 需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。
- 事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。
面向文档(Document-Oriented)数据库
面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元,是一系列数据项的集合。每个数据项都有一个名称与对应的值,值既可以是简单的数据类型,如字符串、数字和日期等;也可以是复杂的类型,如有序列表和关联对象。数据存储的最小单位是文档,同一个表中存储的文档属性可以是不同的,数据可以使用XML、JSON或者JSONB等多种形式存储。
产品:MongoDB、CouchDB、RavenDB
有谁在使用:SAP(MongoDB)、Codecademy(MongoDB)、Foursquare(MongoDB)、NBCNews(RavenDB)
适用的场景
- 日志。企业环境下,每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式,所以我们可以使用它储存不同的信息。
- 分析。鉴于它的弱模式结构,不改变模式下就可以储存不同的度量方法及添加新的度量。
不适用场景
在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务,如果对这方面有需求则不应该选用这个解决方案。
列存储(WideColumnStore)数据库
列存储数据库将数据储存在列族(columnfamily)中,一个列族存储经常被一起查询的相关数据。举个例子,如果我们有一个Person类,我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下,姓名和年龄就会被放入一个列族中,而薪资则在另一个列族中。
产品:Cassandra、HBase
有谁在使用:Ebay(Cassandra)、Instagram(Cassandra)、NASA(Cassandra)、Twitter(CassandraandHBase)、Facebook(HBase)、Yahoo!(HBase)
适用的场景
- 日志。因为我们可以将数据储存在不同的列中,每个应用程序可以将信息写入自己的列族中。
- 博客平台。我们储存每个信息到不同的列族中。举个例子,标签可以储存在一个,类别可以在一个,而文章则在另一个。
不适用场景
- 如果我们需要ACID事务。Vassandra就不支持事务。
- 原型设计。如果我们分析Cassandra的数据结构,我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初,我们根本不可能去预测它的查询方式,而一旦查询方式改变,我们就必须重新设计列族。
图(Graph-Oriented)数据库
图数据库允许我们将数据以图的方式储存。实体会被作为顶点,而实体之间的关系则会被作为边。比如我们有三个实体,SteveJobs、Apple和Next,则会有两个“Foundedby”的边将Apple和Next连接到SteveJobs。
产品:Neo4J、InfiniteGraph、OrientDB
有谁在使用:Adobe(Neo4J)、Cisco(Neo4J)、T-Mobile(Neo4J)
适用的场景
- 在一些关系性强的数据中
- 推荐引擎。如果我们将数据以图的形式表现,那么将会非常有益于推荐的制定
不适用场景
不适合的数据模型。图数据库的适用范围很小,因为很少有操作涉及到整个图。
5、优秀NoSQL数据库介绍
Casssandra
CasssandraLogo
Cassandra最初由Facebook开发,后来成了Apache开源项目,它是一个网络社交云计算方面理想的数据库。它集成了其他的流行工具如Solr,现在已经成为一个完全成熟的大型数据存储工具。Cassandra是一个混合型的非关系的数据库,类似于Google的BigTable。其主要功能比Dynomite(分布式的Key-Value存储系统)更丰富,但支持度却不如文档存储MongoDB。Cassandra的主要特点就是它不是一个数据库,而是由一堆数据库节点共同构成的一个分布式网络服务,对Cassandra的一个写操作,会被复制到其他节点上去,而对Cassandra的读操作,也会被路由到某个节点上面去读取。在最近的一次测试中,Netflix建立了一个288个节点的集群。
Lucene/Solr
Lucene/SolrLogo
Lucene是Apache软件基金会4jakarta项目组的一个子项目,这是一个开放源代码的全文检索引擎工具包,就是说它不是一个完整的全文检索引擎,而是一个全文检索引擎的架构。不过大多数人并不认同Lucene是一个数据库,因为大多数人只是用它来检索大量的文本块,不过它的确采用了与其他NoSQL数据存储相似的模型。如果说查询并不是仅仅局限于精确的匹配,而是寻找出那些出现在块中的字或者字段的话,毫无疑问,Lucene/Solr是最好的查询方式。
Riak
RiakLogo
Riak是由技术公司basho开发的一个类似Dynamo的分布式Key-Value系统。其以分布式,水平扩展性,高容错性等特点著称。从事Riak工作最有趣的部分是可以使用JavaScript或者Erlang来做Map/Reduce查询,它们会查询每个节点,收集结果,而且可以重复,如果需要使用的结果进行重新进行搜寻的话。该系统还为类似于Solr的搜索提供全文索引,同时还提供一个控制面板,可以查看集群的信息。
CouchDB
CouchDBLogo
CouchDB是用Erlang开发的面向文档的数据库系统,不过它不是一个传统的关系数据库,而是面向文档的数据库,其数据存储方式有点类似lucene的index文件格式,CouchDB最大的意义在于它是一个面向web应用的新一代存储系统。作为一个分布式的数据库,CouchDB可以把存储系统分布到n台物理的节点上面,并且很好的协调和同步节点之间的数据读写一致性。CouchDB支持RESTAPI,可以让用户使用JavaScript来操作CouchDB数据库,也可以用JavaScript编写查询语句,可以想像一下,用AJAX技术结合CouchDB开发出来的CMS系统会是多么的简单和方便。
CouchDB还有一个更加商业化的“表亲”——Couchbase,不过它提供缓存功能,更好的分片,增量查询,更好的索引和一些其他的功能。其实Couchbase与CouchDB也是紧密相关的,Couchbase产品包含了CouchDB的一个副本。
Neo4J
Neo4JLogo
大多数的NoSQL数据库只是存储键和值的一个灵活的捆绑。不过Neo4J的存储的是对象之间的关系,或者说这种结构就是数学中的“图”。Neo4J是一个面向网络(“图”)的数据库,也就是说,它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎,但是它将结构化数据存储在网络上而不是表中,当然也可以把Neo4J看作是一个高性能的图引擎,该引擎具有成熟和健壮的数据库的所有特性。该工具包括很多有关搜索和分析的关系的算法,它能够帮助寻找谁是我的朋友,或者寻找朋友的朋友。这些“图的遍历”算法,可以节省很多指针查询的麻烦。
Oracle的NoSQL
OracleLogo
也许是NoSQL运动太红火的原因,Oracle决定开发一款产品,将键/值对拆分在整个节点集上,这样的优势在于提供了一个灵活的事务保护措施,进而可以确保从数据在节点上等待存储开始到通过网络被成功备份结束,都尽在掌握之中。
Oracle的NoSQLDatabase,是在10月4号的甲骨文全球大全上发布的BigDataAppliance的其中一个组件,BigDataAppliance是一个集成了Hadoop、NoSQLDatabase、Oracle数据库Hadoop适配器、Oracle数据库Hadoop装载器及R语言的系统。
MongoDB
MongoDBLogo
MongoDB是一个基于分布式文件存储的数据库,介于关系数据库和非关系数据库之间,是非关系数据库当中功能最丰富,最像关系数据库的。MongoDB最大的特点是他支持的查询语言非常强大,其语法有点类似于面向对象的查询语言,几乎可以实现类似关系数据库单表查询的绝大部分功能,而且还支持对数据建立索引。MongoDB支持RUBY,PYTHON,JAVA,C++,PHP,C#等多种语言。
MongoDB是高性能开源文档数据库,也是目前最受关注的NoSQL技术之一,以敏捷、可扩展和对企业应用友好(支持事务,一致性和数据完整性保证,有大企业应用案例)而著称。有人甚至认为LAMP中的M应该用MongoDB取代MySQL,其火热程度可见一斑。使用MongoDB的公司包括Foursquare,Craiglist,迪士尼,SAP,Intuit,EA等,国内淘宝、大众点评、视觉中国等公司有应用。(最新版MongoDB2.2下载)
Hadoop的HBase
HadoopLogo
HBase(HadoopDatabase),是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PCServer上搭建起大规模结构化存储集群。HBase是GoogleBigtable的开源实现,类似GoogleBigtable利用GFS作为其文件存储系统,HBase利用HadoopHDFS作为其文件存储系统;Google运行MapReduce来处理Bigtable中的海量数据,HBase同样利用HadoopMapReduce来处理HBase中的海量数据。
虽然大多数人都认为Hadoop及其所有的工具都是作为管理大规模集群的一种机制,其实不然,Hadoop也包括数据库,在HBase中也是通过节点来传播数据。Hadoop的Map/Reduce的架构是非常适合于复杂的计算任务或查询工作。领土在不断的扩张,新的数据库像Accumulo就是Hadoop平台的一个延伸。(ApacheAccumulo是一个可靠的、可伸缩的、高性能的排序分布式的Key-Value存储解决方案,基于单元访问控制以及可定制的服务器端处理。使用GoogleBigTable设计思路,基于ApacheHadoop、Zookeeper和Thrift构建)
BigTable/Accumulo/Hypertable
BigTable/Accumulo/HypertableLogo
BigTable是非关系的数据库,是一个稀疏的、分布式的、持久化存储的多维度排序Map。Bigtable的设计目的是可靠的处理PB级别的数据,并且能够部署到上千台机器上。Bigtable已经实现了下面的几个目标:适用性广泛、可扩展、高性能和高可用性。Bigtable已经在超过60个Google的产品和项目上得到了应用,包括GoogleAnalytics、GoogleFinance、Orkut、PersonalizedSearch、Writely和GoogleEarth。
谷歌的BigTable开启了NoSQL的热潮,现在很多公司都模仿谷歌的架构搭建了自己的平台。谷歌的AppEngine用户可以把键/值对存储在数据库中,而Hadoop的用户可以把它们放在Accumulo上,其他的可以使用Hypertable。所有的这些基本上都属于键/值存储,只不过添加了一些额外的功能,增加了搜索的速度而已。
DynamoDB
DynamoDBLogo
DynamoDB是亚马逊的key-value模式的存储平台,可用性和扩展性都很好,性能也不错:读写访问中99.9%的响应时间都在300ms内。DynamoDB的NoSQL解决方案,也是使用键/值对存储的模式,平且通过服务器把所有的数据存储在SSD上的三个不同的区域。如果有更高的传输需求,DynamoDB也可以在后台添加更多的服务器。