NoSQL

来自软件开发
跳转至: 导航搜索

什么是NOSQL?

NoSQL(NoSQL = Not Only SQL ),意即“不仅仅是SQL”,泛指非关系型的数据库。

一种非关系数据库管理系统,提供存储、处理和访问任何类型数据的功能,并基于一种无模式、灵活的数据模型,支持横向的、向外扩展的架构。

NoSQL可以大体上分为4个种类:Key-value、Document-Oriented、Column-Family Databases以及 Graph-Oriented Databases。

诞生的原因

随着互联网的不断发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求,主要体现在下面这四个方面:

1. 低延迟的读写速度:应用快速地反应能极大地提升用户的满意度;

2. 支撑海量的数据和流量:对于搜索这样大型应用而言,需要利用PB级别的数据和能应对百万级的流量;

3. 大规模集群的管理:系统管理员希望分布式应用能更简单的部署和管理;

4. 庞大运营成本的考量:IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低;

虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位,但是由于其天生的几个限制,使其很难满足上面这几个需求:

1. 扩展困难:由于存在类似Join这样多表查询机制,使得数据库在扩展方面很艰难;

2. 读写慢:这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂,使得其非常容易发生死锁等的并发问题,所以导致其读写速度下滑非常严重;

3. 成本高:企业级数据库的License价格很惊人,并且随着系统的规模,而不断上升;

4. 有限的支撑容量:现有关系型解决方案还无法支撑Google这样海量的数据存储;

业界为了解决上面提到的几个需求,推出了多款新类型的数据库,并且由于它们在设计上和传统的NoSQL数据库相比有很大的不同,所以被统称为“NoSQL”系列数据库。总的来说,在设计上,它们非常关注对数据高并发地读写和对海量数据的存储等,与关系型数据库相比,它们在架构和数据模型方量面做了“减法”,而在扩展和并发等方面做了“加法”。现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。

优点

1. 简单的扩展:典型例子是Cassandra,由于其架构是类似于经典的P2P,所以能通过轻松地添加新的节点来扩展这个集群;

2. 快速的读写:主要例子有Redis,由于其逻辑简单,而且纯内存操作,使得其性能非常出色,单节点每秒可以处理超过10万次读写操作;

3. 低廉的成本:这是大多数分布式数据库共有的特点,因为主要都是开源软件,没有昂贵的License成本;

缺点

1. 不提供对SQL的支持:如果不支持SQL这样的工业标准,将会对用户产生一定的学习和应用迁移成本;

2. 支持的特性不够丰富:现有产品所提供的功能都比较有限,大多数NoSQL数据库都不支持事务,也不像MS SQL Server和Oracle那样能提供各种附加功能,比如BI和报表等;

3. 现有产品的不够成熟:大多数产品都还处于初创期,和关系型数据库几十年的完善不可同日而语;

适用场景

NoSQL数据库在以下的这几种情况下比较适用:

1、数据模型比较简单;

2、需要灵活性更强的IT系统;

3、对数据库性能要求较高;

4、不需要高度的数据一致性;

5、对于给定key,比较容易映射复杂值的环境。

分类

键值(Key-Value)数据库

概述:键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据,鉴于使用主键访问,所以会获得不错的性能及扩展性。

产品:Riak、Redis、Memcached、Amazon’s Dynamo、Project Voldemort

有谁在使用:GitHub (Riak)、BestBuy (Riak)、Twitter (Redis和Memcached)、StackOverFlow (Redis)、 Instagram (Redis)、Youtube (Memcached)、Wikipedia(Memcached)

适用的场景:

储存用户信息,比如会话、配置文件、参数、购物车等等。这些信息一般都和ID(键)挂钩,这种情景下键值数据库是个很好的选择。

不适用场景

需要通过值来查询。Key-Value数据库中根本没有通过值查询的途径。【毕竟value可以重复,一个孩子多个父亲,岂不是青青草原】

需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。

需要事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。

面向文档(Document-Oriented)数据库

概述:面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元,是一系列数据项的集合。 每个数据项都有一个名称与对应的值,值既可以是简单的数据类型,如字符串、数字和日期等;也可以是复杂的类型,如有序列表和关联对象。 数据存储的最小单位是文档,同一个表中存储的文档属性可以是不同的,数据可以使用XML、JSON或者JSONB等多种形式存储。

产品:MongoDB、CouchDB、RavenDB

有谁在使用:SAP (MongoDB)、Codecademy (MongoDB)、Foursquare (MongoDB)、NBC News (RavenDB)

适用的场景

日志。企业环境下,每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式,所以我们可以使用它储存不同的信息。

分析。鉴于它的弱模式结构,不改变模式下就可以储存不同的度量方法及添加新的度量。

不适用场景

在不同的文档上添加事务。Document-Oriented数据库并不支持文档间的事务,如果对这方面有需求则不应该选用这个解决方案。

列存储数据库

概述:列存储数据库将数据储存在列族中,一个列族存储经常被一起查询的相关数据。 举个例子,如果我们有一个Person类,我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下,姓名和年龄就会被放入一个列族中,而薪资则在另一个列族中。

产品:Cassandra、HBase

有谁在使用:Ebay (Cassandra)、Instagram (Cassandra)、NASA (Cassandra)、Twitter (Cassandra and HBase)、Facebook (HBase)、Yahoo!(HBase)

适用的场景

日志。因为我们可以将数据储存在不同的列中,每个应用程序可以将信息写入自己的列族中。

博客平台。我们储存每个信息到不同的列族中。举个例子,标签可以储存在一个,类别可以在一个,而文章则在另一个。

不适用场景

如果我们需要ACID事务。Vassandra就不支持事务。

原型设计。如果我们分析Cassandra的数据结构,我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初,我们根本不可能去预测它的查询方式,而一旦查询方式改变,我们就必须重新设计列族。

图(Graph-Oriented)数据库

概述:图数据库允许我们将数据以图的方式储存。实体会被作为顶点,而实体之间的关系则会被作为边。 比如我们有三个实体,Steve Jobs、Apple和Next,则会有两个“Founded by”的边将Apple和Next连接到Steve Jobs。

产品:Neo4J、Infinite Graph、OrientDB

有谁在使用:Adobe (Neo4J)、Cisco (Neo4J)、T-Mobile (Neo4J)

适用的场景

在一些关系性强的数据中

推荐引擎。如果我们将数据以图的形式表现,那么将会非常有益于推荐的制定

不适用场景

不适合的数据模型。图数据库的适用范围很小,因为很少有操作涉及到整个图。

参考资料