NoSQL思维导图
2020-04-22 10:23:07 2 举报AI智能生成
带你更深层了解NoSQL数据库
作者其他创作
大纲/内容
5.4 NoSQL的四大类型
键值数据库
子主题
列族数据库
hgetall
文档数据库
一个数据记录
XML文档
HTML文档
JSON文档
SequoiaDB数据库
存储
数据是不规则的
每一条记录包含了所有的有关“SequoiaDB”的信息而没有任何外部的引用，这条记录就是“自包含”的
这使得记录很容易完全移动到其他服务器
条记录的所有信息都包含在里面了，不需要考虑还有信息在别的表没有-起迁移走
只有被移动的那-条记录(文档)需要操作
ACID的保证就会变得更快速，读写的速度也会有很大的提升
图形数据库
不同类型数据库比较分析
MySQL
产生早，随LAMP大潮得成熟，改进不大，但是新兴的互联网使用的最多的数据库
MongoDB
提供更灵活的数据模型、异步提交、地理位置索引等五花十色的功能
HBase
依仗着Hadoop的生态环境，可以有很好的扩展性。
5.5 NoSQL的三大基石
CAP
C : 一致性
指任何一个读操作总是能够读到之前完成的写操作的结果，
也就是在分布式环境中，多点的数据是一致的，或，所有节点在同一时间具有相同的数据
A : 可用性
指快速获取数据，可以在确定的时间内返回操作结果，保证每个请求不管成功或者失败都有响应;
P ： 分区容忍性
系统中任意信息的丢失或失败不会影响系统的继续运作。
CA
强调一致性(C)和可用性(A)，放弃分区容忍性(P )
把所有与事务相关的内容都放到同一- 台机器上
CP
强调一致性(C)和分区容忍性(P)，放弃可用性(A)
AP
强调可用性(A)和分区容忍性(P)，放弃一致性(C)
允许系统返回不一致的数据
BASE
基本可用
软状态
“软状态( soft-state)”是与“硬状态( hard-state)”相对应的一种提法。数据库保存的数据是“硬状态”时，可以保证数据一-致性，即保证数据一直是正确的。 “软状态” 是指状态可以有- -段时间不同步，具有一定的滞后性
最终一致性
最终一致性（弱一致性的特例）
一致性的类型
强一致性
当执行完一次更新操作后，后续的其他读操作就可以保证读到更新后的最新数据;反之，如果不能保证后续访问读到的都是更新后的最新数据
弱一致性
而最终-致性只不过是弱一致性的一种特例，允许后续的访问操作可以暂时读不到更新后的数据，但是经过一-段时间之后， 必须最终读到更新后的数据
最常见系统
DNS (域名 系统)
一个域名更新操作根据配置的形式被分发出去，并结合有过期机制的缓存;最终所有的客户端可以看到最新的值。
根据更新数据后各进程访问到数据的时间和方式的不同
因果-致性
如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将获得A写入的最新值。而与进程A无因果关系的进程C的访问，仍然遵守- -般的最终- -致性规则
“读己之所写”一致性
因果- -致性的-一个特例
当进程A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值
单调读-致性
如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值
会话-致性:
它把访问存储系统的进程放到会话( session)的上下文.中，只要会话还存在，系统就保证“读己之所写”-致性。
如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话
单调写-致性
系统保证来自同一个进程的写操作顺序执行。
如何实现各种类型的一致性?
5.6 NoSQL到NewSQL数据库
5.7 文档数据库MongDB
NoSQL数据库
5.1 NoSQL简介
概念
Not Only SQL
与关系型数据库彼此无法
特点
（1）灵活的可扩展性
（2）灵活的数据模型
（3）与云计算紧密融合
现使用公司
Facebook
Mozilla
Adobe
Foursquare
百度、腾讯、阿里、新浪、华为.....
5.2 NoSQL兴起的原因
1.关系型数据库无法满足web2.0需求
( 1)无法满足海量数据的管理需求
(2)无法满足数据高并发的需求
(3)无法满足高可扩展性和高可用性的需求
2.MySQL集群无法完全解决问题
复杂性
部署、管理、配置很复杂
数据库复制
MySQL主备之间采用复制方式：异步复制
当主库压力较大时，可能产生较大延迟，主备切换可能会丢失最后一部分更新事务，这时往往需要人工介入，备份和恢复不方便
扩容问题
系统压力过大需要增加新的机器，这个过程涉及数据重新划分，整个过程比较复杂，且容易出错
动态数据迁移问题
3.“Onesizefitsall\"模式很难适用于截然不同的业务场景
关系模型作为统一的数据模型既被用于数据分析，也被用于在线业务。但这两者一个强调高吞吐，一个强调低延时，已经演化出完全不同的架构。用同--套模型来抽象显然是不合适的
Hadoop就是针对数据分析
MongoDB、Redis 等是针对在线业务，两者都抛弃了关系模型
4.关系型数据库Web2.0时代却成了鸡肋
(1) Web2.0 网站系统通常不要求严格的数据库事务
(2) Web2.0 并不要求严格的读写实时性
(3) Web2.0通常不包含大量复杂的SQL查询(去结构化，存储空间换取更好的查询性能)
5.3 NoSQL与关系数据库的比较
各方面比较表格
总结:彼此无法取代
关系数据库
优势
以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询，技术成熟，有专业公司的技术支持
劣势
可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持Web2.0应用，事务机制影响了系统的整体性能等
应用场景
NoSQL 数据库
可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等
缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性，技术尚不成熟，缺乏专业团队的技术支持，维护较困难等
互联网企业、传统企业的非关键业务(比如数据分析)
采用混合架构
●亚马逊公司就使用不同类型的数据库来支撑它的电子商务应
●当前的产品和订单信息则适合存放在关系数据库中大量的历史订单信息则适合保存在类似MongoDB的文档数据库中
●对于“购物篮”这种临时性数据，采用键值存储会更加高效
0 条评论
下一页
为你推荐
查看更多
