文章目录
- 5.1 NoSQL数据库
- 5.2 NoSQL和关系数据库的比较
- 5.3 四大类型NoSQL数据库
- 5.3.1 键值数据库和列族数据库
- 5.3.2 文档数据库、图数据库、以及不同数据库比较分析
- 5.4 NoSQL数据库的理论基石
- CAP理论:
- BASE理论:
- Eventual consistency(最终一致性):
- 5.5 从NoSQL到NewSQL数据库
- 5.6 文档数据库MongoDB
5.1 NoSQL数据库
NoSQL兴起原因1:关系型数据库无法满足Web2.0的需求
-
很多非关系型数据可以作为关系型数据的补充,很多业务场景下需要用到非关系型数据库
-
NOSQL数据库特点
-
灵活的可扩展性:有非常强大的水平可扩展性,可以支持在多个机器上水平扩展
-
灵活的数据模型
-
和云计算的紧密结合:
-
云计算基础设施可以根据负载实时变化,来对底层的IT设施进行动态伸缩,负载增加可以将更多机器加入集群,如果负载减少,可以将相关的机器退出;
-
传统关系型数据库的纵向可扩展性受到一定的限制,在水平可扩展性更是不具备这个特性,不能和云计算紧密结合
-
NoSQL在设计之初就考虑到了它的水平可扩展性,和云计算是紧密结合的
-
-
-
传统关系型数据库在性能上的缺陷
- 无法满足海量数据的管理需求
- 无法满足高并发的需求
- 因为动态数据无法提前生成,不能提前生成一个静态网页让用户来访问,只能实时地根据用户的请求来实时的生成数据
- 这种实时生成的数据,对数据库的负载非常高
- 基本上用关系型数据库是无法满足高并发的需求
- 无法满足高扩展性和高可用性的需求
- 中小型企业通过mysql集群方式的缺陷
- 复杂性:整个集群部署非常负载
- 延迟性:当主库的压力较大时,就会带来较大的延迟
- 扩容问题:当集群压力过大时,需要增加新机器对整个数据集进行重新分区,非常复杂
- 动态迁移:在集群使用过程中出现有些分库的负载重,有些分库的负载轻,这时候需要负载均衡,实现数据迁移,需要集群的总控节点来协调数据迁移过程,整个过程需要人工实现,很难实现其自动化
- 中小型企业通过mysql集群方式的缺陷
NoSQL兴起的原因2:数据模型的局限性
-
有些在线业务强调低延时,有些数据分析业务强调高吞吐率,场景不同对于数据架构提出的要求不同,用同一个数据模型适应不同业务场景是不切实际的
-
因此根据不同的业务需求研究出了不同的产品:例如Hadoop 用于数据分析、批处理;MongDB,Redis用于在线业务
NoSQL兴起的原因3:Web2.0关系型数据库的许多特性没有发挥
-
关系型数据库有着完善的事务机制,以及高效的查询机制,但这两个优势在Web2.0无法发挥
-
Web2.0用更多的存储空间换取更好的性能
5.2 NoSQL和关系数据库的比较
-
关系数据库和NoSQL比较
-
在数据库原理方面
- 关系型数据库:具有完备的关系代数理论作为基础
- NoSQL数据库:缺乏理论基础
-
数据规模
- 关系型数据库:很难实现横向扩展,纵向扩展非常有限
- NoSQL数据库:具有非常好的水平可扩展性
-
在数据库模式方面:
- 关系型数据库:要定义严格的数据库模式,而且要严格遵守事先定义的数据库模式
- NoSQL数据库:数据模型非常灵活
-
在查询效率方面:
- 关系型数据库:适当数量级查询效率高,当数量级增大时,查询效率下降
- NoSQL数据库:未构建面向复杂查询的索引,因此查询性能较差
-
在事务一致性方面:
- 关系型数据库:遵循ACID实物模型可以保证事务的强一致性
- NoSQL数据库:未构建面向复杂查询的索引,因此查询性能较差;NoSQL采用Base模型,很多NoSQL数据库只能保证最终一致性,不能保证强一致性
-
在数据库完整性方面:
- 关系型数据库:具有保证完整性的完备机制
- NoSQL数据库:不能实现完整性约束
-
在可扩展性方面:
- 关系型数据库:扩展性一般是比较差的
- NoSQL数据库:水平扩展性非常好
-
在可用性方面:
- 关系型数据库:随着规模增大,为了保证严格的一致性,可用性方面就削弱
- NoSQL数据库:具有非常好的可用性,能够在短时间内迅速返回所需要的结果
-
在标准化方面:
- 关系型数据库:关系型数据库遵循SQL标准,标准化比较完善,不同厂家数据库可以相互访问,导入导出
- NoSQL数据库:未形成通用的行业标准
-
在技术支持方面:
- 关系型数据库:关系型数据库很多都是商业数据库,可获得非常强大的技术和后续服务支持
- NoSQL数据库:NoSQL数据库很多都属于开源产品,处于整个发展的初期阶段
-
在可维护方面:
- 关系型数据库:关系型数据库需要管理员维护
- NoSQL数据库:没有成熟的基础和实践操作,维护较为复杂
-
-
关系数据库的优势与劣势
-
优势
-
劣势
-
-
NoSQL数据库的优劣势
-
两种数据库的应用场景
5.3 四大类型NoSQL数据库
- 四大类型NoSQL数据库
- 举例
5.3.1 键值数据库和列族数据库
-
键值数据库
-
相关产品:Redis、Memcached、SimpleDB(云端产品)
-
数据模型:键是一个字符串对象,值可以是任意类型的数据、比如整型字符型、数组、列表、集合等
-
典型应用:涉及频繁读写、拥有简单数据模型的应用、内容缓存、如会话、配置文件、参数、购物车等,存储配置和用户信息等移动应用
-
优点:扩展性好、灵活性号、大量写操作性能高
-
缺点:无法存储结构化信息,条件查询效率较低
-
不适用的场景:
- 键值数据库根本没有通过值查询的途径;
- 在键值数据库中,不能通过两个或者两个以上的键来关联数据;
- 在一些键值数据库中中产生故障时,不可以回滚
-
使用者:百度云数据库(Redis)
-
键值数据库的应用
- 键值数据库成为缓冲区,将经常访问的数据放入缓冲层
-
-
列族数据库
- 相关产品:BigTable、HBase(master-slave架构)、Cassandra(p2p架构)
- 数据模型:列族
- 典型应用:
- 适用于分布式数据存储与管理(尤其适用于海量数据存储管理,水平扩展性质好)
- 数据在地理上分布于多个数据中心的应用程序
- 可以容纳副本存在短期不一致情况的应用程序
- 拥有动态字段的应用程序
- 优点:查找速度快、可扩展性强、容易进行分布式扩展、复杂性低
- 缺点:功能较少,大多不支持强事务一致性
- 不适用场景:需要ACID事务支持的情形,Cassandra等产品就不适用
- 使用者:Facebook(HBase)、Yahoo(HBase)
5.3.2 文档数据库、图数据库、以及不同数据库比较分析
-
文档数据库
-
也是一种键值数据库,值为文档,关系数据库中的每一行记录,其实就是一个文档
-
特性:可以对自己的数据的内容和类型进行自我描述
-
文档数据库的数据格式:JSON格式
-
其拥有更好的并发性:
-
相关产品:MongDB、CouchDB
-
数据模型:就是一个键值、本质是以键值数据库、只不过值时版本化文档
-
典型应用:存储、索引并管理面向文档的是数据、或者类似的半结构化数据
-
优点:性能好(高并发),灵活性高,提供嵌入式文档功能,将经常查询到的数据存储在同一个文档中
-
缺点:缺乏统一的查询语法
-
不适用情形:文档是巨苦不支持文档间的事务,如果对这方面有需求则不应该选择这个解决方案
-
使用者:百度云数据库(MongDB)
-
-
图数据库
-
相关产品:Neo4j
-
数据模型:图结构
-
典型应用:专门用于处理具有高度相互关联关系的数据,比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
-
优点:灵活性高、支持复杂的图形算法,可用于构建复杂的关系图谱
-
缺点:数据模型应用范围非常有限
-
-
四大类型数据库的比较
5.4 NoSQL数据库的理论基石
- NoSQL数据库的三个理论基石:CAP、BASE、最终一致性
CAP理论:
-
Consistency 一致性:指任何一个读操作总能读到之前完成的写操作的结果
-
Availability 可用性:指快速获取数据、可以在确定的时间内返回操作结果,保证每个请求不管成功失败都有响应
-
Partition tolerance 分区容忍性:指当出现网络分区的情况时(即系统中的一部分节点无法和其他节点进行通信)分离的系统也能正常运行
-
一个分布式系统最多满足这三个需求中的两个:
-
牺牲一致性来换取可用性的例子:
- 假设有两台机器M1和M2,M1上有副本V1,M2上有副本V2,以及两个进程P1,P2
-
假设M1上有一个进程对副本P1进行更新操作,需要将更新后的值传播到M2机器,进程P2将其从副本v2中读出
-
假设在更新值的传播过程中断,如果要保证可用性,进程p2立即读取v2的值,读到的肯定是不一致的数据;如果需要保证一致性,就一直等到故障恢复后,再从v2中读取数据,中间可能过去了很长时间,无法保证可用性
-
在面对CAP理论的时有以下几种选择:
-
CA:放弃分区容忍性
-
CP:放弃可用性
-
AP:放弃一致性
-
-
不同产品在CAP理论下的不同设计原则
BASE理论:
-
BASE:是Basically Available Soft state和Eventual consistency的简写,意思为“碱”
-
ACID:是关系型数据库的事务的四个性质,NoSQL中的BASE(j碱)和ACID(酸)是对应关系
-
Basically Available:指当分布式系统的一部分发生问题变得不可用时,其他部分仍然可以正常使用、也就是允许分区失败的情形出现
-
Soft state(软状态):
- 硬状态:要求数据库的状态必须一直保持数据一致性,就是任意时刻的数据都是正确的
- 软状态:指状态可以有一段时间不同步,具有一定的滞后性
Eventual consistency(最终一致性):
-
强一致性:执行一个更新操作之后,后续的其他操作都能读到你更新的最终数据
-
弱一致性:执行一个更新操作之后,后续的其他操作不能读到你更新的最终数据;弱一致性可能有一段时间的不一致,但是最终会达到一致状态
-
最终一致性:根据更新数据后各进程访问到数据的时间和方式不同,可以区分为
-
因果一致性
-
“读己之所写”一致性
-
单调读一致性
-
会话一致性
-
单调写一致性
-
-
如何实现各种类型的一致性?
-
假设有一个分布式系统:为了实现它的可靠性,要对数据进行冗余存储
-
假设N表示数据冗余的份数、W表示更新数据时需要保证写完成的节点数,R表示读取数据的时候需要读取的节点数
-
-
实例:
5.5 从NoSQL到NewSQL数据库
- 数据库发展
-
应用场景
-
NewSQL数据库同时具备OldSQL数据库和NoSQL数据库各自的优点
-
具有非常好的水平可扩展性
-
具有强一致性
-
具有事务一致性
-
支持SQL查询
-
支持海量的数据存储
-
-
关系型数据库、NoSQL和NewSQL数据库产品分类图
5.6 文档数据库MongoDB
-
MongoDB简介
-
MongoDB是由C++语言编写的,是一个基于分布式文件存储的开源数据库系统
-
在高负载的情况下,添加更多的节点,可以保证服务器性能
-
MongoDB旨在为WEB应用提供可扩展的高性能数据存储解决方案
-
文档结构:数据结构由键值对组成的MongoDB文档类似于JSON对象
-
-
MongoDB特点:
- 提供一个面向文档存储,操作起来比较简单和容易
- 可以设置任何属性的索引,实现更快的排序
- 具有较好的水平可扩展性
- 支持丰富的查询表达式,可查询文档中内嵌的对象及数组
- 可替换已完成文档某个指定的数据字段
- MongoDB中的MapReduce主要是用来对数据进行批处理和聚合操作
- 安装过程简单
-
MongoDB的概念解析:
-
实例:
-
关系数据库设计以及MongDB设计实例
- 关系表的设计可能设计多表连接查询
-
MongDB使用一个文档就能表现这些信息
-
MgonDB数据库相关结构内容
- 一个MongDB中可以建立多个数据库
- MongoDB的默认数据库为“db”,该数据库存储在data目录中
- MongoDB的单个实例可以容纳多个独立的数据库,每一个都有自己的集合和权限不同的数据库也放置在不同的文件中
-
文档概念:
-
RDBMS与MongoDB对应术语
-
集合概念:集合类似于RDMS中的表格
-
MongoDB shell访问MongoDB
-
使用JAVA程序访问MongoDB
-
环境配置
-
连接数据库
-
创建集合
-
插入文档
-