NoSQL数据库的出现及选择哪种NoSQL数据库

    在没有NOSQL数据时,关系型数据库一直是数据持久化的唯一选择,比较典型的关系型数据库有SQL Server、Oracle,MySQL,DB2.做.NET开发的同学一般会选择SQL Server,做JAVA的可能会偏向Oracle,MySQL,Python则是PostgreSQL或MySQL等等。过去很长一段时间内,关系数据库的健壮性已经在多数应用程序中得到证实。我们可以使用这些传统数据库良好的控制并发操作、事务等等。然而如果传统的关系型数据库一直这么可靠,那么为什么还会出现NOSQL呢?NoSQL之所以生存并得到发展,是因为它做到了传统关系型数据库做不到的事!

 

关系型数据库中存在的问题

我们使用的高级编程语言如Java、.Net.python等语言他们都有一个共同的特性——面向对象。但是我们所使用数据库MySQL、PostgreSQL、Oracle以及SQL Server他们同样有一个共同的特性——关系型数据库。这里就牵扯到了“Impedance Mismatch”这个术语:存储结构是面向对象的,但是数据库却是关系的,所以在每次存储或者查询数据时,我们都需要做转换。

 

应用程序规模的变大

随着互联网的逐渐发展,越来越多的业务数据和访问能力让服务器承受着巨大的负担为了解决这个问题我们可以通过扩展:一种是纵向扩展,即购买更好的机器,更大的磁盘空间、更多的内存等等;另一种是横向扩展,即购买更多的机器组成集群,搭建分布式服务器,在巨大的规模下,纵向扩展发挥的作用并不是很大。首先单机器性能提升需要巨额的开销并且有着性能的上限,在Google和Facebook这种规模下,永远不可能使用一台机器支撑所有的负载。鉴于这种情况,我们需要新的数据库,因为关系数据库并不能很好的运行在集群上。

 

NoSQL 数据库特点

不再使用SQL语言

一般为开源项目

为集群运行而生

弱结构化——不会严格的限制数据结构类型

 

NoSQL数据库的类型

NoSQL可以大体上分为4个种类:键-值对数据库列族/大表数据库文档数据库以及 图形数据库。下面就一览这些类型的特性:

 

一、 键-值对数据库

键值数据库就像在传统语言中使用的哈希表。你可以通过key来添加、查询或者删除数据,鉴于使用主键访问,所以会获得不错的性能及扩展性虽然具备高度可扩展性,但却无法帮助开发人员顺畅处理复杂数据集。如果大家需要进行磁盘备份、分布式散列表并通过一致性对数据内容加以检查,那么上述方案既具备良好的规模化能力、又能提供出色的处理速度。然而如果我们需要通过某个键来获取另一个键、进而访问第三个键以查询相关值,那么问题就会变得不易处理了

代表产品:Couchbase、Riak、Redis、Memcached

案列:Youtube (Memcached)、Twitter (Redis)、StackOverFlow (Redis)、GitHub (Riak)

适用的场景

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

不适用场景

1. 取代通过键查询,而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。

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

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

 

二、列族/大表数据库

这是键-值数据库的一种更为先进的表现形式。从本质上讲,其中的键与值 存在一定程度的复合。我们可以将其视为一套贯穿多维数组的散列映射。基本每一个列都容纳着一行数据。举个例子,如果我们有一个Person类,我们通常会一起查询他们的姓名和年龄而不是薪资。这种情况下,姓名和年龄就会被放入一个列族中,而薪资则在另一个列族中。

 

代表产品:Cassandra、HBase

案列:Instagram (Cassandra),NASA (Cassandra),Yahoo!(HBase)

适用的场景

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

2. 社交平台。我们储存每个信息到不同的列族中。

不适用场景

1. 需要ACID事务。

2. 数据之间的关系与数据本身的重要性不相上下

 

三、文档数据库

面向文档数据库会将数据以文档的形式储存。每个文档都是自包含的数据单元,是一系列数据项的集合。每个数据项都有一个名称与对应的值,值既可以是简单的数据类型,如字符串、数字和日期等;也可以是复杂的类型,如有序列表和关联对象。数据存储的最小单位是文档,同一个表中存储的文档属性可以是不同的,数据可以使用XML、JSON或者JSONB等多种形式存储。文档数据库属于自然而然的发展趋势。从集群化到数据访问,文档数据库与键-值数据库几乎完全一致;惟一的区别在于,文档数据库能够理解所存储数据中的文档内容。”换句话来说,文档数据库会可以将值作为JSON、而JSON文档中的元素则能够通过检索轻松进行查询与搜索。

代表产品:MongoDB、CouchDB、Couchbase

案列:SAP (MongoDB)

适用的场景

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

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

不适用场景

在不同的文档上添加事务。文档数据库数据库并不支持文档间的事务

 

四、图形数据库

形数据库并不太关注数据规模或者可用性,而主要针对我们的数据之间存在怎样的相关性以及用户需要如何执行计算任务。正如Neo Technologies公司(主要产品为Neo4j数据库)产品工程高级主管Philip Rathle所说,图形数据库的威力主要体现在“数据集在本质上存在关联且非表格形式的情况下。其首要数据访问模式采用事务型机制,即OLTP/记录系统而非批量处理机制……请大家记住,图形数据库允许以事务性方式执行关联性操作,这一点在关系型数据库管理系统领域只能通过批量处理来完成。”

代表产品:Neo4J

案列:Adobe(Neo4J)

适用的场景

1. 在一些关系性强的数据中

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

不适用场景

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
关系型数据库NoSQL数据库 什么是NoSQL 大家有没有听说过“NoSQL”呢?近年,这个词极受关注。看到“NoSQL”这个词,大家可能误以为是“No!SQL”的缩写,并深感愤怒:“SQL怎么没有必要了呢?”但实际上,它是“Not Only SQL”的缩写。它的意义是:适用关系型数据库的时候就使用关系型数据库,不适用的时候也没有必要非使用关系型数据库不可,可以考虑使用更加合适的数据存储。 为弥补关系型数据库的不足,各种各样的NoSQL数据库应运而生。 为了更好地了解本书所介绍的NoSQL数据库,对关系型数据库的理解是必不可少的。那么,就让我们先来看一看关系型数据库的历史、分类和特征吧。 关系型数据库简史 1969年,埃德加•弗兰克•科德(Edgar Frank Codd)发表了划时代的论文,首次提出了关系数据模型的概念。但可惜的是,刊登论文的《IBM Research Report》只是IBM公司的内部刊物,因此论文反响平平。1970年,他再次在刊物《Communication of the ACM》上发表了题为“A Relational Model of Data for Large Shared Data banks”(大型共享数据库的关系模型)的论文,终于引起了大家的关注。 科德所提出的关系数据模型的概念成为了现今关系型数据库的基础。当时的关系型数据库由于硬件性能低劣、处理速度过慢而迟迟没有得到实际应用。但之后随着硬件性能的提升,加之使用简单、性能优越等优点,关系型数据库得到了广泛的应用。 通用性及高性能 虽然本书是讲解NoSQL数据库的,但有一个重要的大前提,请大家一定不要误解。这个大前提就是“关系型数据库的性能绝对不低,它具有非常好的通用性和非常高的性能”。毫无疑问,对于绝大多数的应用来说它都是最有效的解决方案。 突出的优势 关系型数据库作为应用广泛的通用型数据库,它的突出优势主要有以下几点: 保持数据的一致性(事务处理) 由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处) 可以进行JOIN等复杂查询 存在很多实际成果和专业技术信息(成熟的技术) 这其中,能够保持数据的一致性是关系型数据库的最大优势。在需要严格保证数据一致性和处理完整性的情况下,用关系型数据库是肯定没有错的。但是有些情况不需要JOIN,对上述关系型数据库的优点也没有什么特别需要,这时似乎也就没有必要拘泥于关系型数据库了。 关系型数据库的不足 不擅长的处理 就像之前提到的那样,关系型数据库的性能非常高。但是它毕竟是一个通用型的数据库,并不能完全适应所有的用途。具体来说它并不擅长以下处理: 大量数据的写入处理 为有数据更新的表做索引或表结构(schema)变更 字段不固定时应用 对简单查询需要快速返回结果的处理 。。。。。。 NoSQL数据库 为了弥补关系型数据库的不足(特别是最近几年),NoSQL数据库出现了。关系型数据库应用广泛,能进行事务处理和JOIN等复杂处理。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。 易于数据的分散 如前所述,关系型数据库并不擅长大量数据的写入处理。原本关系型数据库就是以JOIN为前提的,就是说,各个数据之间存在关联是关系型数据库得名的主要原因。为了进行JOIN处理,关系型数据库不得不把数据存储在同一个服务器内,这不利于数据的分散。相反,NoSQL数据库原本就不支持JOIN处理,各个数据都是独立设计的,很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作,处理起来也更加容易。同理,数据的读入操作当然也同样容易。 提升性能和增大规模 下面说一点题外话,如果想要使服务器能够轻松地处理更大量的数据,那么只有两个选择:一是提升性能,二是增大规模。下面我们来整理一下这两者的不同。 首先,提升性能指的就是通过提升现行服务器自身的性能来提高处理能力。这是非常简单的方法,程序方面也不需要进行变更,但需要一些费用。若要购买性能翻倍的服务器,需要花费的资金往往不只是原来的2倍,可能需要多达5到10倍。这种方法虽然简单,但是成本较高。 另一方面,增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要依葫芦画瓢增加廉价服务器的数量就可以了。 不对大量数据进行处理的话就没有使用的必要吗? NoSQL数据库基本上来说为了“使大量数据的写入处理更加容易(让增加服务器数量更容易)”而设计的。但如果不是对大量数据进行操作的话,NoSQ
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值