重删之删除-Memory Efficient Sanitization of a Deduplicated Storage System
2013-03-15 20:29
495 查看
重复数据删除这水太深了,又几篇关于重删的文章闪现于Fast13. 一篇关于恢复的,一篇关于元数据压缩(recipe compression) , 一篇关于并行删除的(不太懂,还没细看), 有一篇关于删除的(Sanitization),还有一篇关于提高恢复速度的。
Memory Efficient Sanitization of a Deduplicated Storage System:此文章首先introduce 数据的重要性,堂而皇之的冠以“敏感数据”(the sensitive data),说要达到“删除敏感数据,就想从没存储过似的”,然后是长篇介绍thread mode 及删除的必要性,重要性。好庄重的文章,不看到最后,我以为这是搞安全的呢?!
然后煞有介事的给我们将条例(如下)。(ps:好像在说,你看,我们都定出规则来了,别人没有吧?)
P1: All deleted data are erased.
P2: All live data are available.
P3: Sanitization is efficient.
P4: The storage system is usable while sanitization runs.
如果你愿意一层一层,一层的剥开我的心,你会发现你会讶异。paper,高质量的paper,就得耐心的看,因为人家也是花了很长
很长的时间才写下了这么successful paper. 写着有耐心,读者更需耐心。
如图所以,终于要进入主题啦!四种删除机制所用内存比较。
Reference counts 保证不了可靠性,如果服务中断,或者宕机等事故发生,大量的事务回滚操作烦烦烦!而亲也占用空间。
Bloom Filter 真是一大进化,以牺牲时间(多次hashing)和 一定的正确率(很多paper 说 发生的概率像磁盘发生错误一样的低)
来节省空间。但是,错误率虽然低,可毕竟还是存在风险与缺陷。(你人是好,可是不够帅)
Bit Vector 可又是一大突破,减,减,减!以1bit 代表一个数据块,利用率已经到极致。可惜,需要多次读disk(多次读containers),如此性能怎能不是瓶颈,怎能不是个毛病?
Perfect Hash, 呵呵,优势大了去了!虽然比bit vector 占用多点的空间,可是少了大量的磁盘IOs。你说是进步吗?既然,我们不能从再缩小空间找到突破口,我么只能从其他地方下手。于是,优化bit vector 的disk io 是也。
可以看出,没有绝对的两全其美。时间换空间,正确率换空间,空间换时间等等,有无相生,此消彼长。
啊!扯远了。
下面就介绍到了how to use perfect hash。何为perfect hash ,其定义如下:
Definition
–(a)A functionh: U → [m]is called a
perfect hash function(PHF)forS ⊆ Uif
h is one-to-one on S. (m>=n)
–(b)A functionh: U → [m]is called a
minimal perfect hash function (MPHF)forS ⊆ Uif
h is a PHF and m = n = |S|.
–(c)For integerk ≥ 1, a functionh: U → [m]
is called a k-perfect hash function (k-PHF)forS ⊆ Uif for every
j ∈ [m] we have | {x ∈ S | h(x) = j}| ≤ k.
如何利用呢?
•When
–通常情况下,PHF或MPHF是针对静态集合的。也就是,在使用PHF或MPHF时,所有的 KEY 值是事先已知并且固定的。
•Process
–1. (准备阶段)将已知的所有的 KEY 值传给PHF或MPHF生成算法,生成PHF或MPHF以及相应的数据;
–2. (使用阶段)调用已有的PHF或MPHF以及相应的数据快速计算哈希值并进行相应的操作。其实在实际使用中我们只关 心 步骤2,但步骤1的生成算法却是PHF或MPHF的关键。
其准备阶段,也就是构造过程如下图所示。
[align=left] [/align]
具体可参考论文:Hash, displace, and compress.
回归原文,文章主要也最核心的贡献就是:如何利用此方法应用到重删的删除中。wou ! 这真是了不起。这就是思维所致,并不一定你要有多么伟大的idea才能成就丰功伟业。
具体过程就是:
•Merge phase
•Analysis phase
•Enumeration phase
•Copy phase
•Zero phase
一言以蔽之,更具全局索引(global index) 建立完美哈希,然后扫描一遍文件谱(file recipe),标记其活着还是死去的。最后扫描一遍所有的container,如果存在死的块,也就是被删了的块,则copy此container 到一个新的container,然后清空旧的container。
[align=left] [/align]
严谨的表述,论文提到静态的删除机制,当然也提到了动态的删除机制。所谓考虑全面,才能体现大家风范。作为一个学者,不得不如此。上图是一个静态删除过程,也就是没有作业备份恢复的前提下。
不知道为什么,如果copy 了container,全局索引的映射表需要更改啊!copy 多少,就要改多少。其实也是个麻烦。论文有意避之,不可不察。他的数据也表明,大量的时间花在read and copy container 阶段,此处需要更进一步的优化。对于动态的删除机制,论文并不详细。
更多文章见: http://www.zhihuluntan.com/forum.php?mod=viewthread&tid=493&page=1&extra=#pid684
Memory Efficient Sanitization of a Deduplicated Storage System:此文章首先introduce 数据的重要性,堂而皇之的冠以“敏感数据”(the sensitive data),说要达到“删除敏感数据,就想从没存储过似的”,然后是长篇介绍thread mode 及删除的必要性,重要性。好庄重的文章,不看到最后,我以为这是搞安全的呢?!
然后煞有介事的给我们将条例(如下)。(ps:好像在说,你看,我们都定出规则来了,别人没有吧?)
P1: All deleted data are erased.
P2: All live data are available.
P3: Sanitization is efficient.
P4: The storage system is usable while sanitization runs.
如果你愿意一层一层,一层的剥开我的心,你会发现你会讶异。paper,高质量的paper,就得耐心的看,因为人家也是花了很长
很长的时间才写下了这么successful paper. 写着有耐心,读者更需耐心。
如图所以,终于要进入主题啦!四种删除机制所用内存比较。
Reference counts 保证不了可靠性,如果服务中断,或者宕机等事故发生,大量的事务回滚操作烦烦烦!而亲也占用空间。
Bloom Filter 真是一大进化,以牺牲时间(多次hashing)和 一定的正确率(很多paper 说 发生的概率像磁盘发生错误一样的低)
来节省空间。但是,错误率虽然低,可毕竟还是存在风险与缺陷。(你人是好,可是不够帅)
Bit Vector 可又是一大突破,减,减,减!以1bit 代表一个数据块,利用率已经到极致。可惜,需要多次读disk(多次读containers),如此性能怎能不是瓶颈,怎能不是个毛病?
Perfect Hash, 呵呵,优势大了去了!虽然比bit vector 占用多点的空间,可是少了大量的磁盘IOs。你说是进步吗?既然,我们不能从再缩小空间找到突破口,我么只能从其他地方下手。于是,优化bit vector 的disk io 是也。
可以看出,没有绝对的两全其美。时间换空间,正确率换空间,空间换时间等等,有无相生,此消彼长。
啊!扯远了。
下面就介绍到了how to use perfect hash。何为perfect hash ,其定义如下:
Definition
–(a)A functionh: U → [m]is called a
perfect hash function(PHF)forS ⊆ Uif
h is one-to-one on S. (m>=n)
–(b)A functionh: U → [m]is called a
minimal perfect hash function (MPHF)forS ⊆ Uif
h is a PHF and m = n = |S|.
–(c)For integerk ≥ 1, a functionh: U → [m]
is called a k-perfect hash function (k-PHF)forS ⊆ Uif for every
j ∈ [m] we have | {x ∈ S | h(x) = j}| ≤ k.
如何利用呢?
•When
–通常情况下,PHF或MPHF是针对静态集合的。也就是,在使用PHF或MPHF时,所有的 KEY 值是事先已知并且固定的。
•Process
–1. (准备阶段)将已知的所有的 KEY 值传给PHF或MPHF生成算法,生成PHF或MPHF以及相应的数据;
–2. (使用阶段)调用已有的PHF或MPHF以及相应的数据快速计算哈希值并进行相应的操作。其实在实际使用中我们只关 心 步骤2,但步骤1的生成算法却是PHF或MPHF的关键。
其准备阶段,也就是构造过程如下图所示。
[align=left] [/align]
具体可参考论文:Hash, displace, and compress.
回归原文,文章主要也最核心的贡献就是:如何利用此方法应用到重删的删除中。wou ! 这真是了不起。这就是思维所致,并不一定你要有多么伟大的idea才能成就丰功伟业。
具体过程就是:
•Merge phase
•Analysis phase
•Enumeration phase
•Copy phase
•Zero phase
一言以蔽之,更具全局索引(global index) 建立完美哈希,然后扫描一遍文件谱(file recipe),标记其活着还是死去的。最后扫描一遍所有的container,如果存在死的块,也就是被删了的块,则copy此container 到一个新的container,然后清空旧的container。
[align=left] [/align]
严谨的表述,论文提到静态的删除机制,当然也提到了动态的删除机制。所谓考虑全面,才能体现大家风范。作为一个学者,不得不如此。上图是一个静态删除过程,也就是没有作业备份恢复的前提下。
不知道为什么,如果copy 了container,全局索引的映射表需要更改啊!copy 多少,就要改多少。其实也是个麻烦。论文有意避之,不可不察。他的数据也表明,大量的时间花在read and copy container 阶段,此处需要更进一步的优化。对于动态的删除机制,论文并不详细。
更多文章见: http://www.zhihuluntan.com/forum.php?mod=viewthread&tid=493&page=1&extra=#pid684
相关文章推荐
- Low-overhead enhancement of reliability of journaled file system using solid state storage and de-duplication
- 解决 ASP.NET 中 System.OutOfMemoryException 的问题
- System.OutOfMemoryException
- C#打开tif文件时内存溢出(System.OutOfMemoryException)解决办法
- iTron3学习笔记(一) System Calls of Memory Pool Management Functions
- Xap 包装失败。引发类型为“System.OutOfMemoryException”的异常
- Problems with System.OutOfMemoryException At System.String.GetStringForStringBuilder in 32-Bit Managed Solutions
- System.OutOfMemoryException: 引发类型为“System.OutOfMemoryException”的异常
- Exception of type System.OutOfMemoryException was thrown.
- Needle in a haystack: efficient storage of billions of photos 【转】
- ASP.NET 中关于 System.OutOfMemoryException 的问题与解决方法
- OutOfMemoryError: Cannot create GC thread. Out of system resources
- 项目中遇到System.StackOverflowException和System.OutOfMemoryException
- .Net 内存溢出(System.OutOfMemoryException)
- GridView输入Excel时出现"System.OutOfMemoryException: Out of memory"及其解决方案。
- Problems with System.OutOfMemoryException At System.String.GetStringForStringBuilder in 32-Bit Managed Solutions
- 每日一命令(13)free - (Display amount of free and used memory in the system)
- 解决 Xap 包装失败。引发类型为“System.OutOfMemoryException”的异常
- Exception of type 'System.OutOfMemoryException' was thrown.
- 一周乱弹(0624 1,maven 添加依赖包.2,sqlserver 删除语句.3..OutOfMemoryError: PermGen space。4,SQL datediff (时间差)