浅谈分布式存储之单机对象存储引擎

最新推荐文章于 2024-09-25 19:39:57 发布

lingshengxiyou

最新推荐文章于 2024-09-25 19:39:57 发布

阅读量440

点赞数

文章标签：分布式运维 c++ linux 虚拟化

本文链接：https://blog.csdn.net/lingshengxiyou/article/details/127810740

版权

本文探讨了构建分布式对象存储系统中，针对S3场景设计的单机对象存储引擎BlobStore。BlobStore简化了覆盖写和快照等特性，强调异步读写和分层缓存。文章详细介绍了BlobStore的接口、架构、IO流程和分层缓存设计，以及与BlueStore的区别。

摘要由CSDN通过智能技术生成

前言

构建大规模分布式存储系统通常需要一个高性能、低延迟、稳定可靠的单机存储引擎。对于不同的分布式存储系统其需要的单机存储引擎也不相同。分布式KV存储通常使用RocksDB等单机KV存储引擎，其特点是value通常很小且不可变；分布式数据库通常也是使用RocksDB作为单机存储引擎；分布式对象存储使用Haystack、Bitcask等作为单机对象存储引擎，本质上也是kv存储，其特点是value可以是1B--5GB且对象不可变；分布式块存储也需要高性能的单机对象存储引擎，其特点是对象是可变的，需要支持覆盖写、快照等复杂的功能，其实现难度也大。

不同的单机存储引擎技术点也不一样，在这里，我们仅仅讨论分布式对象存储单机对象存储引擎的设计，但是不会讨论Haystack、Bitcask等模型，具体技术细节可前往Google。我们主要讨论基于Ceph BlueStore单机对象存储引擎来设计适用于分布式对象存储的单机存储引擎。

Inspiration

之前已经有一系列的文章介绍Ceph BlueStore，我们可以发现BlueStore支持覆盖写、快照、对象扩展属性、IO保序等复杂的操作，比较适用于块存储的场景；但是在对象存储S3的场景中，我们发现其实覆盖写、快照、对象扩展属性这些特性我们根本不需要，因为对象存储S3是不可变的，也就不需要覆盖写，甚至IO保序也不需要，因为对象存储S3是使用HTTP协议访问的，不论在多客户端还是单客户端的并发条件下，都不需要保证同一对象put object的并发性。

线上生产环境的存储机型通常可以选配为大容量的HDD盘和高性能的NVME盘结合；同时专门为NVME打造的SPDK直接By Pass Kernel，大大缩短了IO路径，减少了IO延迟；此外BlueStore的写入延迟也有一部分耗费在IO保序、覆盖写的DeferredWrite和RocksDB存储元数据的sync等上面。

我们可以考虑结合BlueStore的优秀特性、SPDK的高性能以及特定的存储机型，打造一个适用于分布式对象存储的支持分层缓存的单机对象存储引擎BlobStore。不要与SPDK的blobstore搞混哦。