大数据总结【第五章:Nosql】

时间:2024-04-12 15:22:11

Nosql

not only sql

NoSQL兴起的原因:(关系数据无法满足Web 2.0的需求)

1)无法满足海量数据的管理需求
2)无法满足数据高并发的需求
3)无法满足高可扩展性和高可用性的需求

Web2.0特性

1)Web2.0网站系统通常不要求严格的数据库事务
2)Web2.0并不要求严格的读写实时性
3)Web 2.0通常不包含大量复杂的SQL查询

NoSQL数据库具有以下几个特点

(1)灵活的可扩展性
(2)灵活的数据模型
(3)与云计算紧密融合

与关系数据库的比较

(1)关系数据库
优势:以完善的关系代数理论作为基础,有严格的标准,支持事务ACID四性,借助索引机制可以实现高效的查询,技术成熟,有专业公司的技术支持
劣势:可扩展性较差,无法较好支持海量数据存储,数据模型过于死板、无法较好支持Web2.0应用,事务机制影响了系统的整体性能等
(2)NoSQL数据库
优势:可以支持超大规模数据存储,灵活的数据模型可以很好地支持Web2.0应用,具有强大的横向扩展能力等
劣势:缺乏数学理论基础,复杂查询性能不高,大都不能实现事务强一致性,很难实现数据完整性,技术尚不成熟,缺乏专业团队的技术支持,维护较困难等

关系数据库和NoSQL数据库各有优缺点,彼此无法取代
• 关系数据库应用场景:电信、银行等领域的关键业务系统,需要保证强事务一致性
• NoSQL数据库应用场景:互联网企业、传统企业的非关键业务(比如数据分析)
采用混合架构
• 案例:亚马逊公司就使用不同类型的数据库来支撑它的电子商务应用
• 对于“购物篮”这种临时性数据,采用键值存储会更加高效
• 当前的产品和订单信息则适合存放在关系数据库中
• 大量的历史订单信息则适合保存在类似MongoDB的文档数据库中

NoSQL四大类型

大数据总结【第五章:Nosql】
典型的NoSQL数据库通常包括键值数据库、列族数据库、文档数据库和图形数据库
1)键值数据库
大数据总结【第五章:Nosql】

2)列族数据库
大数据总结【第五章:Nosql】
3)文档数据库
大数据总结【第五章:Nosql】

4)图数据库

大数据总结【第五章:Nosql】

不同类型数据库比较分析

大数据总结【第五章:Nosql】

  • MySQL产生年代较早,而且随着LAMP大潮得以成熟。尽管其没有什么大的改进,但是新兴的互联网使用的最多的数据库
  • MongoDB是个新生事物,提供更灵活的数据模型、异步提交、地理位置索引等五花十色的功能
  • HBase是个“仗势欺人”的大象兵。依仗着Hadoop的生态环境,可以有很好的扩展性。但是就像象兵一样,使用者需要养一头大象(Hadoop),才能驱使他
  • Redis是键值存储的代表,功能最简单。提供随机数据存储。就像一根棒子一样,没有多余的构造。但是也正是因此,它的伸缩性特别好。就像悟空手里的金箍棒,大可捅破天,小能成缩成针

三大基石

大数据总结【第五章:Nosql】
1)CAP
所谓的CAP指的是:

  • C(Consistency):一致性,是指任何一个读操作总是能够读到之前完成的写操作的结果,也就是在分布式环境中,多点的数据是一致的,或者说,所有节点在同一时间具有相同的数据
  • A:(Availability):可用性,是指快速获取数据,可以在确定的时间内返回操作结果,保证每个请求不管成功或者失败都有响应;
  • P(Tolerance of Network Partition):分区容忍性,是指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信),分离的系统也能够正常运行,也就是说,系统中任意信息的丢失或失败不会影响系统的继续运作。

一个分布式系统不可能同时满足一致性、可用性和分区容忍性这三个需求,最多只能同时满足其中两个

当处理CAP的问题时,可以有几个明显的选择:

  1. CA:也就是强调一致性(C)和可用性(A),放弃分区容忍性(P),最简单的做法是把所有与事务相关的内容都放到同一台机器上。很显然,这种做法会严重影响系统的可扩展性。传统的关系数据库(MySQL、SQL Server和PostgreSQL),都采用了这种设计原则,因此,扩展性都比较差
  2. CP:也就是强调一致性(C)和分区容忍性(P),放弃可用性(A),当出现网络分区的情况时,受影响的服务需要等待数据一致,因此在等待期间就无法对外提供服务
  3. AP:也就是强调可用性(A)和分区容忍性(P),放弃一致性(C),允许系统返回不一致的数据(Web2.0
    大数据总结【第五章:Nosql】
    2)BASE

BASE的基本含义是基本可用(Basically Availble)、软状态(Soft-state)和最终一致性(Eventual consistency):

  • 基本可用
    基本可用,是指一个分布式系统的一部分发生问题变得不可用时,其他部分仍然可以正常使用,也就是允许分区失败的情形出现
    软状态
  • “软状态(soft-state)”是与“硬状态(hard-state)”相对应的一种提法。数据库保存的数据是“硬状态”时,可以保证数据一致性,即保证数据一直是正确的。“软状态”是指状态可以有一段时间不同步,具有一定的滞后性
  • 最终一致性
    一致性的类型包括强一致性和弱一致性,二者的主要区别在于高并发的数据访问操作下,后续操作是否能够获取最新的数据。对于强一致性而言,当执行完一次更新操作后,后续的其他读操作就可以保证读到更新后的最新数据;反之,如果不能保证后续访问读到的都是更新后的最新数据,那么就是弱一致性。而最终一致性只不过是弱一致性的一种特例,允许后续的访问操作可以暂时读不到更新后的数据,但是经过一段时间之后,必须最终读到更新后的数据。
    最常见的实现最终一致性的系统是DNS(域名系统)。一个域名更新操作根据配置的形式被分发出去,并结合有过期机制的缓存;最终所有的客户端可以看到最新的值。

最终一致性根据更新数据后各进程访问到数据的时间和方式的不同,又可以区分为:

  • 因果一致性:如果进程A通知进程B它已更新了一个数据项,那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问,仍然遵守一般的最终一致性规则
  • “读己之所写”一致性:可以视为因果一致性的一个特例。当进程A自己执行一个更新操作之后,它自己总是可以访问到更新过的值,绝不会看到旧值
  • 单调读一致性:如果进程已经看到过数据对象的某个值,那么任何后续访问都不会返回在那个值之前的值
  • 会话一致性:它把访问存储系统的进程放到会话(session)的上下文中,只要会话还存在,系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止,就要建立新的会话,而且系统保证不会延续到新的会话
  • 单调写一致性:系统保证来自同一个进程的写操作顺序执行。系统必须保证这种程度的一致性,否则就非常难以编程了

mongoDB的使用