顶会论文解读|DEPART:分布式KV存储系统的副本解耦方案(3)

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 顶会论文解读|DEPART:分布式KV存储系统的副本解耦方案

c. 挑战三:副本解耦后如何加速数据恢复操作

副本解耦后,通过一种并行的恢复机制,以利用数据解耦存储的特征来加速数据恢复操作。

image.png

如图步骤①中,当为节点上的数据构建Merkle tree以检测丢失的数据时,使用两个线程,并行地从LSM-tree的主副本和两层日志的冗余副本中读数据。

当修复多个范围段的丢失数据时,如图步骤③,同样使用两个线程,并行地从LSM-tree的主副本和两层日志的冗余副本中读写数据。


三、实验


3.1 实验设置

image.png

实验服务器硬件配置

● 在6个节点(5个存储节点,1个客户端节点)组成的本地集群中运行所有实验, 10 Gb/s以太网交换机;

● 工作负载:使用YCSB 0.15.0来生成工作负载,KV对大小为1KB,生成的工作负载服从Zipf分布 (0.99);

● 参数:默认采用三副本,并且将写一致性等级和读一致性等级默认设置为1(WCL=ONE, RCL=ONE)。


3.2 比较

● Cassandra v3.11.4  VS  multiple LSM-trees (mLSM) VS DEPART

● DEPART builds on Cassandra v3.11.4

在开源的分布式KV存储系统Cassandra上实现了原型系统DEPART,同时也实现了多个LSM-tree的简单解耦方案。将DEPART与Cassandra、多个LSM-tree的解耦方案分别进行性能比较,以展示系统DEPART的设计优势。

实验一:基准测试

实验一分别测试了不同KV系统的写、读、范围查询和更新操作的吞吐量。

image.png

由实验结果可知,相比于Cassandra,系统DEPART可以显著提升所有操作的吞吐量。而对于多个LSM-tree的解耦方案,其可以较好地提升Cassandra的读性能,但对Cassandra的写性能提升非常有限。主要原因是多个LSM-tree的解耦方案会导致解耦出的每个LSM-tree仍然需要执行频繁的Compaction操作,以维护每层数据的完全有有序,从而导致总的Compaction开销仍然非常严重。

实验二:不同一致性配置

实验评估了不同一致性配置下的系统性能。这里对于强一致性等级,考虑了三副本下不同的写一致性等级和读一致性等级配置。

image.png

由实验结果可知,与Cassandra相比。系统DEPART可以在不同一致性配置下均可以提高所有操作的吞吐量,并且相比于多个LSM-tree的解耦方案,DEPART可以有效提高写入和更新操作的吞吐量。

然而,当读一致性等级(RCL)配置为大于1时,与Cassandra相比,DEPART的读性能收益会变小,并且DEPART的读性能还要略差于多个LSM-tree的解耦方案。其主要原因是,在这种读一致性配置下,每个读请求需要成功访问至少两个副本,因此必须搜索两层日志当中的冗余副本;又由于两层日志中的冗余副本并未完全排序,因此读取两层日志的性能要低于读取完全排序的LSM-tree的主副本。

注意,DEPART的读性能仍然要好于Cassandra,因为副本解耦后,DEPART搜索的数据量更少,但是DEPART的读性能要差于多个LSM-tree,因为多个LSM-tree保持冗余副本完全有序。

实验三:数据恢复性能

分别测试当恢复不同数据量时所需要的时间。

image.png

与Cassandra相比,DEPART将恢复时间减少38%-54%,主要原因是并行修复机制可以并行地读写主副本和冗余副本。

实验四:有序度参数S对系统读写性能的影响

image.png

如表格所示,当S的值为1时,两层日志会变为两层LSM-tree,KV数据是完全有序的,因此它可以获得最高的读吞吐量。但由于频繁的合并排序操作,这时候写吞吐量是最低的。

当S的值从1不断增大时,两层日志的有序度会不断降低,故合并排序开销逐渐减小,因此写性能会不断增加,而读性能会不断降低。

因此,可以通过调整S的取值,在读写性能之间做合适的权衡。


四、总结

DEPART是一个基于副本解耦的高性能和高可靠的分布式KV存储系统,包括轻量级副本解耦方案、两层日志架构、有序度可调机制、并行恢复机制等关键模块设计。


KV研究热点总结与展望

首先,目前KV领域的绝大部分工作都集中在优化KV存储引擎上,例如改进LSM-tree架构,以减轻读写放大问题,以及结合新型硬件来重新设计KV存储引擎等等。

但在KV系统的数据容错层,相关研究极少,我们进行了初步探索,观察到当前统一的多副本管理会极大加剧KV系统的读写放大,因此研究设计了基于副本解耦的多副本差异化管理框架,极大提升了系统性能。这项工作基于Cassandra开源平台实现,并可以应用在TiKV等一系列基于LSM-tree的分布式KV存储系统中。

对于KV系统未来的研究方向,可以结合应用层的需求和缓存特征来进行特定的KV系统设计。例如,研究设计一种属性感知的内存KV系统,使其在存储结构上能够支持对数据属性值的高效读写,最终部署到云存储平台,以高效支撑SQL数据库等应用。此外也可以结合上层应用的其他特征和需求来设计针对性的KV存储系统。

详细内容请参阅论文《DEPART: Replica Decoupling for Distributed Key-Value Storage》

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
14天前
|
消息中间件 SQL 中间件
大厂都在用的分布式事务方案,Seata+RocketMQ带你打破10万QPS瓶颈
分布式事务涉及跨多个数据库或服务的操作,确保数据一致性。本地事务通过数据库直接支持ACID特性,而分布式事务则需解决跨服务协调难、高并发压力及性能与一致性权衡等问题。常见的解决方案包括两阶段提交(2PC)、Seata提供的AT和TCC模式、以及基于消息队列的最终一致性方案。这些方法各有优劣,适用于不同业务场景,选择合适的方案需综合考虑业务需求、系统规模和技术团队能力。
102 7
|
18天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
48 4
|
19天前
|
缓存 NoSQL Java
Spring Boot中的分布式缓存方案
Spring Boot提供了简便的方式来集成和使用分布式缓存。通过Redis和Memcached等缓存方案,可以显著提升应用的性能和扩展性。合理配置和优化缓存策略,可以有效避免常见的缓存问题,保证系统的稳定性和高效运行。
37 3
|
18天前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
1月前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
106 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
24天前
|
NoSQL 安全 PHP
hyperf-wise-locksmith,一个高效的PHP分布式锁方案
`hyperf-wise-locksmith` 是 Hyperf 框架下的互斥锁库,支持文件锁、分布式锁、红锁及协程锁,有效防止分布式环境下的竞争条件。本文介绍了其安装、特性和应用场景,如在线支付系统的余额扣减,确保操作的原子性。
26 4
|
1月前
|
NoSQL 算法 关系型数据库
分布式 ID 详解 ( 5大分布式 ID 生成方案 )
本文详解分布式全局唯一ID及其5种实现方案,关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
分布式 ID 详解 ( 5大分布式 ID 生成方案 )
|
24天前
|
机器学习/深度学习 人工智能 分布式计算
【AI系统】分布式通信与 NVLink
进入大模型时代后,AI的核心转向大模型发展,训练这类模型需克服大量GPU资源及长时间的需求。面对单个GPU内存限制,跨多个GPU的分布式训练成为必要,这涉及到分布式通信和NVLink技术的应用。分布式通信允许多个节点协作完成任务,而NVLink则是一种高速、低延迟的通信技术,用于连接GPU或GPU与其它设备,以实现高性能计算。随着大模型的参数、数据规模扩大及算力需求增长,分布式并行策略,如数据并行和模型并行,变得至关重要。这些策略通过将模型或数据分割在多个GPU上处理,提高了训练效率。此外,NVLink和NVSwitch技术的持续演进,为GPU间的高效通信提供了更强的支持,推动了大模型训练的快
38 0
|
2月前
|
存储 缓存 NoSQL
分布式架构下 Session 共享的方案
【10月更文挑战第15天】在实际应用中,需要根据具体的业务需求、系统架构和性能要求等因素,选择合适的 Session 共享方案。同时,还需要不断地进行优化和调整,以确保系统的稳定性和可靠性。
|
2月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
62 3
下一篇
DataWorks