关系型数据库与NoSQL数据库场景说明

1

关系型数据库

关系型数据库把所有的数据都通过行和列的二元表现形式表示出来。它的优势:

  • 保持数据的一致性(事务处理)
  • 由于以标准化为前提,数据更新的开销很小(相同的字段基本上都只有一处)
  • 可以进行Join等复杂查询
  • 能够保持数据的一致性是关系型数据库的最大优势

关系型数据库的性能非常高,但是它毕竟是一个通用型的数据库,并不能完全适应所有的用途,具体来说它并不擅长以下处理:

  • 大量数据的写入处理。
  • 为有数据更新的表做索引或表结构(schema)变更
  • 字段不固定时应用
  • 对简单查询需要快速返回结果的处理

大量数据的写入处理:

在数据读入方面,由复制产生的主从模式(数据的写入由主数据库负责,数据的读入由从数据库负责),可以比较简单地通过增加从数据库来实现规模化。但是,在数 据的写入方面却完全没有简单的方法来解决规模化问题。例如,要想将数据的写入规模化,可以考虑把主数据库从一套增加到两台,作为互相关联复制的二元主数据 库来使用。确实这样似乎可以把每台主数据库的负荷减少一半,但是更新处理会产生冲突(同样的数据在两台服务器同时更新成其他值),可能会造成数据的不一 致。为了避免这样的问题,就需要把每个表的请求分别分配给合适的主数据库来处理,这就不那么简单了。

另外也可以考虑把数据库分割开来,分别放在不同的数据库服务器上,比如将这个表放在这个数据库服务器上,那个表放在那个数据库服务器上,数据库分割可以减少 每台数据库服务器上的数据量,以便减少硬盘I/O处理,实现内存上的高速处理,效果非常显著。但是,由于分别存储在不同服务器上的表之间无法进行JOIN 处理,数据库分割的时候就需要预先考虑这些问题。数据库分割后,如果一定要进行JOIN处理,就必须要在程序中进行关联,这是非常困难的。

为有数据更新的表做索引或表结构(schema)变更

在使用关系型数据库时,为了加快查询速度需要创建索引,为了增加必要的字段就一定需要改变表结构。为了进行这些处理,需要对表进行共享锁定,这期间数据变更 (更新、插入、删除等)是无法进行的。如果需要进行一些耗时操作(例如为数据量比较大的表创建索引或者是变更其表结构),就需要特别注意:长时间内数据可 能无法进行更新。

共享锁:其他连接可以对数据进行读取但是不能修改数据,是读锁。

排他锁:其他连接法务对数据进行读取和修改操作,是写锁。

字段不固定时的应用

如果字段不固定,利用关系型数据库也是比较困难的。加字段在实际运用中每次都进行反复的表结构变更时非常痛苦的。你也可以预先设定大量的预备字段,但这样的话,时间一长很容易弄不清楚字段和数据的对应状态(即哪个字段保存哪些数据),所以并不推荐使用。

对简单查询需要快速返回结果的处理

关系型数据库并不擅长对简单的查询快速返回结构。因为关系型数据库是使用专门的SQL语言进行数据读取的,它需要对SQL语言进行解析,同时还有对表的锁定 和解锁这样的额外开销。这里并不是说关系型数据库的速度太慢,而只是想告诉大家若希望对简单查询进行高速处理,则没有必要非用关系型数据库不可。

关系型数据库应用广泛,能进行事物处理和JOIN等复杂处理。相对地,NoSQL数据库只应用在特定领域,基本上不进行复杂的处理,但它恰恰弥补了之前所列举的关系型数据库的不足之处。

2

NoSQL数据库

NoSQL数据库原本就不支持JOIN处理,各 个数据都是独立设计的,很容易把数据分散到多个服务器上。由于数据被分散到了多个服务器上,减少了每个服务器上的数据量,即使要进行大量数据的写入操作, 处理起来也更加容易。同理,数据的读入操作当然也同样容易。所以它的优点是易于数据的分散

提 升处理大数据的能力可以通过两种方式提升性能(纵向)和增大规模(横向),提升性能指的是通过提升现行服务器自身的性能来提高处理能力。这需要的费用较 高。增大规模指的是使用多台廉价的服务器来提高处理能力。它需要对程序进行变更,但由于使用廉价的服务器,可以控制成本。另外,以后只要增加服务器的数量 就可以了。

典型的NoSQL数据库

临时性键值存储(memcached、Redis)、永久性键值存储(ROMA、Redis)、面向文档的数据库(MongoDB、CouchDB)、面向列的数据库(Cassandra、HBase)

键值存储

这是最常见的SQL数据库,它的数据是以键值的形式存储的。虽然它的处理速度非常快,但是基本上只能通过键的完全一致查询获取数据。根据数据的保存方式可以分为临时性、永久性和两者兼具3种。

临时性:memcahced把所有数据都保存在内存中,这样保存和读取的速度非常快。

永久性:把数据保存在硬盘上,与memcached在内存中处理数据比起来,由于必然要发生对硬盘的IO操作,所以性能上还是有差距的。

两者兼具:Redis 属于这种类型。Redis首先把数据保存在内存中,在满足特定条件(默认是15分钟一次以上,5分钟内10个以上,1分钟内10000个以上的键发生变 更)的时候将数据写入到硬盘中,这样既确保了内存中数据的处理速度,又可以通过写入硬盘来保证数据的永久性,这种类型的数据库特别适合处理数组类型的数 据,总结来说:

  • 同时在内存和硬盘上保存数据
  • 可以进行非常快速的保存和读取处理
  • 保存在硬盘上的数据不会消失(可以恢复)
  • 适合于处理数组类型的数据

面向文档的数据库

MongoDB、CouchDB属于这种类型,它们属于NoSQL数据库,但与键值存储相异。

  1. 不定义表结构:即使不定义表结构,也可以像定义了表结构一样使用,还省去了变更表结构的麻烦。
  2. 可以使用复杂的查询条件:跟键值存储不同的是,面向文档的数据库可以通过复杂的查询条件来获取数据,虽然不具备事务处理和Join这些关系型数据库所具有的处理能力,但初次以外的其他处理基本上都能实现。

面向列的数据库:普通的关系型数据库都是以行为单位来存储数据的,擅长进行以行为单位的读入处理,比如特定条件数据的获取。因此,关系型数据库也被称为面向行的数据库。面向列的数据库以列为单位,对大量行少数列进行读取,对所有行的特定列进行同时更新。

面向列的数据库具有高扩展性,即使数据增加也不会降低相应的处理速度(特别是写入速度),所以它主要应用于需要处理大量数据的情况。另外,利用面向列的数据库的优势,把它作为批处理程序的存储器来对大量数据进行更新也是非常有用的。

面向列的数据库

Cassandra、HBae、HyperTable属于这种类型,由于近年来数据量出现爆发性增长,这种类型的NoSQL数据库尤其引入注目。

普通的关系型数据库都是以行为单位来存储数据的,擅长以行为单位的读入处理,比如特定条件数据的获取。因此,关系型数据库也被成为面向行的数据库。相反,面向列的数据库是以列为单位来存储数据的,擅长以列为单位读入数据。

面 向列的数据库具有搞扩展性,即使数据增加也不会降低相应的处理速度(特别是写入速度),所以它主要应用于需要处理大量数据的情况。另外,把它作为批处理程 序的存储器来对大量数据进行更新也是非常有用的。但由于面向列的数据库跟现行数据库存储的思维方式有很大不同,故应用起来十分困难。

原文发布于微信公众号 - php(phpdaily)

原文发表时间:2016-05-30

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏码匠的流水账

聊聊partition的方式

一般来说,数据库的繁忙体现在:不同用户需要访问数据集中的不同部分,这种情况下,我们把数据的各个部分存放在不同的服务器/节点中,每个服务器/节点负责自身数据的读取...

501
来自专栏包子铺里聊IT

【最火大数据 Framework】五分钟深入 Spark 运行机制

上篇文章,我们简要介绍了 MapReduce 框架的局限和 Spark 横空出世的土壤。今天,我们就来详细介绍 Spark 的内部原理和它强大功能的背后设计。...

35512
来自专栏服务端技术杂谈

高性能与调优

814
来自专栏程序你好

Apache Spark大数据处理 - 性能分析(实例)

今天的任务是将伦敦自行车租赁数据分为两组,周末和工作日。将数据分组到更小的子集进行进一步处理是一种常见的业务需求,我们将看到Spark如何帮助我们完成这项任务。

1063
来自专栏java系列博客

=Java面试通关要点汇总集之核心篇参考答案

2203
来自专栏人工智能LeadAI

ElasticSearch优化系列三:索引过程

大家可能会遇到索引数据比较慢的过程。其实明白索引的原理就可以有针对性的进行优化。ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用...

3609
来自专栏架构师之路

计数系统架构实践一次搞定 | 架构师之路

提醒,本文较长,可提前收藏/转发。 一、需求缘起 很多业务都有“计数”需求,以微博为例: ? 微博首页的个人中心部分,有三个重要的计数: 关注了多少人的计数 粉...

3726
来自专栏牛肉圆粉不加葱

如何让你的 Spark SQL 查询加速数十倍?

先来回答标题所提的问题,这里的答案是列存储,下面对列存储及在列存储加速 Spark SQL 查询速度进行介绍

994
来自专栏Linuxer的专栏

谢宝友: 深入理解 Linux RCU 之从硬件说起

想要制造出质量可靠的桥梁,就必须真正懂得力学原理。对于想要理解RCU的软件工程师来说,也需要具备一定的硬件基础。

5680
来自专栏about云

hadoop为什么64MB(或128MB或256MB)是最优选择?

问题导读: 为什么不能远少于64MB(或128MB或256MB) ? 为什么不能远大于64MB(或128MB或256MB)? 为什么不能远少于64...

2796

扫码关注云+社区