NoSql入门

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

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

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


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

查看所有标签

猜你喜欢:

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

Uberland

Uberland

Alex Rosenblat / University of California Press / 2018-11-19 / GBP 21.00

Silicon Valley technology is transforming the way we work, and Uber is leading the charge. An American startup that promised to deliver entrepreneurship for the masses through its technology, Uber ins......一起来看看 《Uberland》 这本书的介绍吧!

HTML 压缩/解压工具
HTML 压缩/解压工具

在线压缩/解压 HTML 代码

html转js在线工具
html转js在线工具

html转js在线工具

RGB CMYK 转换工具
RGB CMYK 转换工具

RGB CMYK 互转工具