NoSQL数据库（林子雨慕课课程）-Toy模板网

这篇具有很好参考价值的文章主要介绍了NoSQL数据库（林子雨慕课课程）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

5.1 NoSQL数据库

NoSQL兴起原因1:关系型数据库无法满足Web2.0的需求

很多非关系型数据可以作为关系型数据的补充，很多业务场景下需要用到非关系型数据库
NOSQL数据库特点
- 灵活的可扩展性：有非常强大的水平可扩展性，可以支持在多个机器上水平扩展
- 灵活的数据模型
- 和云计算的紧密结合：
  - 云计算基础设施可以根据负载实时变化，来对底层的IT设施进行动态伸缩，负载增加可以将更多机器加入集群，如果负载减少，可以将相关的机器退出；
  - 传统关系型数据库的纵向可扩展性受到一定的限制，在水平可扩展性更是不具备这个特性，不能和云计算紧密结合
  - NoSQL在设计之初就考虑到了它的水平可扩展性，和云计算是紧密结合的
传统关系型数据库在性能上的缺陷
- 无法满足海量数据的管理需求
- 无法满足高并发的需求
  - 因为动态数据无法提前生成，不能提前生成一个静态网页让用户来访问，只能实时地根据用户的请求来实时的生成数据
  - 这种实时生成的数据，对数据库的负载非常高
  - 基本上用关系型数据库是无法满足高并发的需求
- 无法满足高扩展性和高可用性的需求
  - 中小型企业通过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数据库

NoSQL数据库（林子雨慕课课程）,大数据应用,nosql,数据库

举例

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数据库

数据库发展

NoSQL数据库（林子雨慕课课程）,大数据应用,nosql,数据库

应用场景
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
- 环境配置
- 连接数据库
- 创建集合
- 插入文档
  
  文章来源地址https://www.toymoban.com/news/detail-725359.html