NoSQL数据库（林子雨慕课课程）_林子雨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数据库

• 举例

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

  • 环境配置

    

  • 连接数据库

    

  • 创建集合

    

  • 插入文档