14-1 键值数据库ppt课件
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
12
13
• 图1显示的是Amazon平台的抽象架构，其中 ，动态网页内容由网页渲染服务组件产生，而 网页渲染服务又由其它服务提供，一个服务可 以由不同的数据存储来管理其状态，而这些数 据的存储只能在其服务范围内被访问。有些服 务担当聚集者的角色，通过使用不同的其它服 务来产生一个复杂的响应。基本上，聚集服务 是无状态的，尽管它们使用缓存.
• 分布式文件系统和数据库(P2P)
– 与只支持平面层的命名空间的点对点系统相比，分 布式文件系统一般是支持目录树架构的命名空间。
16
讨论
• 首先，Dynamo的目标应用是“永远可写”的应用程序 ，以便对用户的更新请求或并发写不会拒绝。
• 其次，如前所述，Dynamo部署在内部可信安全的 基础设施之上。
• Amazon面临的更具体的问题
– 可靠性 – 可扩展性 – Amazon的经验：上述依赖于应用的状态管理 – Amazon的特殊要求：应用总在线——可用性
怎么利用对象版本？对象存储与块存储到底意味着什么？ 8
• Amazon的具体问题是：
Amzon的电子商务平台由成百上千个服务——包 括购物建议、订单提交和错误侦测等组成。每项服务都 由分散在世界各地的数据中心通过网络来提供接口。这 些服务有些是无状态的(比如说：只聚集来自其它服务的 响应)，有些是有状态的(如根据其固化存储的状态来执 行业务逻辑所产生的的响应)；对于传统的存储状态所使 用的关系型数据库，操作的复杂和硬件成本的昂贵是使 其是低效的。(这个，在自己教学实践中倒是有体会)， 同时扩展性差
– 数据的分布和复制采用一致性Hash[10] – 读数据的一致性由对象版本来保证[12] – 数据更新期间数据副本的一致性由类似投票机
制和离散化副本同步协议来保证 – 成员关系和失效检测由基于闲聊的协议保证
上小节我的问题：在存储系统中，应用程序状态意味着什么?
10
系统预设和要求
• 此类服务的存储系统有以下要求：
一个结点负责的虚拟结点的数量可以根据其容量 来决定,这样，也就顾及到其物理基础设施
20
副本策略
• 每个数据项被复制到N台主机上。而每个键 ，K,被分配给协调器结点，协调器结点负责 落在其范围内的数据项的键。而且，为了 局部存储落在其范围内的键，协调器将这 些键顺时针方向复制到其它的环上后继N-1 个结点。这样，每个结点负责它和它的第N 个前继结点范围内的数据项。
• 在Dynamo中，当客户端要更新一个系统时 ，它必须指明它正在更新哪一个版本。通 过将其从早期读操作获得的上下文信息下 传，可以做到这一点
• 最好是限制向量时钟的大小，因此， Dynamo使用时钟截断模式：在有每一个 (node,counter)对时，Dynamo 还存储了结 点更新该数据项时的最后时间。
28
成员维护和故障检测
• 基于闲聊的协议将成员变更和最终成员的一致 性视图广播出去。
– 每隔2秒，结点会与其随机选择的对等结点联系， 然后它们之间相互交换信息，并且它们之间彼此保 持成员信息的同步
• 为了防止结点故障造成的信息孤岛，一些 Dynamo结点作为种子结点。所谓的种子结点 即那些可由外部机制发现并且为所有结点感知 的结点。
证数据的完整性
来自亚马逊的Dynamo项目
4
5
6
Voldemort 使用
value = store.get(key) store.put(key, value) store.delete(key)
7
Dynamo问题产生(研究的来源)
• 对于分布式存储(或者说是”云存储”)的共有的 目标
– 可靠性 – 可扩展性
• 存储系统在建立服务等级协议上扮演重要角色 尤其是当服务逻辑相对权重较轻时(就像 Amazon的许多业务)，状态管理成为一项服 务的服务等级协议的重要组件.
14
设计细节
• 对冲突的解决办法引入了两个问题：什么时候去解决它们；由谁负责 解决。
– 一个重要的设计考虑是什么时候解决更新的冲突？也就是说，是否应该 在读和写的时候就解决冲突。
客户端体验的解决办法。 其它主要考虑的还有：
向量可扩展性 对称性 去中心化 异质性
15
相关研究(本系统思想来源)
• 点对点系统(P2P)
– 第一代点对点系统，是非结构化的点对点网络，其 特点是整个层的网络是网状的，一个查询在整个网 络中流动
– 接下来的点对点系统，即结构化的点对点系统，其 特点是网络采用了全局一致性协议来保证任何结点 都可以有效地将其查询路由到目的结点。
– 然而，版本分化同样可能会出现，当并发的更新失败 时，可能会导致一个版本的冲突。在这种情况下，系 统并不能来和解一个对象的不同版本，此时，将由客 户端来融合所有的版本来达到一个最终版本
23
• Dynamo使用向量时钟来捕捉一个对象不同 版本间的因果关系。一个向量时钟是有效 的一列(node,counter)元组对。一个向量时 钟与一个对象的不同版本一一对应。
24
25
Get()和put()操作的执行
• Dynamo中的任何数据都能够接受来自客户端的对 任何键的get()和put()操作
• 客户端操作get()和put()有两种策略:
– (1)将查询路由给一个通常的负载均衡器，由负载均衡 器来根据各结点负载来选择结点
– (2)使用客户端的分布感知库来将请求直接路由到适当 的协调器结点。
• [10] Karger, D., Lehman, E., Leighton, T., Panigrahy, R., Levine, M., and Lewin, D. 1997. Consistent hashing and random: distributed caching protocols for relieving hot spots on the World Wide Web. In Proceedings of the Twenty-Ninth Annual ACM Symposium on theory of Computing (El Paso,Texas, United States, May 04 - 06, 1997). STOC '97. ACM Press, New York, NY, 654-663
22
Data Versioning(数据版本)
• Dynamo采用最终一致性策略，也即允许数据的更 新通过异步广播到所有的副本
• Dynamo将每个数据项的更改作为一个新的、不变 的版本
– 它允许一个对象的多个不同的版本在系统中同时存在 。绝大多数情况下，新的版本会覆盖旧的版本，而且 ，系统也可以决定有效的版本(语法和解)
29
故障检测
• 去中心化的失效检测协议使用一个简单的 闲聊式的协议来使得系统的每个结点感知 其它结点的离去(或加入)，详见[8]
30
参考ቤተ መጻሕፍቲ ባይዱ献
• [8] Gupta, I., Chandra, T. D., and Goldszmidt, G. S. 2001. On scalable and efficient distributed failure detectors. In Principles of Distributed Computing (Newport, Rhode Island, United States). PODC '01. ACM Press, New York,NY, 170-179.Proceedings of the Twentieth Annual ACM Symposium on
• even the slightest outage has significant financial consequences and impacts customer trust.——so availaiblity is particular focus
9
Dynamo的技术
• 总得来说，是各种著名的技术来获得可靠 性和可用性
– 查询模型：读写由独一的键来
– ACID特性：Dynamo弱化了其中一致性——为
高可用性 – 效率 – 其它预设：
• Dynamo是预想运行在非常安全的环境中的，因此 ，没有考虑安全机制，这是在移植其架构时要考虑 的
11
服务等级协议(SLA)
• the common pattern of using a relational database would lead to inefficiencies and limit scale and availability.
– 当一个新的结点加入的时候，它被分配有多个位置 (也即后文中所说的“token”——象征)
使用虚拟结点有以下好处：
当一个结点不可用时，此结点上的负载会被分到 其它可用结点上(自己补充：事实上，这个也被有头 脑的人看出了问题：——即网络中充斥着数据包)
当结点又恢复可用时或者新的结点加入系统时， 新的可用结点会接收其它结点的负载来平衡
• 采用一个类似于选举的一致性协议
– 设置R和W，使得R+W>N,来产生一个类投票的系统
26
临时故障处理:暗示回传(Hinted Handoff)
27
永久故障处理:副本同步
• Dynamo实现了反熵(副本同步)协议来保持 副本一致
• 为了更快地检测副本之间的不一致，同时 ，使得传输的数据最小，Dynamo使用 Merkle树[13]
Key-value数据库
1
2
Key-Value数据库特点及应用
应用场景：内容缓存，主要用于处理大量数据 的高访问负载，也用于一些日志系统。 优点：查找迅速 缺点：数据无结构，通常只被当做字符串或二 进制数据
3
• Java实现的开源key-value数据库 • 特征
– 数据自动冗余备份于多个结点上 – 数据分区存储 – 单点故障对整个系统透明 – 支持复杂数据类型的序列化 – 将数据项进行版本化，出现故障时最大限度保
– Dynamo的目标空间是“永远可写”的数据存储。对于Amazon的许多服务 ，拒绝用户的更新可能导致很差的用户体验。为此，Amazon将冲突解决 的复杂性推向了读这一边，从而保证写永远不会被拒绝。
• 另一个设计考虑是由谁来进行冲突的处理。这可以通过数据存储或副 本来做。
– 如果由数据存储来解决，那么选择的办法只能会挺简单——“最后写为准” – 另一方面，由于应用程序对数据模式敏感，因此，由它可以作出更适合
– 尤其是通过自己近期对带《VB程序设计与数据库》的课程 ，深刻体会关系型数据库对数据类型的强制，使得程序开发 人员的负担有多重——我的疑问
• Some of these services are stateless (i.e., services which aggregate responses from other services) and some are stateful (i.e., a service that generates its response by executing business logic on its state stored in persistent store)
• 第三，使用的Dynamo不需要对目录树支持的命名 空间。
• 第四，Dynamo是面向那些要求在几百毫秒至少有 99.9%的读和写被完成的对延迟敏感的应用程序
17
18
分区(布)算法
• 需要将数据在结点中动态分布
– 在一致性Hash算法中,Hash函数的输出范围被当作固 定的环空间(“ring”)(也就是最大的Hash值与最小的 Hash值相衔接),系统中的每个结点被赋予一个环空间 范围内的随机值，这个值代表它在环中的位置。每一 份数据，通过其键Hash产生其在ring上的位置被赋到 一个结点上,然后 顺着顺时钟的方向找到第一个位置大 于数据项Hash位置的实际结点。
21
node B replicates the key k at nodes C and D in addition
to storing it locally. Node D will store the keys that fall in
the ranges (A, B], (B, C], and (C, D].
– 一致性Hash算法的优点是——数据的离去和加入只会 影响到其相邻的邻居，而其它的结点没有受到影响。
– 一些挑战：
• 首先，每个结点在环上的随机位置的产生导致数据和负载的不均衡
• 其次，这个算法忽视了各结点的异质性(不同的网络带宽、不同的负
载、不同的硬件等等)
19
• Dynamo采用的是一致性Hash的变体(类似于 [10,20]):并不是将结点与环上的一个点相映射 ，而是一个结点与多个环上的点相对应。因此 ，引入了”虚拟结点”的概念
13
• 图1显示的是Amazon平台的抽象架构，其中 ，动态网页内容由网页渲染服务组件产生，而 网页渲染服务又由其它服务提供，一个服务可 以由不同的数据存储来管理其状态，而这些数 据的存储只能在其服务范围内被访问。有些服 务担当聚集者的角色，通过使用不同的其它服 务来产生一个复杂的响应。基本上，聚集服务 是无状态的，尽管它们使用缓存.
• 分布式文件系统和数据库(P2P)
– 与只支持平面层的命名空间的点对点系统相比，分 布式文件系统一般是支持目录树架构的命名空间。
16
讨论
• 首先，Dynamo的目标应用是“永远可写”的应用程序 ，以便对用户的更新请求或并发写不会拒绝。
• 其次，如前所述，Dynamo部署在内部可信安全的 基础设施之上。
• Amazon面临的更具体的问题
– 可靠性 – 可扩展性 – Amazon的经验：上述依赖于应用的状态管理 – Amazon的特殊要求：应用总在线——可用性
怎么利用对象版本？对象存储与块存储到底意味着什么？ 8
• Amazon的具体问题是：
Amzon的电子商务平台由成百上千个服务——包 括购物建议、订单提交和错误侦测等组成。每项服务都 由分散在世界各地的数据中心通过网络来提供接口。这 些服务有些是无状态的(比如说：只聚集来自其它服务的 响应)，有些是有状态的(如根据其固化存储的状态来执 行业务逻辑所产生的的响应)；对于传统的存储状态所使 用的关系型数据库，操作的复杂和硬件成本的昂贵是使 其是低效的。(这个，在自己教学实践中倒是有体会)， 同时扩展性差
– 数据的分布和复制采用一致性Hash[10] – 读数据的一致性由对象版本来保证[12] – 数据更新期间数据副本的一致性由类似投票机
制和离散化副本同步协议来保证 – 成员关系和失效检测由基于闲聊的协议保证
上小节我的问题：在存储系统中，应用程序状态意味着什么?
10
系统预设和要求
• 此类服务的存储系统有以下要求：
一个结点负责的虚拟结点的数量可以根据其容量 来决定,这样，也就顾及到其物理基础设施
20
副本策略
• 每个数据项被复制到N台主机上。而每个键 ，K,被分配给协调器结点，协调器结点负责 落在其范围内的数据项的键。而且，为了 局部存储落在其范围内的键，协调器将这 些键顺时针方向复制到其它的环上后继N-1 个结点。这样，每个结点负责它和它的第N 个前继结点范围内的数据项。
• 在Dynamo中，当客户端要更新一个系统时 ，它必须指明它正在更新哪一个版本。通 过将其从早期读操作获得的上下文信息下 传，可以做到这一点
• 最好是限制向量时钟的大小，因此， Dynamo使用时钟截断模式：在有每一个 (node,counter)对时，Dynamo 还存储了结 点更新该数据项时的最后时间。
28
成员维护和故障检测
• 基于闲聊的协议将成员变更和最终成员的一致 性视图广播出去。
– 每隔2秒，结点会与其随机选择的对等结点联系， 然后它们之间相互交换信息，并且它们之间彼此保 持成员信息的同步
• 为了防止结点故障造成的信息孤岛，一些 Dynamo结点作为种子结点。所谓的种子结点 即那些可由外部机制发现并且为所有结点感知 的结点。
证数据的完整性
来自亚马逊的Dynamo项目
4
5
6
Voldemort 使用
value = store.get(key) store.put(key, value) store.delete(key)
7
Dynamo问题产生(研究的来源)
• 对于分布式存储(或者说是”云存储”)的共有的 目标
– 可靠性 – 可扩展性
• 存储系统在建立服务等级协议上扮演重要角色 尤其是当服务逻辑相对权重较轻时(就像 Amazon的许多业务)，状态管理成为一项服 务的服务等级协议的重要组件.
14
设计细节
• 对冲突的解决办法引入了两个问题：什么时候去解决它们；由谁负责 解决。
– 一个重要的设计考虑是什么时候解决更新的冲突？也就是说，是否应该 在读和写的时候就解决冲突。
客户端体验的解决办法。 其它主要考虑的还有：
向量可扩展性 对称性 去中心化 异质性
15
相关研究(本系统思想来源)
• 点对点系统(P2P)
– 第一代点对点系统，是非结构化的点对点网络，其 特点是整个层的网络是网状的，一个查询在整个网 络中流动
– 接下来的点对点系统，即结构化的点对点系统，其 特点是网络采用了全局一致性协议来保证任何结点 都可以有效地将其查询路由到目的结点。
– 然而，版本分化同样可能会出现，当并发的更新失败 时，可能会导致一个版本的冲突。在这种情况下，系 统并不能来和解一个对象的不同版本，此时，将由客 户端来融合所有的版本来达到一个最终版本
23
• Dynamo使用向量时钟来捕捉一个对象不同 版本间的因果关系。一个向量时钟是有效 的一列(node,counter)元组对。一个向量时 钟与一个对象的不同版本一一对应。
24
25
Get()和put()操作的执行
• Dynamo中的任何数据都能够接受来自客户端的对 任何键的get()和put()操作
• 客户端操作get()和put()有两种策略:
– (1)将查询路由给一个通常的负载均衡器，由负载均衡 器来根据各结点负载来选择结点
– (2)使用客户端的分布感知库来将请求直接路由到适当 的协调器结点。
• [10] Karger, D., Lehman, E., Leighton, T., Panigrahy, R., Levine, M., and Lewin, D. 1997. Consistent hashing and random: distributed caching protocols for relieving hot spots on the World Wide Web. In Proceedings of the Twenty-Ninth Annual ACM Symposium on theory of Computing (El Paso,Texas, United States, May 04 - 06, 1997). STOC '97. ACM Press, New York, NY, 654-663
22
Data Versioning(数据版本)
• Dynamo采用最终一致性策略，也即允许数据的更 新通过异步广播到所有的副本
• Dynamo将每个数据项的更改作为一个新的、不变 的版本
– 它允许一个对象的多个不同的版本在系统中同时存在 。绝大多数情况下，新的版本会覆盖旧的版本，而且 ，系统也可以决定有效的版本(语法和解)
29
故障检测
• 去中心化的失效检测协议使用一个简单的 闲聊式的协议来使得系统的每个结点感知 其它结点的离去(或加入)，详见[8]
30
参考ቤተ መጻሕፍቲ ባይዱ献
• [8] Gupta, I., Chandra, T. D., and Goldszmidt, G. S. 2001. On scalable and efficient distributed failure detectors. In Principles of Distributed Computing (Newport, Rhode Island, United States). PODC '01. ACM Press, New York,NY, 170-179.Proceedings of the Twentieth Annual ACM Symposium on
• even the slightest outage has significant financial consequences and impacts customer trust.——so availaiblity is particular focus
9
Dynamo的技术
• 总得来说，是各种著名的技术来获得可靠 性和可用性
– 查询模型：读写由独一的键来
– ACID特性：Dynamo弱化了其中一致性——为
高可用性 – 效率 – 其它预设：
• Dynamo是预想运行在非常安全的环境中的，因此 ，没有考虑安全机制，这是在移植其架构时要考虑 的
11
服务等级协议(SLA)
• the common pattern of using a relational database would lead to inefficiencies and limit scale and availability.
– 当一个新的结点加入的时候，它被分配有多个位置 (也即后文中所说的“token”——象征)
使用虚拟结点有以下好处：
当一个结点不可用时，此结点上的负载会被分到 其它可用结点上(自己补充：事实上，这个也被有头 脑的人看出了问题：——即网络中充斥着数据包)
当结点又恢复可用时或者新的结点加入系统时， 新的可用结点会接收其它结点的负载来平衡
• 采用一个类似于选举的一致性协议
– 设置R和W，使得R+W>N,来产生一个类投票的系统
26
临时故障处理:暗示回传(Hinted Handoff)
27
永久故障处理:副本同步
• Dynamo实现了反熵(副本同步)协议来保持 副本一致
• 为了更快地检测副本之间的不一致，同时 ，使得传输的数据最小，Dynamo使用 Merkle树[13]
Key-value数据库
1
2
Key-Value数据库特点及应用
应用场景：内容缓存，主要用于处理大量数据 的高访问负载，也用于一些日志系统。 优点：查找迅速 缺点：数据无结构，通常只被当做字符串或二 进制数据
3
• Java实现的开源key-value数据库 • 特征
– 数据自动冗余备份于多个结点上 – 数据分区存储 – 单点故障对整个系统透明 – 支持复杂数据类型的序列化 – 将数据项进行版本化，出现故障时最大限度保
– Dynamo的目标空间是“永远可写”的数据存储。对于Amazon的许多服务 ，拒绝用户的更新可能导致很差的用户体验。为此，Amazon将冲突解决 的复杂性推向了读这一边，从而保证写永远不会被拒绝。
• 另一个设计考虑是由谁来进行冲突的处理。这可以通过数据存储或副 本来做。
– 如果由数据存储来解决，那么选择的办法只能会挺简单——“最后写为准” – 另一方面，由于应用程序对数据模式敏感，因此，由它可以作出更适合
– 尤其是通过自己近期对带《VB程序设计与数据库》的课程 ，深刻体会关系型数据库对数据类型的强制，使得程序开发 人员的负担有多重——我的疑问
• Some of these services are stateless (i.e., services which aggregate responses from other services) and some are stateful (i.e., a service that generates its response by executing business logic on its state stored in persistent store)
• 第三，使用的Dynamo不需要对目录树支持的命名 空间。
• 第四，Dynamo是面向那些要求在几百毫秒至少有 99.9%的读和写被完成的对延迟敏感的应用程序
17
18
分区(布)算法
• 需要将数据在结点中动态分布
– 在一致性Hash算法中,Hash函数的输出范围被当作固 定的环空间(“ring”)(也就是最大的Hash值与最小的 Hash值相衔接),系统中的每个结点被赋予一个环空间 范围内的随机值，这个值代表它在环中的位置。每一 份数据，通过其键Hash产生其在ring上的位置被赋到 一个结点上,然后 顺着顺时钟的方向找到第一个位置大 于数据项Hash位置的实际结点。
21
node B replicates the key k at nodes C and D in addition
to storing it locally. Node D will store the keys that fall in
the ranges (A, B], (B, C], and (C, D].
– 一致性Hash算法的优点是——数据的离去和加入只会 影响到其相邻的邻居，而其它的结点没有受到影响。
– 一些挑战：
• 首先，每个结点在环上的随机位置的产生导致数据和负载的不均衡
• 其次，这个算法忽视了各结点的异质性(不同的网络带宽、不同的负
载、不同的硬件等等)
19
• Dynamo采用的是一致性Hash的变体(类似于 [10,20]):并不是将结点与环上的一个点相映射 ，而是一个结点与多个环上的点相对应。因此 ，引入了”虚拟结点”的概念