专业做美食视频的网站,企业培训课程一览表,怎么样制作网页,安庆建设银行网站作者 | 奇伢来源 | 奇伢云存储小文件存储小文件存储#xff0c;老生常谈的问题。先聊聊小文件存储重点关注的是什么#xff1f;以前我们提过#xff0c;对于磁盘来说#xff0c;小 io 吃 iops#xff0c;大块 io 吃吞吐。划重点#xff1a;小文件的重点是 io 次数。为什么… 作者 | 奇伢来源 | 奇伢云存储小文件存储小文件存储老生常谈的问题。先聊聊小文件存储重点关注的是什么以前我们提过对于磁盘来说小 io 吃 iops大块 io 吃吞吐。划重点小文件的重点是 io 次数。为什么每次提到海量小文件的时候总说传统的文件系统不合适呢因为它的元数据操作太惹人眼球了。假设有 1K 的数据元数据如果搞个 1K 这个开销就太大了空间大一倍性能下降一倍。所以只要是针对小文件的存储优化基本上都会在元数据上下点功夫。Haystack 的背景Haystack 是 Facebook 为了解决他们图片存储而专门设计的一套存储架构2012 年发表论文《 Finding a needle in Haystack: Facebook’s photo storage 》。文中提到当时 2012 年 他们已经有 2600 亿张图片超过 20 PB 的数据用户每周上传 10 亿张大约 60 TB 的数据。从这个数据量来看确实谈得上海量的文件。算出来的图片平均大小 64K 左右吧不大就是以前普通图片的大小。64K 不知道怎么算的用 60 TB 除一个 10 亿就知道了。Haystack 的特点接下来聊聊 Haystack 的设计到底有什么神奇特点呢可以归纳下面四点Write OnceRead OftenNerver ModifyRarely Deleted大白话就是只写一次从不更新不定期会读极少删除。这个 Haystack 特点是适配 Facebook 的图片场景的。注意是先有 facebook 的业务场景特点然后才把 Haystack 设计成这样的。因果关系不要搞反了哦。海量的文件的挑战在哪里每一次文件存储会涉及到元数据和数据两部分的操作。当数量是海量的时候无论是对存储容量和元数据的量都会带来巨大的影响。存储容量这个自不用提这是用户的数据它是你必须要存储的通常这里考虑的是存储效率考虑用更少的介质、更高的可靠性来存储更多的数据通常这里的选型是副本和纠删码。元数据就有意思了因为这个是内部的设计导致的冗余数据为了索引用户数据而产生的数据元数据的设计则会影响到用户的体验特别是海量的场景。童鞋思考个问题海量、小文件 的前提下为什么元数据会带来挑战挑战主要是哪些方面 1 存储成本有挑战划重点任何的评估不能脱离场景。举个简单的例子假如每个文件 1K 每个文件对应元数据也 1K 这开销大不大太大了嘛。一倍的浪费。在海量的背景下用户存储 1P 的数据就要存储 1P 的元数据浪费在元数据的成本无法容忍。那元数据设计成 1K 的是错误的吗不一定。比如说如果是每个文件 1G对应每个元数据 1K 呢这个开销大不大不大因为 1K/1G 才是 0.00009% 也就是说用户存储 1P 的数据元数据消耗为 0.092 TB 这成本几乎可以忽略。所以前提很重要设计好坏并不是绝对的都是相对而言的任何架构都要适配自己的场景。 2 存储性能有挑战接着上面的例子每个文件 1K 每个文件对应元数据也 1K 这性能开销大不大太大了嘛。性能是一倍的损耗。每个文件 1K 本该一次磁盘 IO 就能解决但是另外还要加一次元数据操作的磁盘 IO 。也就是说磁盘极限如果 1 万的 iops 用户只能获取到 5000 的 iops 性能。内部损耗一半。那如果是每个文件 1G对应每个元数据 1K 呢这个开销大不大不大嘛假设每笔 io 是 4K 的定长大小。1G 的数据写 262144 次。只是多加一次元数据 IO 无关紧要。 3 Hasystack 的突围方向划重点小文件的场景元数据的成本消耗和性能消耗会显得更突出。再加上海量的前提下这个是必须要解决的挑战。那 Haystack 应该怎么做呢两个方面重新设计元数据结构而不是使用文件系统的结构要精简元数据的大小削减元数据的 io 的次数甚至从 io 路径上彻底消除元数据它你如果理解了上面的栗子对于这两个优化方向的导出应该也是水到渠成的。Haystack 的目标高吞吐低延迟高可靠具备故障容错能力架构简单底成本Haystack 的架构设计 1 整体架构Haystack 的架构非常简单截取论文中的图片图中表明了三个核心组件Haystack DirectoryHaystack CacheHaystack StoreStore 就是一个单机的存储引擎上层告诉它写哪它就写哪。管理的单位是一个个大块文件。Haystack 里面叫做 Physical Volume 其实就是一个个大文件而已啦。划重点Haystack 也是基于文件系统之上的。Physical Volume 有一个阈值比如写满 100 GB就不写了。可以把它理解成一个大日志文件数据的写入方式也是 log 日志的方式append 写入。Directory 是最上层的一个抽象上面提到 Store 管理的是 Physical Volume 上报到 Directory 组件Directory 把这些底层的 Physical Volume 按照副本关系组织起来形成 Logical Volume 。Logical Volume 就是提供给用户写入数据用的。举个简单的例子如果是三副本的 Haystack 系统那么一个 Logical Volume 由 3 个 Physical Volume 组成副本镜像。Cache 这个就不用说了就是一个单纯的缓存组件。 2 数据怎么组织奇伢用几个问题的形式来阐述数据的组织。问题一Physical Volume 是什么其实就是大文件Haystack Store 是基于文件系统之上的。Physical Volume 就实现形式来讲就是文件可以是 ext4 的文件也可以是 xfs 的文件。只不过这个文件有名字 Physical Volume ID 也是一个阈值比如 100 GB 。问题二Logical Volume 是什么抽象出来的结构。由多个 Physical Volume 组成。它的个数由副本数决定比如一个 3 副本 Logical Volume 由 3 个 Physical Volume 组成。问题三Physical Volume 内部又是有什么构成呢一个叫做 Needle 的东西。Needle 其实就是用户数据加一些头部加一些尾部构成的一个整体结构。Physical Volume 就是由这一个个 Needle 组成的。问题四Needle 的头尾有啥用主要几个方面用来构建元数据索引用的里面有 keysize 等关键数据用来校验数据是否损坏里面有 magiccrc 等用来标识数据是否删除里面有 Flags 标记位这些头尾数据就是 Haystack 给每个用户对象重新设计的元数据了相比文件系统的元数据这个太精简了。在内存中的内存表甚至只需要一个 16 个字节就够了8 字节的 key 4 字节的 offset4 字节的 size 。这个比内核文件系统动辄几百字节甚至几 K 字节要好太多了。问题四元数据现在多大了元数据分为磁盘元数据持久化了的和内存元数据。磁盘元数据可以看上面的 Needle 结构体具体实现在 32 字节左右。内存元数据可以控制在 16 个字节。 3 读、写、删数据写入的流程Web 接入点先去 Haystack Directory 选一个 Logical Volume 把数据发往 Haystack Store 写到对应的三个 Physical Volume 即可注意append 写入哦数据读取的流程Web 接入点先去 Haystack Directory 拿到指定对象的元数据然后请求发给 Haystack Store 读取数据这里就不提 Haystack Cache 或者 CDN 的逻辑了过于简单数据删除的流程Web 接入点先去 Haystack Directory 拿到指定对象的元数据然后把删除请求发给 Haystack Store 就地更新 Needle 的标记位标记成删除划重点Haystack 的删除是就地更新而不是 append 写入。这里跟纯粹的 log 文件不大一样。 但由于删除是极少的所以就算不是 append 写入也不影响大局。 4 空间回收Haystack 也和 LSMBitcask 等设计类似删除是删除回收是回收这是两个步骤。空间回收就是 Compact 太简单了论文甚至都没稀的提它寥寥数语说了两句原文描述如下A Store machine compacts a volume file by copying needles into a new file while skipping any duplicate or deleted entries.实现很简单和以前提过的 Compact 并无二样。逻辑就是遍历 Volume 文件把重复的和标记删除了的 Needle 跳过有效的 Needle 读出来写到新的地方即可。不一样的思考回想一下这个架构思考一下它做到了它立的 flag 吗 1 它的目标高吞吐低延迟怎么实现的呢对于写请求全都化为 append 请求极力的保持磁盘的顺序性能。并且得益于 Needle 的设计Haystack 把数据和元数据放在一起一次性落盘相当于省去了元数据的 IO 写开销。当然这种设计也必然有代价由此带来的代价就是加载时间变长。对于读请求通过元数据的精简让内存 hold 住所有的元数据去除了元数据的 IO 开销这样读操作也就只剩用户数据的 IO 。注意Haystack 删除不是 append 哦而是覆盖写但之前已经说过了Haystack 的适用场景就是“极少删除” 。 2 高可靠故障容错怎么实现的呢这个很简单通过副本冗余来做的。Volume 的组织逻辑放在 Directory 组件中一份数据存储多份并且分散在不同的位置。当其中一份故障则只需要拷贝其他副本即可。 3 毕竟 2012 年的论文Haystack 的实践过时了吗论文中提到Facebook 当时的实践是用 2U 的刀片服务器48G 内存搭配 12 * 1TB 的 SATA 盘。如果按照一个文件 64 KB 算一个 needle 内存元数据 16 字节这个很极限了只需要 3 G 的内存单机 48 GB 的物理内存应对这整机的元数据确实绰绰有余。但现在很多服务器已经升级到 64 盘单盘 16 TB满载的话需要 256 G 的内存装元数据。这个内存配比就不大合适了如果元数据再稍微大点就更不行了。但话说回来并不是每个人都用 64 盘 16 T 的高密服务器所以并不能一概而论还是要看自己的需求场景。就算过去 10 年我觉得它还能秀。总结Haystack 最核心的优化是重新设计元数据的结构使得内存元数据只有十几个字节极大的减轻了负担且设计的 Needle 结构可以完整恢复内存元数据得益于元数据的精简Haystack 就能把单机全量元数据放在内存读的时候元数据在内存只有用户数据的 IO 消耗极大的提高了性能写的时候得益于 Needle 的设计元数据更新操作不单独刷而是和用户数据在一起刷相当于省掉了元数据 IO 的开销和 Bitcask 类似为了提高内存加载速度也有索引Index 文件的实现Haystack 并不过时可以结合自己的场景焕发生机往期推荐为什么还有这么多的网络故障k8s集群居然可以图形化安装了用了HTTPS没想到还是被监控了将 k8s 制作成 3D 射击游戏好玩到停不下来点分享点收藏点点赞点在看
