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

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

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 关系型数据库的事务机制 事务是关系型数据库最重要的机制之一l 关系

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

5、L数据库的基本原理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）第2章 NoSQL数据库的基本原理2.

10、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

17、系统有不同的策略。第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 17 2.2.3 一次写入多次读取（WORM）背景：l 典型的大数据场景，如：搜索引擎抓取网页并抽取正文、链接，并不需要修改抓取的原始网页。网站或物联网应用抓取到日志或监控数据，一般只会进行查询、统计、挖掘，也不需要修改原始数据。l 从系统层面，如果数据不需要修改（update、insert或delete），数据的存储、分片和多副本机制可以大为简化。此外可以实现将分片内数据排序等机制，以加快扫描速度。l 应用一次写入多次读取机制，意味着在系统底层只支持新建和追加（append）。此时系统具有更好的顺序存储特性，对

18、于机械硬盘，顺序读写比随机读写的开销更小，硬件损耗更小，出现碎片的可能性较小（需要配合其他机制，详情可以参考第五章描述的HBASE写入机制）。如何在一个只支持append的存储系统上实现数据更新、插入和删除？l 可以采用时间戳机制。从WORM设计，也可以看出NoSQL应用场景和RDBMS存在差异，相互不可替代。第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 18 2.2.4 分布式系统的可伸缩性 背景：分布式系统中可能存在节点故障、以及持续采集数据导致系统容量或处理能力出现瓶颈。目标：l 分布式系统需要提供一种易于操作的增加、移去或替换节点的方法l 节点变动时，数据分片和副本可

19、以自动平衡，空白的新节点会被存入适当的分片副本，移走的节点所负责的数据会被指派给别的节点l 个别节点变动和数据平衡时，对系统服务的影响较小，即节点变化可以动态进行，数据平衡在后台进行（例如：限制数据平衡时使用的带宽，以防止对系统正常服务产生过大影响等）l 节点变化后，用户可以方便的查看当前节点的列表和运行情况第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 19 小结：在分布式数据管理中，需要保持集群的高性能、高可靠性和易用性 进行分布式数据管理的主要目的是通过横向扩展提升数据存储、管理、查询和处理性能l 负载均衡：数据分片，并均匀分布在各个节点上；计算本地化，节点只查询自身的数

20、据l 集群可伸缩：集群规模可以随着数据增长进行横向扩展l 将底层存储设置为“一次写入多次读取”，简化大数据场景下的软件设计难度 由于分布式环境中存在部分节点不可达的可能，因此需要保证部分节点出现故障时，系统的其他部分仍可以正常工作；此外故障最终可以被发现和消除l 容错性：数据多副本，副本存储在不同节点上，多副本之间具有同步更新、冲突检测等机制l 集群可伸缩：可以移除故障节点，替换新节点，并实现数据的再平衡 不能要求用户精通分布式系统原理，或者事先了解集群中的大量细节信息才能使用，系统必须易用l 自动管理副本：自动分片、自动检测副本状态、节点的变化，并平衡数据l 统一访问接口：用户通过统一接口即

21、可访问数据，不必预先知道各个节点的信息或集群拓扑等。第2章 NoSQL数据库的基本原理2.2 分布式数据管理的特点 20 目标l 分布式系统中（特别是NoSQL数据库），数据多副本产生的一致性问题l 进一步的目标：各个节点之间对某一主题达成共识（例如：配置信息更新）概念上的差别（CAP和BASE的概念将在随后解释）l ACID中的一致性：强调（一个或多个）事务前后，数据的状态（约束、完整性等）都是有效的。l CAP中的一致性：强调多个副本是状态一致、同步更新的l BASE中的一致性：和ACID中的一致性相近，但强调弱一致性第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 21

22、2.3.1 CAP理论 CAP是指分布式系统中的Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）。CAP理论是指在分布式系统中，CAP三个特性不可兼得，只能同时满足两个。和RDBMS中的ACID相比较的原因是，理论上分布式系统中多副本的更新应该是一个“事务”，要么都成功，要么都失败，并且性能很好，但实际上存在难题。一些分布式系统可以实现分布式事务（当前大多数NoSQL系统不支持，或不能良好支持），即可以提供跨节点的ACID。CAP则是强调集群环境下，数据多副本带来的问题，此时二者讨论的主题不同。第2章 NoSQL数据库的

23、基本原理2.3 分布式系统的一致性问题CAP理论可参考：Brewers Conjecture and the Feasibility of Consistent，Available，Partition-Tolerant Web Services 22 2.3.1 CAP理论 Consistency（一致性），是指分布式系统中所有节点都能对某个数据达成共识，例如：多个副本内容是否相同，当出现不一致时，以哪个副本为准。Availability（可用性），这里可以理解为分布式系统的响应速度，或响应能力。Partition tolerance（分区容错性），指在部分节点故障、以及出现消息丢包的情况下，

24、集群系统（的剩余部分）仍然可以提供服务，完成数据访问，这一般需要通过合理的数据多副本机制实现。CAP不能兼顾，但并非绝对对立。l 在实际NoSQL系统中，一般通过设计上的取舍和使用过程中的配置，在A和C之间进行权衡l 对于大多数分布式系统，P是必须的l 在系统设计层面，或系统的模块设计层面，以及在不同的业务场景下，都可能采用不同取舍策略或配置策略第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 23 2.3.1 CAP理论 假设系统中，数据只有一个副本。则一致性（C）可以得到绝对的保障，由于在读写时不需要通过网络查询其他副本的情况，因此读写性能较高（A），但如果存储数据的节点故

25、障则无法容错，即该设计兼顾CA。假设系统中，数据存在n个副本，但采用“读写分离”机制，只有一个副本可以接受写请求。此时：l 对于写操作，一致性和可用性较好，因为只要写完一个副本，操作即为成功，但此时该写入节点无法实现分区可用性，即兼顾CA。l 对于读操作，假设数据存在多个“只读”副本，客户端每次只读取其中一个，则该设计实现了读操作的分区可用性（多副本），可用性较好，但客户端无法判断该副本是否为最新的（考虑网络通信的不确定性），即只兼顾了PA。l 对于读操作，假设客户端需要同时读取多个副本，并对比这些副本，以检查是否存在版本差异或版本冲突。则此时兼顾了PC，由于需要读取多个副本，因此客户端响应时

26、间变长，可用性（A）变弱。第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 24 2.3.1 CAP理论 思考：假设在分布式系统中，数据存储为3个副本，每个副本都可以接受读写请求。l 如果强调读操作的PA，应采用何种策略？l 如果强调读操作的PC，应采用何种策略？l 如果强调写操作的PA，应采用何种策略？l 如果强调写操作的PC，应采用何种策略？l 如何在保证P的情况下，希望能够兼顾AC，可以采用何种妥协策略？在“一次写入多次读取”机制下，是否可以讨论写操作的CAP？l 数据分片可能支持Appendl 数据分片可能被整体删除l 数据分片可能在批量更新没有完成时出现网络故障l 针

27、对一条记录，可以通过时间戳+append等机制实现数据改写，从而在多副本之间产生版本差异第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 25 2.3.2 BASE和最终一致性 BASE:An Acid Alternative BASE是一个和ACID相对比的概念，强调弱一致性l ACID指事务的强一致性。在分布式环境下，涉及到网络通信的不可靠性，性能较差，且技术实现复杂。ACID认为事务执行时不应存在中间状态，只有“成功”、“回滚”等最终状态。l BASE强调，在互联网等场景中，用户响应（即可用性）很重要，必须首先满足。最终一致性（Eventual Consistency），

28、即事务存在中间状态，但经历一段时间之后，最终会一致。最终一致性（在一些应用场景下）也可以看作NoSQL允许多个副本可以存在暂时的不同步（即异步更新），结合CAP理论，这种设计强调PA，可以提高响应速度。第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 26 2.3.2 BASE和最终一致性 BASE所强调的软状态、弱一致性等，在一些互联网业务中，并不会带来大的问题。l 例如：一位欧洲用户在社交软件上短时间内更新了多次头像，但他在亚洲的好友即便正在刷新，可能也只能在一段时间后才看到更新的情况，并且只看到了最终的头像，中间的更新结果在服务器同步信息的过程中被覆盖了。弱一致性场景中，

29、经常会使用“异步消息机制”在网络节点之间的进行通信。l 异步消息意味着消息的发送和接受之间存在时间差。消息的发送者在消息发出后立刻退出发送流程，不会阻塞等待接受者的反馈，因此不会受到网络延迟等影响，因此系统的响应时间较少。这也可以看作是一种软状态机制。l NoSQL中也会使用异步消息机制进行事件通知等，但最终用户一般不需要关心其具体过程。第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 27 2.3.2 BASE和最终一致性 BASE所强调的软状态、弱一致性等，在一些互联网业务中，并不会带来大的问题。l 例如：一位欧洲用户在社交软件上短时间内更新了多次头像，但他在亚洲的好友即便

30、正在刷新，可能也只能在一段时间后才看到更新的情况，并且只看到了最终的头像，中间的更新结果在服务器同步信息的过程中被覆盖了。弱一致性场景中，经常会使用“异步消息机制”在网络节点之间的进行通信。l 异步消息意味着消息的发送和接受之间存在时间差。消息的发送者在消息发出后立刻退出发送流程，不会阻塞等待接受者的反馈，因此不会受到网络延迟等影响，因此系统的响应时间较少。这也可以看作是一种软状态机制。l NoSQL中也会使用异步消息机制进行事件通知等，但最终用户一般不需要关心其具体过程。第2章 NoSQL数据库的基本原理2.3 分布式系统的一致性问题 28 假设在读写分离场景下，有一个写节点（称为主节点），

31、和若干个读节点（称为从节点）。当主节点出现故障时，集群如何实现自动的故障恢复？l 可以在从节点中“选举”出一个新的主节点。l 可以由从节点（或若干外部节点）进行自动选举。l 此时需要一个算法（或网络协议），来协调选举者的行为。假设在一个集群环境中，所有节点都需要更新一个配置项，如何自动发现该配置项的更新？l 需要所有节点对“xx配置项更新为xx”，（发现并）达成共识第2章 NoSQL数据库的基本原理2.3.4.Paxos算法简介 29 Paxos是一种基于异步消息的一致性算法（共识算法），主要解决了如下问题：l 如何发起投票，特别是当多个节点希望发起投票时，如何决定投票主题？l 具有投票权的节

32、点如何投票？出现网络故障、延迟或部分节点失效时，投票过程和结果是否还有效？l 如何让“吃瓜群众”（learner）获知投票结果 Paxos“被认为是同类算法中最有效的”，具有多种改进算法（例如：Fast Paxos等）。现有的分布式一致性软件，如：Zookeeper、chubby软件，以及诸如MongoDB等NoSQL数据库中的主节点选举模块，大多使用或借鉴了Paxos（至少是相似的）。第2章 NoSQL数据库的基本原理2.3.4.Paxos算法简介 30 基本角色l 若干proposer（提议者）：proposer负责提出投票提议（proposal），以及给出建议的决议（或称为值，value

33、）。l 若干（一般三个以上的奇数个）acceptor（投票者）：acceptor收到提议后进行投票，以少数服从多数的原则决定是否接受提议，以及是否批准该值。可能还存在下列角色l client客户端：提议的产生者，client将提议提交给任意proposer，由其提交投票。l learner（学习者，有时称observer）：learner只能观察投票结果，并更新自己的认识（值）。l leader：在改进后的Paxos机制中负责。在实际系统中，通常只有客户端和服务器的概念。客户端一般扮演client、proposer和learner的角色，而服务端扮演accepter、coordinator和l

34、eader的角色。此外，一个节点也可能承担多个角色。第2章 NoSQL数据库的基本原理2.3.4.Paxos算法简介 31 第一阶段为发起提议阶段l 反馈的acceptor为半数以上原则，少部分节点失效时，投票仍可以进行l 接受提议的编号为最新原则，确保当前只为一个提议投票，确保当前提议是最新的。l 反馈决议为历史决议或空值原则 第二阶段为决议的批准阶段l proposer决定决议（值）l 反馈的acceptor为半数以上原则l 学习者或客户端只能学习到投票通过的决议（或值）进一步需要解决l 如何防止提升编号抢占提议权？引入leader机制，在第一阶段由leader决定提议。l 如何加快投票过

35、程。（fast Paxos协议）授予leader在第二阶段发生冲突时的决策权。第2章 NoSQL数据库的基本原理2.3.4.Paxos算法简介 32 投票流程：第2章 NoSQL数据库的基本原理2.3.4.Paxos算法简介 33 相当于实现了分布式环境下的ACID，必须全部节点都成功提交更新，整个事务才算成功 存在协调者（左）和参与者（右）两个角色 在不同阶段，不同的角色或通信出现故障，所产生的影响是不同的 大部分NoSQL数据库软件并不直接支持分布式事务提交。因为其阻塞过程对系统的整体性能影响较大第2章 NoSQL数据库的基本原理补充：分布式事务、二阶段提交和三阶段提交两阶段提交过程三阶段

36、提交过程两阶段提交的简要过程如下：1协调者和参与者准备就绪，参与者等待消息。2第一阶段开始:协调者进入PREPARE状态，发送PREPARE消息，协调者等待消息 3参与者收到消息，能够继续执行，则进入READY状态并发送READY指令，否则发送ABORT。消息发送后，将日志写入磁盘，参与者进入阻塞状态等待后续消息。4第二阶段开始:协调者收到所有消息，从PREPARE变更为COMMIT或ABORT状态，相应的发送global_commit或者global_abort指令给所有的参与者。5参与者收到global_commit或者global_abort消息，执行本地事务操作或回滚，同时解除阻塞状态

37、。两阶段提交可以在大多数情况保障分布式事务的原子性，即事务的相关操作要么都成功，要么都失败。分析如下：1两阶段提交中所有的消息等待过程，都可以设置超时。在步骤3、4接收消息时，如果出现超时，则参与者或协调者可以认为对方故障，因而事务失败，并执行相应指令。2在步骤5处，如果参与者一直没有收到global_commit或者global_abort消息，则无法直接判断是否应该中止事务，因为有可能commit消息已经发出，但由于网络问题没有收到，此时有可能其他节点已经进行了commit，也有可能时协调者故障。同理，如果在执行步骤4之后，参与者出现故障，当故障恢复之后，参与者无法判断事务处在何种状态。3

38、如果认为参与者之间可以相互通信，则参与者一直没有收到global_commit或者global_abort消息时，可以向其他参与者发出询问。如果参与者在此过程中出现故障，也可以在故障恢复后，通过向协调者或其他参与者询问的方式恢复事务应有的状态。如果协调者在步骤4出现故障，则可能所有参与者都没有收到步骤5处的global_commit或者global_abort消息。此时会造成参与者一直阻塞，直到协调者恢复（例如通过日志恢复）或有部分参与者收到global_commit或者global_abort消息等。如果有部分参与者还没有进行投票时就出现协调者故障，则在参与者相互协商之后，可中止事务。上述机

39、制称为协同中止机制。两阶段提交的主要问题在于，当第二阶段出现协调者故障时，参与者阻塞时间较长，可能需要协调者完全恢复，参与者才知道要做什么，并解除阻塞。在阻塞期间，参与者无法参与其他事务，也无法执行其他可能破坏事务原子性的操作。针对这个问题，有人提出了三阶段提交方案。三阶段提交的前提是节点可能发生故障，但通信链路不会发生故障。三阶段提交的主要流程为：1第一阶段：协调者发出投票消息，参与者判断自身是否可以提交任务，并反馈给协调者。2第二阶段：如果所有参与者都可以提交，协调者发出PreCommit消息，参与者收到消息后将事务写入日志，并反馈给些调整。3第三阶段：协调者根据情况发出global_co

40、mmit消息，参与者收到消息后进行真正的提交。二阶段提交时，如果在第二阶段出现协调者故障，则参与者必须阻塞等待到超时，在执行协同中止机制，甚至有几率引发更长的阻塞。但在三阶段提交时，如果参与者没有收到第二阶段的PreCommit消息，或协调者没能收到全部的PreCommit回复，都可以判定提交失败，而不需要协同中止。如果在收到PreCommit之后，参与者没有收到global_commit，也可以之际提交任务，因为收到PreCommit即表示所有参与者都承诺可以提交任务，此时不存在不确定性，不需要阻塞等待。三阶段提交以更大的网络开销，降低了参与者处在不确定状态的时间，使得发生故障时的阻塞时间更

41、短。但是在故障率较低的场景下，为降低网络开销，二阶段提交应用的更加广泛。36 NoSQL并没有一个统一的存储模式，底层存储引擎的实现差异很大，具体策略和配置方式也因软件而异。常见的存储模式有：键值模式、列存储模式、文档存储模式和图存储模式等。常见的NoSQL软件可能会结合使用多种存储模式，例如键值对和列存储。这些存储模式在底层大多是一次写入多次读取的。除了图存储模式之外，大多对分布式环境支持较好。这些存储模型之上，一般只支持简单的查询，对关联查询等支持较差。这些存储模型对索引（例如：二级索引）的支持较差。第2章 NoSQL数据库的基本原理2.4 NoSQL的常见存储模式 37 NoSQL并没有

42、一个统一的存储模式，底层存储引擎的实现差异很大，具体策略和配置方式也因软件而异。常见的存储模式有：键值模式、列存储模式、文档存储模式和图存储模式等。常见的NoSQL软件可能会结合使用多种存储模式，例如键值对和列存储。这些存储模式在底层大多是一次写入多次读取的。除了图存储模式之外，大多对分布式环境支持较好。这些存储模型之上，一般只支持简单的查询，对关联查询等支持较差。这些存储模型对索引（例如：二级索引）的支持较差。第2章 NoSQL数据库的基本原理2.4 NoSQL的常见存储模式 38 NoSQL并没有一个统一的存储模式，底层存储引擎的实现差异很大，具体策略和配置方式也因软件而异。常见的存储模式

43、有：键值模式、列存储模式、文档存储模式和图存储模式等。常见的NoSQL软件可能会结合使用多种存储模式，例如键值对和列存储。这些存储模式在底层大多是一次写入多次读取的。除了图存储模式之外，大多对分布式环境支持较好。这些存储模型之上，一般只支持简单的查询，对关联查询等支持较差。这些存储模型对索引（例如：二级索引）的支持较差。第2章 NoSQL数据库的基本原理2.4 NoSQL的常见存储模式 39 2.4.1 键值对存储模式 所谓键值对，即（物理上）每行数据的结构为：，或者等形式。l Key相当于主键l 如果有多个Key相同的键值对，则被看作在逻辑上是一行数据，或者被认为是该value的更新历史（以

44、时间戳决定版本新旧）l Value一般较为自由，不限定数据类型、值域等，很难对Value建立索引。l 没有列或列名的概念，列名可能显式的现在value中，例如：，即key为 编号001，value包含了列名（姓名）和取值（张三）。在实际系统中，一般会根据key进行数据分片内的局部排序，以加快检索效率 Redis、HBase、Cassandra等使用该存储模式第2章 NoSQL数据库的基本原理2.4 NoSQL的常见存储模式 40 2.4.2 文档式存储模式 可以看作键值对模式的升级，底层存储的每行数据中仍然存在key（或者ID）和value。但Value是采用JSON等格式描述的复杂数据类型

45、每条数据的文档格式可以不同 文档格式中支持嵌套等复杂形式 比较有名的文档式数据库，如MongoBD和CouchDB等第2章 NoSQL数据库的基本原理2.4 NoSQL的常见存储模式这是MongoDB中的一行数据，描述一条通信录数据。数据包含_id、username、contact和access列，contact和access列是复合列，不满足关系型数据库中的列的原子性JSON是一种轻量级的数据交换语言。JSON最被熟知的应用之一，是作为JavaScript语言中的对象和数组，这从它的英文名也可以看出。JSON也被用来在RESTFUL风格的Web接口中进行数据交换。JSON对数据的组织方法和X

46、ML类似，独立于语言，具有自我描述性，但是比XML更简洁，对结构的要求也没有那么严谨，如下面的例子：“mail”:“from”:“Alice”,”to”:“Bob”,“head”:“This is an email”,“body”:“Hello!This is an email.”,“attachment”:“Hello!This is an attachment.”“comment”:“This is a comment”JSON中的元素可以看作是一种键值对的描述方式，以“：”为间隔，前面是键后面是值，键需要用双引号包括。JSON支持一些数据简单的数据类型，如：整数或浮点数：“year”:2

47、018 字符串：“year”:“2018”对象：“year”:“2018”，“month”:“Jan”，“dayofmonth”:“1”逻辑值：“IsHoliday”:true空值：“IsHoliday”:null数组：“week”:“Mon”,“Tue”,“Wed”,“Thu”,“Fri”,“Sat”,“Sun”一般认为，描述相同的数据结构，JSON比XML更加简洁，JSON的存储和处理效率更高。JSON支持一些简单的数据类型，因此在描述数据时更加方便。JSON没有保留字，不要求严格的树形结构。用javascript、Python等常见高级语言，可以非常方便地解析JSON数据。42 2.4.

48、3 列存储模式 可以看作是一种纵向切分数据的方式，不同列会放到不同的位置（节点）存储，实际软件一般也会按照行键（key）再进行横向切片和分布式存储。对于稀疏表（空值较多），其存储效率较高 底层一般也是一次写入多次读取的 在切片内一般会按行键进行排序，以加快分布式检索速度。比较有名的列存储数据库，如谷歌的Big Table和Dremal，以及HBase等。第2章 NoSQL数据库的基本原理2.4 NoSQL的常见存储模式面向行和面向列存储的对比Dremel列存储架构简介（1）Dremel是谷歌研发的交互式数据分析系统，谷歌在2006年撰写、并2010年公开的论文Dremel:Interactiv

49、e Analysis of Web Scale Datasets介绍了这个系统。Apache Drill和Cloudera Impala则是基于Dremel模型实现的开源分布式数据仓库软件的典型代表。Dremel采用了列存储机制，此外Dremel中的每条记录也可以看作文档型记录，下面对其存储架构做一个介绍：假设有两个文档类型的记录，r1和r2，如图所示：Dremel列存储架构简介（2）r1和r2表示的是两个网页的部分信息数据。其结构参见右上角的“Documents”格式（schema），这个格式采用个谷歌的proto buffer格式构建。这两个记录显然不满足列的原子性原则。结构中出现了嵌套的

50、字段，例如“Name”，格式定义中的“group”表明其可以嵌套。结构中具有可以重复的字段如“Language”，在格式定义时，“Language”前面的“repeat”关键字说明该情况，注意其重复次数是不固定的，最少可以是零次。结构中的“DocId”字段必须存在（“required”），其他的字段都是可选的，在格式定义中的“option”说明该情况。“Forward”和“backward”字段的数值是其他记录的“DocId”。此外，r1和r2的信息内容差别很大，如果以面向行的方式存储，则r2可能存在大量空值。且支持“repeat”的字段，可能需要采用多个表实现。Dremel列存储架构简介（3