NoSql入门

栏目: 数据库 · 发布时间: 5年前

内容简介:NoSQL(NoSql = Not Only Sql), 意思是 “不仅仅是SQL” 范指非关系型的数据库。不是传统的关系型数据库解析:泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心。

什么是No-Sql

概念:

NoSQL(NoSql = Not Only Sql), 意思是 “不仅仅是SQL” 范指非关系型的数据库。不是传统的关系型数据库

解析:

泛指非关系型的数据库。随着互联网web2.0网站的兴起,传统的关系数据库在应付web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心。

为什么要使用NoSql数据库

互联网的瓶颈

1. 高并发读写

--针对短时间内具有高并发的情况,特别是短时间内大量的写入操作。传统数据库针对这种情况就有些力不从心了。

2. 海量数据的高效率存储和访问

现在的数据已经是非常庞大了,一些大型网站每天产生的数据量是相当恐怖的。存储了这么多的数据,查询效率就会受到很大的影响。

3. 高科扩展性和高可用性

基于传统数据库的结构,我们的数据库表是非常难以横向扩展的,比如增加一个新的字段 时或者修改某个字段时,牵一发而动全身。

4. 数据存储的方式单一。

在数据库中针对形形色色的数据,我们都只有采用表结构的方式来存储数据。

web2.0特别是一些用户访问量比较大的网站如:www.taobao.com weibo.com baidu.com

每秒的访问量可能是上万次(10K);传统的关系型数据库 mysql oracle 每秒进行10K次数据查询还可以勉强应付,但是如果是每秒10K次读写数据库,因为数据库的数据都是卸载磁盘中,所以磁盘IO也是支撑不住每秒10K的读写。

在web的架构中,数据库是最难进行横向扩展的(通过简单的添加机器和硬件,也就是添加一些服务节点来提高负载均衡能力);对于7*24小时在线的网站来说,对关系型数据库进行升级和扩展(分布式扩展--分库分表)是非常痛苦的事情,往往要进行停机维护;但这种对www.taobao.com 来说是非常丑陋的事情。[--可不可以添加几台服务器然后把复制,然后进行负载均衡--]。

NoSQL 是采用key/value的结构来存储数据,而且大多数的NoSQL采用内存来存储数据,一段时间后把数据同步到磁盘中;由于使用内存保存数据很好地解决了高并发读写的问题;其次NoSQL提供了根据key值进行横向分表(比如:用户id,每2000w数据放到一台数据库服务器中的一张用户表中);同时实现了主从数据库互备,这样可以让数据库的动态迁移变得简单,让数据库服务器的横向扩展变得容易了。

关系型数据库的优势:

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

关系型数据的不足:

  • 大量数据的写入处理

读写集中在一个数据库上让数据库不堪重负,大部分网站已使用主从复制技术实现读写分离,以提高读写性能和读库的可扩展性。所以在进行大量数据操作时,会使用数据库的主从模式,数据的写入由主数据库负责,数据的读入由从数据库负责,可以比较简单地通过增加从数据库来实现规模化,但是数据的写入却完全没有简单的方法来解决规模化问题。

解决方法:

①:要想将数据的写入规模化,可以考虑把主数据库从一台增加到两台,作为互相关联复制的二元主数据库使用,确实这样可以把每台主数据库的负荷减少一半,但是更新处理会发生冲突,可能会造成数据的不一致,为了避免这样的问题,需要把对每个表的请求分别分配给合适的主数据库来处理。

②:可以考虑把数据库分割开来,分别放在不同的数据库服务器上,比如将不同的表放在不同的数据库服务器上,数据库分割可以减少每台数据库服务器上的数据量,以便减少硬盘IO的输入、输出处理,实现内存上的高速处理。但是由于分别存储字不同服务器上的表之间无法进行Join处理,数据库分割的时候就需要预先考虑这些问题,数据库分割之后,如果一定要进行Join处理,就必须要在程序中进行关联,这是非常困难的。

为有数据更新表的索引或表结构变更

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

字段不固定时应用

如果字段不固定,利用关系型数据库也是比较困难的,有人会说,需要的时候加个字段就可以了,这样的方法也不是不可以,但在实际运用中每次都进行反复的表结构变更是非常痛苦的。你也可以预先设定大量的预备字段,但这样的话,时间一长很容易弄不清除字段和数据的对应状态,即哪个字段保存有哪些数据。

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

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

NoSql数据库的优势

  • 易扩展
    • NoSQL数据库种类繁多,但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系,这样就非常容易扩展。也无形之间,在架构的层面上带来了可扩展的能力。 
  • 大数据量性能高
    • NoSQL数据库都具有非常高的读写性能,尤其在大数据量下,同样表现优秀。这得益于它的无关系性,数据库的结构简单。一般 MySQL 使用Query Cache,每次表的更新Cache就失效,是一种大粒度的Cache,在针对web2.0的交互频繁的应用,Cache性能不高。而NoSQL的Cache是记录级的,是一种细粒度的Cache,所以NoSQL在这个层面上来说就要性能高很多了
  • 多样灵活的数据模型
    • NoSQL无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。而在关系数据库里,增删字段是一件非常麻烦的事情。如果是非常大数据量的表,增加字段简直就是一个噩梦

典型的NoSQL数据库

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

一、 键值存储

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

(1)临时性

所谓临时性就是数据有可能丢失,memcached把所有数据都保存在内存中,这样保存和读取的速度非常快,但是当 memcached 停止时,数据就不存在了。由于数据保存在内存中,所以无法操作超出内存容量的数据,旧数据会丢失。总结来说:

  • 在内存中保存数据
  • 可以进行非常快速的保存和读取处理
  • 数据有可能丢失

(2)永久性

所谓永久性就是数据不会丢失,这里的键值存储是把数据保存在硬盘上,与临时性比起来,由于必然要发生对硬盘的IO操作,所以性能上还是有差距的,但数据不会丢失是它最大的优势。总结来说:

  • 在硬盘上保存数据
  • 可以进行非常快速的保存和读取处理(但无法与memcached相比)
  • 数据不会丢失

(3) 两者兼备

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

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

二、面向文档的数据库

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

(1)不定义表结构

即使不定义表结构,也可以像定义了表结构一样使用,还省去了变更表结构的麻烦。

(2)可以使用复杂的查询条件

跟键值存储不同的是,面向文档的数据库可以通过复杂的查询条件来获取数据,虽然不具备事务处理和Join这些关系型数据库所具有的处理能力,但初次以外的其他处理基本上都能实现。

三、 面向列的数据库

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

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

四、图形数据库(这里就不作介绍了)

三种对比

1. key-value:内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等。优点:查询速度快。缺点:数据无结构化,通常只被当做字符串或者二进制数据。

2. 列存储:分布式文件系统。优点:查找速度快,可扩展性强,更容易进行分布式扩展。缺点:功能相对局限。

3. 文档型:与key-value类似,不同的是数据库能够了解value的内容。优点:数据结构要求不严格,表结构可变,不需要预先定义表结构。缺点:查询效率不高,缺乏统一的语法。

4. 图形:社交网络,推荐系统。专注于构建关系图谱。优点:利用图形结构相关算法,来寻求最短路径。缺点:很多时候需要对整个图形计算才能得出需要的信息。

络,推荐系统。专注于构建关系图谱。优点:利用图形结构相关算法,来寻求最短路径。缺点:很多时候需要对整个图形计算才能得出需要的信息。


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

营销三大算法

营销三大算法

刘学林、刘逸春、张新春、王颖、余彬晶、刘锦炽、董少灵、沈逸超、王锐睿、孙静若 / 上海交通大学出版社 / 2018-1-31 / 88.00元

未来的营销应该是数字化的,即数字营销。以数据为本,用演算做根,数字营销能够演算生活的方方面面。在数字营销领域,市场的整个投入、产出带来什么东西?企业一定要狠清楚地知道,这是做数字营销的本质。数字营销和企业做生意的本质是一样的,目的都是以投入换取产出。 本书由正和岛数字营销部落编写,基于大量企业的案例与数据,提出了营销三大核心算法与一套全局营销系统,帮助企业CEO与营销人员科学化建立全局营销系......一起来看看 《营销三大算法》 这本书的介绍吧!

XML、JSON 在线转换
XML、JSON 在线转换

在线XML、JSON转换工具

XML 在线格式化
XML 在线格式化

在线 XML 格式化压缩工具

HEX CMYK 转换工具
HEX CMYK 转换工具

HEX CMYK 互转工具