NoSQL数据库原理第二章NoSQL数据库的基本原理.pptx

《NoSQL数据库原理第二章NoSQL数据库的基本原理.pptx》由会员分享，可在线阅读，更多相关《NoSQL数据库原理第二章NoSQL数据库的基本原理.pptx（60页珍藏版）》请在第壹文秘上搜索。

1、NoSQL数据库原理第2章 NoSQL数据库的基本原理 2 2.1.1 关系模型 （1）实体（Entity）：是指现实世界中的具体或抽象的事物。例如：一个学生、一个教师、一门课程等。 （2）属性（Attribute）：对实体的特性进行描述，例如学生的学号、班级、姓名等。属性一般要求具有原子性，即不可再分割。属性具有值域和数据类型两种特性。 （3）实体标识符：能够唯一标识一个实体的属性称为实体标识符，例如学生的学号，即数据库实现中的键（key）的概念。 （4）联系（Relation）：实体之间的关系，以及实体内部属性之间的关系。第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾

2、 3 2.1.1 关系模型 关系模型中的常见特征l 关系模型中具有明确的表结构l 列具有原子性，不可再分割l 列的值域和类型时固定的l 如果某字段出现空值，一般会保留存储空间(NULL)，以便今后插入数值 NoSQL可能打破这些特征l NoSQL中可能没有明确的结构l 列可能是复合型的l 列中的内容和类型可能是随意的、无定义的l 不会为空值流出存储空间，可能很难直接插入数值第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾 4 2.1.2 关系型数据库的完整性约束 关系模型中的完整性约束l 域完整性：是指对列的值域、类型等进行约束。l 实体完整性：实体集中的每个实体都具有唯一

3、性标识，或者说数据表中的每个元组是可区分的。这意味着数据表中存在不能为空的主属性（即主键）。l 参照完整性：表明表1中的一列A依赖于表2中被参照列的情况。l 用户定义的完整性：用户根据业务逻辑定义的完整性约束。 NoSQL中的完整性约束l 域完整性一般较弱，或不支持l 可能存在主键相同的行，或内容相同但时间戳不同的行等情况，一般不会出现空的主属性l 一般不提供参照完整性，或者外键，因此一般也不支持跨表的关联查询（Join）l 用户定义完整性靠应用程序支持第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾 5 2.1.3 关系型数据库的事务机制 事务是关系型数据库最重要的机制之

4、一l 关系型数据库会对并发操作进行控制，防止用户在存取数据时破坏数据的完整性，造成数据错误。l 事务机制可以保障用户定义的一组操作序列作为一个不可分割的整体提交执行，这一组操作要么都执行，要么都不执行，当事务执行成功，我们认为事务被整体“提交”，则所有数据改变均被持久化保存，而当事务在执行中发生错误时，事务会进行“回滚”，返回到事务尚未开始执行的状态。 ACID：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。l ACID是典型的强一致性要求l ACID是大多数NoSQL抛弃的机制，因为无法在分布式环境中保证效率第2

5、章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾 6 2.1.3 关系型数据库的事务机制 并发控制和封锁机制l 并发调度指将多个事务串行化，并发控制则强调解决共享资源并发存取过程中产生的各类问题 丢失更新、幻读、脏读l 封锁是数据库中所采用的常见并发控制。封锁是一种软件机制，使得当某个事务访问某数据对象时，其他事务不能对该数据进行特定的访问。 共享锁、排它锁l 死锁和预防死锁 顺序加锁、超时法、等待图法分布式环境下实现事务和锁，可能出现什么问题？第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾 7 2.1.4 关系型数据库的分布式部署 关系型数据库一般部署在

6、单机上，并通过垂直扩展（scale up）方式提升性能 一些关系型数据库也可以实现水平扩展，一般需要通过外部软件、或用户编程等方式实现。l （1）将不同的表存储在不同节点。如果某个表体积过大、或频繁被访问，则其他节点无法提供帮助。l （2）水平分割数据，将表中不同的行存储在不同节点上。在RDBMS中需要保持数据的完整性，插入数据时需要检查所有节点上的数据。索引、锁等机制的维护也较为繁琐。l （3）垂直分割数据，将表中不同的列存储在不同节点上。在大数据场景下，表中的行数可能仍然过多，热点数据可能无法做到负载均衡。也可能遇到和水平分割数据类似的问题。 分布式环境下，数据存储存储在不同节点，此时必须

7、通过网络传递相关消息，如果出现网络故障或部分节点失效，则有可能导致整个系统变得低效或死锁，因此在分布式环境下实现高效率的事务机制、以及强一致性等特性较为困难。 关系型数据库目前也存在多种横向扩展方案l 横向扩展可以提供负载均衡能力，例如：将数据进行垂直节分或水平切分。l 横向扩展可以提供一定的容错能力，例如：采用读写分离机制。 灵活运用上述方案，可以在很多应用场景中解决问题，但是当数据量持续增大时，则可能无法应对。 运用上述方案时，用户可能仍需要进行较多的第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾 8 2.1.4 关系型数据库的分布式部署 主从集群（读写分离）l 无法

8、解决写数据的瓶颈，但保持了对单机事务的支持l 读数据时，可以实现一定的负载均衡，提高并发性能，并且可以提供一定的容错机制l 一般来说从服务之间是不共享数据的，每台从服务器都保存全集数据，一般不会进行数据分割l 主从服务器之间可能存在数据不一致的隐患第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾利用分发服务器实现主从数据同步例如：Microsoft SQL Server提供了“Database Mirroring”、“log shipping”、发布订阅、“always on”等多种读写分离策略 9第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾分布式中

9、间件实现关系型数据库的分布式 2.1.4 关系型数据库的分布式部署 分布式中间件 例如：MySQL Fabric、MySQL Cluster、阿里的Cobar(疑似已停止更新) 一般可以实现数据水平拆分、容错、数据路由等功能， 中间件实现难度较大，中间件实际上承担了NoSQL数据库的大部分功能，关系型数据库只用来实现数据分片的存储， 用户配置、使用均较为复杂 系统功能受到一定限制（和单机部署的RDBMS相比） 10 2.1.4 关系型数据库的分布式部署 MySQL Fabric方案l MySQL官方方案l 支持水平分片（Shard x）l 支持主从数据库（Primary/Secondary）第

10、2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾MySQL Fabric的架构图 11 2.1.4 关系型数据库的分布式部署 MySQL Cluster方案l 数据保存在“NDB Cluster”，并尽量将数据写入内存l 表结构保存在“MySQL Server”l 应用程序通过“MySQL Server”访问数据表l 管理客户端通过管理工具(ndb_mgmd)管理“NDB存储服务器”。l 管理配置较为复杂，功能受到一定限制第2章 NoSQL数据库的基本原理2.1 关系型数据库的重要机制回顾MySQL Cluster 12 NoSQL中的数据：结构复杂、数据量大 NoSQL一般

11、采用分布式部署，为保证效率、可靠性等，一方面弱化RDBMS中的部分特性，另一方面哈需要接入分布式部署中遇到的各种难题：l 数据均匀、分布式存储，统一使用、管理数据l 系统可伸缩（横向增加节点或替换故障节点）l 存储和查询任务的容错性l 录入、查询数据时的高性能l 提高系统的易用性第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点假设某个NoSQL数据库将数据均匀存储在n个节点上，此时可能出现各种难题或故障：如何查看整个集群还有多少存储空间？如何在整个集群不停止工作下，快速、方便的增加节点？或者如何尽量减少增加、删除节点所需的时间和工作量？某个节点出现硬盘故障，如何保证数据不缺失？执

12、行查询任务时，某个节点没有回应，如何保证查询结果没有缺失？ 13 2.2.1 数据分片 目的l 使数据均匀分布到多个节点上，执行查询或处理任务时，各个节点只查询自身数据，实现并行处理 跨表联合查询性能？由于需要在多个节点之间计算笛卡儿积，因此性能很差，大部分NoSQL并不支持。l 当运行分布式查询或处理任务时，可以每次处理一个分片，将一个分片一次性读入内存例如HBASE（借助于HDFS），将数据分片为64MB-256MB大小。 架构l 主从架构：主节点负责存储元数据，和客户端访问接口，从节点负责存储数据分片，如：HBasel 对等结构：无主节点，各个节点都可以接受客户端访问请求，如果自身没有存

13、储相关分片，则去该节点回去向其他节点查询数据，如：Cassandra第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 14 2.2.1 数据分片 重要机制l 如果原始数据是一个大型文件（比如TXT换格式的100GB的网站日志文件），则需要将数据切分 大数据工具存储日志类数据时，可以根据自然的行进行切分 数据导入NoSQL之后，可以根据记录的行进行切分l 当节点数量变化时，分片的存储位置等应该可以调整（到其他节点）l 节点对自身存储的分片负责，循环检查数据分片是否健康，节点一般不关心其他节点上分片存储l 切分过程、分片的调整过程等应当是自动的，用户不需要手动处理分片l 用户访问一个

14、接口，即可访问所有数据，用户不需要知道数据属于哪个分片，存储在哪个节点上。 问题：如果部分节点出现故障，数据或查询任务是否会出现缺失？如何解决？l 当数据库为单机部署时，不存在系统部分故障的问题，系统要么100%正常，要么100%失效，此时可以通过主备服务器等方式提高系统的可靠性第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 15 2.2.2 数据多副本 背景：在大规模分布式系统中，要将部分节点失效视为“常态”，而非异常。此时必须考虑集群系统在局部故障的情况下，也能够正常运行。l 故障可能是临时的，也可能时永久的，例如：节点死机、节点硬盘故障、网络雍塞、交换机故障等 解决：将数

15、据存储为多个副本，不同的副本存储在不同节点上，通常是以数据分片为单位实现多副本。l 相对于原始文件或整个表格，分片的体积较小，容易被检测、拷贝l 理论上n个副本都可以被读取，但n个副本是否可以被更新，则要视系统实现和用户策略而定l 例如：HDFS中，基于“机架感知”的三副本机制。 进一步的问题：假设分片被复制了n份，存储在不同节点上，当一个副本被更新时，其他副本如何同步？如果在更新同步时出现临时或永久故障，如何解决？用户是否需要了解，或如何了解副本的同步情况？第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 16 2.2.2 数据多副本 进一步的问题：假设分片被复制了n份，存储在

16、不同节点上，当一个副本被更新时，其他副本如何同步？如果在更新同步时出现临时或永久故障，如何解决？用户是否需要了解，或如何了解副本的同步情况？l 如果n个副本只有一个能被更新，则该机制就是“读写分离”，此时，如果“读”副本出现临时故障，则在故障恢复后可以再向主节点查询并同步数据。如果“读”副本出现永久故障，则系统一般会在其他节点上建立新的副本。如果“写”副本出现故障，则系统无法继续更新数据，此时需要通过“选举”等机制，建立一个新的“写”副本。l 如果n个副本都可以被更新，则可能多个副本之间可能存在数据版本”分叉“（冲突），此时需要额外机制检测到分叉，并消除。（参见第六章的Dynamo机制）l 用户是否需要了解副本同步情况，不同的NoSQL系统有不同的策略。第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 17 2.2.3 一次写入多次读取（WORM） 背景：l 典型的大数据场景，如：搜索引擎抓取网页并抽取正文、链接，并不需要修改抓取的原始网页。网站或物联网应用抓取到日志或监控数据，一般只会进行查询、统计、挖掘，也不需要修改原始数据。l 从系统层面，如果数据不需要修改（upd