文章目录
-
-
- [5.1 NoSQL数据库](#5.1 NoSQL数据库)
- [5.2 NoSQL和关系数据库的比较](#5.2 NoSQL和关系数据库的比较)
- [5.3 四大类型NoSQL数据库](#5.3 四大类型NoSQL数据库)
-
- [5.3.1 键值数据库和列族数据库](#5.3.1 键值数据库和列族数据库)
- [5.3.2 文档数据库、图数据库、以及不同数据库比较分析](#5.3.2 文档数据库、图数据库、以及不同数据库比较分析)
- [5.4 NoSQL数据库的理论基石](#5.4 NoSQL数据库的理论基石)
- [5.5 从NoSQL到NewSQL数据库](#5.5 从NoSQL到NewSQL数据库)
- [5.6 文档数据库MongoDB](#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
-
环境配置
-
连接数据库
-
创建集合
-
插入文档
-