NoSQL数据库面面观

关于我们
让大家在InfoQ上听见你的声音
合作伙伴

欢迎关注我们的:

InfoQ – 促进软件开发领域知识与创新的传播
ding

En |
中文 |
日本 |
Fr |
Br

164,153 十月 独立访问用户

语言 & 开发
Java
.Net
云计算
移动
HTML 5
JavaScript
Ruby
DSLs
Python
PHP
PaaS
特别专题语言 & 开发
如何在Azure环境里做好信息传递可扩展性经验分享

本文介绍建立一个在Azure上使用Azure服务总线, 高吞吐量短信平台的必要步骤。在这篇文章中提出的解决方案是在响应由客户的具体要求,建立一个基于Windows Azure技术的复杂远程信息处理应用。
浏览所有语言 & 开发
架构 & 设计
建模
性能和可伸缩性
领域驱动设计
AOP
设计模式
安全
云计算
SOA
特别专题架构 & 设计
Codenvy背后的技术–一次与CEO TylerJewell的深入访谈

Codenvy是个在线IDE(集成开发环境),它支持使用Java、JavaScript、HTML5、PHP、Ruby和其它语言开发应用程序,同时也内置支持在PaaS上部署这些应用。本文描述了与其CEO Tyler Jewell的一次访谈,其中主要讲述了Codenvy背后所包含的技术。
浏览所有架构 & 设计
过程 & 实践
Agile
领导能力
团队协作
敏捷技术
方法论
持续集成
精益
客户及需求
特别专题过程 & 实践
平安科技于彩荣谈为何保险行业的IT团队需要敏捷化

随着敏捷大潮的涌起,越来越多的团队开始尝试敏捷。但是什么是敏捷?我们该如何着手? 本文作者用平安团队试点敏捷的实战过程揭示了传统金融IT业的敏捷导入过程。 如何应对堆积如山的需求和频繁的需求变更,削减外部压力? 如何在传统金融业提高发布频率,降低版本风险? 每日站会和回顾会议流于形式怎么办? 我们应该避免哪些敏捷陷阱? 不要为了敏捷而敏捷,而是为了解决问题。敏捷,归根到底是过程…
浏览所有过程 & 实践
运维 & 基础架构
性能和可伸缩性
大数据
DevOps
云计算
虚拟化
NoSQL
应用服务器
运维
特别专题运维 & 基础架构
Richard Nicholson谈OSGi联盟与云计算

Paremus的Richard Nicholson与InfoQ讨论了即将到来的R6企业级规范,它对云计算环境会有怎样的影响以及OSGi作为模块化技术在将来的动态分布式计算平台中会有什么样的位置。
浏览所有运维 & 基础架构
企业架构
企业架构
业务流程建模
业务/IT整合
Integration (EAI)
治理
Web 2.0
SOA
特别专题企业架构
Codenvy背后的技术–一次与CEO TylerJewell的深入访谈

Codenvy是个在线IDE(集成开发环境),它支持使用Java、JavaScript、HTML5、PHP、Ruby和其它语言开发应用程序,同时也内置支持在PaaS上部署这些应用。本文描述了与其CEO Tyler Jewell的一次访谈,其中主要讲述了Codenvy背后所包含的技术。
浏览所有企业架构

QCon上海2013
11月1-3日
上海光大会展中心

移动
HTML 5
Node.js
云计算
大数据
运维
架构师
QCon大会
QClub

全部话题
New UI
您目前处于: InfoQ首页 新闻 NoSQL数据库面面观
NoSQL数据库面面观
作者 张龙 发布于 十一月 16, 2013 | 讨论

新浪微博 腾讯微博 豆瓣网 Twitter Facebook linkedin 邮件分享 更多 5
“稍后阅读”
“我的阅读清单”

Alexey Vasiliev是一位知名的Web开发者与Linux系统管理员,曾参与开发过多个项目,如falcon、mongodb_logger、sht_rails及piro等项目。近日,Vasiliev就当前各种NoSQL数据库的优势与劣势撰文进行了详尽的分析。这些分析与比较将会对广大开发者项目的NoSQL数据库选型提供一定的帮助与指导作用。

NoSQL数据库现在已经变得非常流行了,在NoSQL这个大概念下实际上包含了大量的方式与项目,旨在实现各种数据库模型,他们与传统的关系型数据库管理系统存在着非常大的差别,而传统的关系型数据库系统是通过SQL的方式来访问数据的。在NoSQL领域中,传统观念中的模式可以通过不同的数据结构来实现,如散列表、数组、树、图等等。

术语“NoSQL”最早出现在上个世纪90年代末期,然而真正为大家所熟知则是在2009年中期。起初,它只是由Carlo Strozzi创建的一个小型开源数据库,将所有数据以ASCII文件的形式存储,并使用shell脚本而非SQL来访问这些数据。这个数据库与当前的“NoSQL”概念并没有任何相似之处。

Johan Oskarsson在2009年6月于旧金山组织了一场会议,讨论IT市场的新技术、数据存储与处理等主题。之所以会举办这场会议的主要原因在于BigTable和Dynamo等新产品的出现。“NoSQL”这个术语则是由来自RackSpace的Eric vans提出的。这个术语原本就是用在这场会议当中的,也没有什么更深层次的含义。不过最后的结果却是它迅速在互联网上蔓延开来,成为IT领域的一个新趋势。随后,Pramod J.Sadalage与Martin Fowler编写了“NoSQL Distilled”一书,旨在对日益庞大的NoSQL世界进行组织。

现在大约有150多种NoSQL数据库(nosql-database.org),下面就来探讨一下NoSQL的主要发展方向。
列簇存储

面向列的DBMS是这样一种数据库管理系统,它将数据表存储为数据列而非行的形式。从物理上来说,表是列的集合,每一列从本质上来说都是只有一个字段的表。这些数据库通常用于分析系统、商业智能与分析型数据存储。

优点:

可以比较数据,因为在表的一列中,数据通常都是同种类型的。
可以通过便宜、性能一般的硬件实现高速的查询性能;由于压缩的原因,相对于关系型数据库来说,这种方式磁盘上的数据所占据的空间要少5到10倍。

缺点:

通常没有事务。
对于熟悉传统RDBMS的开发者来说存在不少限制。

典型代表:

HBase
Cassandra
Accumulo
Amazon SimpleDB

键值存储

你可以通过这种数据库将键值对存储到持久化存储中,随后使用键来读取值。那么对于这种初看起来用途非常有限的解决方案来说有哪些好处呢?在根据键来保存/读取值时,系统是非常高效的,因为它没有SQL处理器、索引系统以及分析系统等诸多限制。这种解决方案提供了最高效的性能,代价最低的实现以及可伸缩性。

优点:

RDBMS太慢了,SQL游标的负担过于沉重。
采用RDBMS的解决方案来存储少量数据的代价有些大。
没必要使用SQL查询、索引、触发器、存储过程、临时表、表单以及视图等等。
由于其轻量级的设计,键值数据库可以很容易实现可伸缩性以及高性能。

缺点:

关系型数据库的限制可以从底层就确保数据的完整性,而键值存储就没有这些限制,数据的完整性是由应用来控制的。在这种情况下,数据的完整性可能会由于应用代码的错误而做一些妥协。
在RDBMS中,如果模型设计良好,那么数据库的逻辑结构就能完全反映出存储数据的结构,并且与应用的结构有所不同(数据是独立于应用的)。对于键值存储来说,要想取得这种效果是非常困难的事情。

典型代表:

Amazon DynamoDB
Riak
Redis
LevelDB
Scalaris
MemcacheDB
Kyoto Cabinet

文档存储

文档存储指的是用于存储、搜索与管理面向文档的信息(半结构化数据)的程序,其中心概念就是文档。具体的面向文档数据库的实现是不同的,不过总的来说,他们都会以各种标准化格式对数据(文档)进行封装与加密,主要格式有XML、YAML、JSON、BSON、PDF等等。

优点:

足够灵活的查询语言。
易于水平扩展。

缺点:

在很多时候原子性是得不到保障的。

典型代表:

MongoDB
Couchbase
CouchDB
RethinkDB

图型数据库

图型数据库指的是使用图结构的数据库,通过结点、边与属性来表示和存储数据。根据定义,图型数据库是一种提供了无需索引而彼此邻接的存储系统。这意味着每个元素都包含了直接指向邻接元素的指针,因此没必要再通过索引进行查找了。

优点:

对于关联数据集的查找速度更快。
可以很自然地扩展为更大的数据集,因为他们无需使用代价高昂的连接运算符。

缺点:

RDBMS可以用在更为通用的场景下,图型数据库只适合类似于图的数据。

典型代表:

Neo4j
FlockDB
InfoGrid
OrientDB

多模数据库

这些数据库包含了多种数据库的特性。

有两种不同的产品分组可以认为是多模的:

支持多种数据模型和用例的多模数据库。 比如说,ArangoDB宣称它拥有键值存储的好处,同时还提供了面向文档以及图型数据库的支持。
支持多种模式的通用目的的数据库。 比如说,Oracle的MySQL 5.6支持SQL方式的访问,也可以通过Memcached API实现键值访问。

典型代表:

ArangoDB
Aerospike
Datomic

对象数据库

数据库中的数据都建模为对象、属性、方法以及类。面向对象的数据库通常适合于需要高性能数据处理的应用,这种应用一般都有非常复杂的结构。

优点:

相比于关系元组来说,对象模型最适合于展现现实世界,对于复杂、多方位的对象来说尤为如此。
使用层次特性来组织数据。
访问数据时并不需要专门的查询语言,因为访问是直接面向对象的。然而,有时也是需要使用查询的。

缺点

在RDBMS中,由于表的创建、修改或是删除而导致的模式修改通常并不依赖于应用。在使用对象数据库的应用中,模式修改类通常意味着还要对与当前类关联的其他应用类进行修改。这会导致对整个系统进行修改。
对象数据库通常会通过单独的API与特定的语言绑定,只有通过该API才能查询数据。在这方面,RDBMS就做得很好,这要归功于它所使用的通用查询语言。

典型代表:

VelocityDB
Objectivity
ZODB
Siaqodb
EyeDB

多维数据库

这是针对在线分析处理的一种数据库,它可以从各种关系型数据库中检索数据,并且以某种方式将信息组织为类别和段当中。

典型代表:

GlobalsDB
Intersystems Cache
SciDB
Rasdaman

多值数据库

多维数据库的变种。主要的特性是支持使用属性来存储值的列表。

典型代表:

Rocket U2
OpenInsight
Reality

总结

NoSQL的发展速度异常迅猛,不过这并不意味着关系型数据库就没落了。他们还会在很多场景下发挥着巨大的作用,并且与NoSQL数据库共存。我们现在处在多种持久化存储共存的时代,并不存在处于垄断地位的关系型数据库与NoSQL数据库。架构师们对数据库的选择将会基于数据存储本身的特性,以及所预估的数据量。

This entry was posted in Achitecture, DB. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s