NoSQL数据库原理-NoSQL数据库的基本原理

10
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾 Ø 2.1.4 关系型数据库的分布式部署 Ø MySQL Fabric方案
l MySQL官方方案 l 支持水平分片（Shard x） l 支持主从数据库（
Primary/Secondary）
MySQL Fabric的架构图
11
2.1 关系型数据库的重要机制回顾
Ø 2.1.4 关系型数据库的分布式部署
Ø 主从集群（读写分离） l 无法解决写数据的瓶颈，但保持 了对单机事务的支持 l 读数据时，可以实现一定的负载 均衡，提高并发性能，并且可以 提供一定的容错机制 l 一般来说从服务之间是不共享数 据的，每台从服务器都保存全集 数据，一般不会进行数据分割 l 主从服务器之间可能存在数据不 一致的隐患
7
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.4 关系型数据库的分布式部署 Ø 分布式环境下，数据存储存储在不同节点，此时必须通过网络传递相关消息，
如果出现网络故障或部分节点失效，则有可能导致整个系统变得低效或死锁， 因此在分布式环境下实现高效率的事务机制、以及强一致性等特性较为困难。 Ø 关系型数据库目前也存在多种横向扩展方案
Ø 分布式环境下实现事务和锁，可能出现什么问题？
6
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.4 关系型数据库的分布式部署
Ø 关系型数据库一般部署在单机上，并通过垂直扩展（scale up）方式提升性能
Ø 一些关系型数据库也可以实现水平扩展，一般需要通过外部软件、或用户编程等 方式实现。 l （1）将不同的表存储在不同节点。如果某个表体积过大、或频繁被访问，则 其他节点无法提供帮助。 l （2）水平分割数据，将表中不同的行存储在不同节点上。在RDBMS中需要 保持数据的完整性，插入数据时需要检查所有节点上的数据。索引、锁等机 制的维护也较为繁琐。 l （3）垂直分割数据，将表中不同的列存储在不同节点上。在大数据场景下， 表中的行数可能仍然过多，热点数据可能无法做到负载均衡。也可能遇到和 水平分割数据类似的问题。
3
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.2 关系型数据库的完整性约束
辑定义的完整性约束。
Ø 关系模型中的完整性约束
Ø NoSQL中的完整性约束
l 域完整性：是指对列的值域、类型等
l 域完整性一般较弱，或不支持
进行约束。
l 可能存在主键相同的行，或内容相同
l 实体完整性：实体集中的每个实体都
Ø 解决：将数据存储为多个副本，不同的副本存储在不同节点上，通常是以数据 分片为单位实现多副本。 l 相对于原始文件或整个表格，分片的体积较小，容易被检测、拷贝 l 理论上n个副本都可以被读取，但n个副本是否可以被更新，则要视系统实 现和用户策略而定 l 例如：HDFS中，基于“机架感知”的三副本机制。
但时间戳不同的行等情况，一般不会
具有唯一性标识，或者说数据表中的
出现空的主属性
每个元组是可区分的。这意味着数据
l 一般不提供参照完整性，或者外键，
表中存在不能为空的主属性（即主键 ）。
因此一般也不支持跨表的关联查询（ Join）
l 参照完整性：表明表1中的一列A依 赖于表2中被参照列的情况。
l 用户定义完整性靠应用程序支持
l 横向扩展可以提供负载均衡能力，例如：将数据进行垂直节分或水平切分。 l 横向扩展可以提供一定的容错能力，例如：采用读写分离机制。 l 灵活运用上述方案，可以在很多应用场景中解决问题，但是当数据量持续
增大时，则可能无法应对。 l 运用上述方案时，用户可能仍需要进行较多的应用架构设计与编程工作
8
第2章 NoSQL数据库的基本原理
16
第2章 NoSQL数据库的基本原理
2.2 分布式数据管理的特点
Ø 2.2.2 数据多副本
Ø 背景：在大规模分布式系统中，要将部分节点失效视为“常态”，而非异常。 此时必须考虑集群系统在局部故障的情况下，也能够正常运行。 l 故障可能是临时的，也可能时永久的，例如：节点死机、节点硬盘故障、 网络雍塞、交换机故障等
例如：Microsoft SQL Server提供了 “Database Mirroring”、“log shipping”、发布订阅、“always on”等多种读写分离策略
利用分发服务器实现主从数据同步
9
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.4 关系型数据库的分布式部署 Ø 分布式中间件 Ø 例如：MySQL Fabric、MySQL Cluster、阿里的
l 用户定义的完整性：用户根据业务逻
4
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.3 关系型数据库的事务机制
Ø 事务是关系型数据库最重要的机制之一 l 关系型数据库会对并发操作进行控制，防止用户在存取数据时破坏数据的完 整性，造成数据错误。 l 事务机制可以保障用户定义的一组操作序列作为一个不可分割的整体提交执 行，这一组操作要么都执行，要么都不执行，当事务执行成功，我们认为事 务被整体“提交”，则所有数据改变均被持久化保存，而当事务在执行中发 生错误时，事务会进行“回滚”，返回到事务尚未开始执行的状态。
13
第2章 NoSQL数据库的基本原理
2.2 分布式数据管理的特点
Ø 2.2.1 数据分片
Ø 目的 l 使数据均匀分布到多个节点上，执行查询或处理任务时，各个节点只查询自身数据，实 现并行处理 • 跨表联合查询性能？由于需要在多个节点之间计算笛卡儿积，因此性能很差，大 部分NoSQL并不支持。 l 当运行分布式查询或处理任务时，每次处理一个分片，将一个分片一次性读入内存 • 例如HBASE（借助于HDFS），将数据分片为64MB-256MB大小。
15
第2章 NoSQL数据库的基本原理
2.2 分布式数据管理的特点 Ø 2.2.1 数据分片 Ø 问题：如果部分节点出现故障，数据或查询任务是否会出现缺失？如何解决？
l 当数据库为单机部署时，不存在系统部分故障的问题，系统要么100%正 常，要么100%失效，此时可以通过主备服务器等方式提高系统的可靠性
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.4 关系型数据库的分布式部署
Ø MySQL Cluster方案 l 数据保存在“NDB Cluster”，并尽量 将数据写入内存 l 表结构保存在“MySQL Server” l 应用程序通过“MySQL Server”访问 数据表 l 管理客户端通过管理工具(ndb_mgmd) 管理“NDB存储服务器”。 l 管理配置较为复杂，功能受到一定限制
Ø 架构 l 主从架构：主节点负责存储元数据，和客户端访问接口，从节点负责存储数据分片，如： HBase l 对等结构：无主节点，各个节点都可以接受客户端访问请求，如果自身没有存储相关分 片，则去该节点回去向其他节点查询数据，如：Cassandra
14
第2章 NoSQL数据库的基本原理
2.2 分布式数据管理的特点
2.1 关系型数据库的重要机制回顾
Ø 2.1.1 关系模型
Ø 关系模型中的常见特征 l 关系模型中具有明确的表结构 l 列具有原子性，不可再分割 l 列的值域和类型时固定的 l 如果某字段出现空值，一般会保留存储空间(NULL)，以便今后插入数值
Ø NoSQL可能打破这些特征 l NoSQL中可能没有明确的结构 l 列可能是复合型的 l 列中的内容和类型可能是随意的、无定义的 l 不会为空值流出存储空间，可能很难直接插入数值
Ø 2.1.3 关系型数据库的事务机制
Ø 并发控制和封锁机制 l 并发调度指将多个事务串行化，并发控制则强调解决共享资源并发存取过 程中产生的各类问题 • 丢失更新、幻读、脏读…… l 封锁是数据库中所采用的常见并发控制。封锁是一种软件机制，使得当某 个事务访问某数据对象时，其他事务不能对该数据进行特定的访问。 • 共享锁、排它锁…… l 死锁和预防死锁 • 顺序加锁、超时法、等待图法……
NoSQL数据库原理 NoSQL数据库的基本原理
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
Ø 2.1.1 关系模型 Ø （1）实体（Entity）：是指现实世界中的具体或抽象的事物。例如：一个学
生、一个教师、一门课程等。 Ø （2）属性（Attribute）：对实体的特性进行描述，例如学生的学号、班级、
姓名等。属性一般要求具有原子性，即不可再分割。属性具有值域和数据类型 两种特性。 Ø （3）实体标识符：能够唯一标识一个实体的属性称为实体标识符，例如学生 的学号，即数据库实现中的键（key）的概念。 Ø （4）联系（Relation）：实体之间的关系，以及实体内部属性之间的关系。
2
第2章 NoSQL数据库的基本原理
MySQL Cluster
12
第2章 NoSQL数据库的基本原理
2.2 分布式数据管理的特点
Ø NoSQL中的数据：结构复杂、数据量大
Ø NoSQL一般采用分布式部署，为保证效率、 可靠性等，一方面弱化RDBMS中的部分特 性，另一方面哈需要接入分布式部署中遇 到的各种难题： l 数据均匀、分布式存储，统一使用、 管理数据 l 系统可伸缩（横向增加节点或替换故 障节点） l 存储和查询任务的容错性 l 录入、查询数据时的高性能 l 提高系统的易用性
Ø ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、 持久性（Durability）。 l ACID是典型的强一致性要求 l ACID是大多数NoSQL抛弃的机制，因为无法在分布式环境中保证效率
5
第2章 NoSQL数据库的基本原理
2.1 关系型数据库的重要机制回顾
17
第2章 NoSQL据多副本
Ø 进一步的问题：假设分片被复制了n份，存储在不同节点上，当一个副本被更 新时，其他副本如何同步？如果在更新同步时出现临时或永久故障，如何解决 ？用户是否需要了解，或如何了解副本的同步情况？
l 如果n个副本只有一个能被更新，则该机制就是“读写分离”，此时，如果“读” 副本出现临时故障，则在故障恢复后可以再向主节点查询并同步数据。如果“读” 副本出现永久故障，则系统一般会在其他节点上建立新的副本。如果“写”副本出 现故障，则系统无法继续更新数据，此时需要通过“选举”等机制，建立一个新的 “写”副本。
Cobar(疑似已停止更新) Ø 一般可以实现数据水平拆分、容错、数据路由等功能， Ø 中间件实现难度较大，中间件实际上承担了NoSQL数
据库的大部分功能，关系型数据库只用来实现数据分 片的存储， Ø 用户配置、使用均较为复杂 Ø 系统功能受到一定限制（和单机部署的RDBMS相比）
分布式中间件实现关系型数据 库的分布式
Ø 2.2.1 数据分片
Ø 重要机制 l 如果原始数据是一个大型文件（比如TXT换格式的100GB的网站日志文件） ，则需要将数据切分 • 大数据工具存储日志类数据时，可以根据自然的行进行切分 • 数据导入NoSQL之后，可以根据记录的行进行切分 l 当节点数量变化时，分片的存储位置等应该可以调整（到其他节点） l 节点对自身存储的分片负责，循环检查数据分片是否健康，节点一般不关 心其他节点上分片存储 l 切分过程、分片的调整过程等应当是自动的，用户不需要手动处理分片 l 用户访问一个接口，即可访问所有数据，用户不需要知道数据属于哪个分 片，存储在哪个节点上。
假设某个NoSQL数据库将数据均 匀存储在n个节点上，此时可能出 现各种难题或故障： • 如何查看整个集群还有多少存
储空间？ • 如何在整个集群不停止工作下，
快速、方便的增加节点？或者 如何尽量减少增加、删除节点 所需的时间和工作量？ • 某个节点出现硬盘故障，如何 保证数据不缺失？ • 执行查询任务时，某个节点没 有回应，如何保证查询结果没 有缺失？ • ……
l 如果n个副本都可以被更新，则可能多个副本之间可能存在数据版本”分叉“（冲 突），此时需要额外机制检测到分叉，并消除。（参见第六章的Dynamo机制）