1

建议的存储模型是将附件存储在单独的文件（或 blob）中，并将电子邮件本身存储为 MIME 多部分消息，其中包含对附件的引用及其编码方式。这允许用户显示原始，但不需要我实际存储效率较低的 base64 与消息。大多数情况下，我将能够只存储使用的 base64 行长度。

这样，我们可以执行附件级别的重复数据删除。

但重复数据删除如何走得更远？以下是我的想法：

  • 当然，所有附件和电子邮件都可以单独压缩（字节级重复数据删除）。
  • 我可以将 12 个附件的集合压缩到一个文件中。压缩相同类型的多个文件（例如 PDF），即使是来自同一发件人的文件，可能更有效。
  • MIME 消息也可以成组压缩。
  • 我不关心搜索效率，因为会使用全文索引。
  • 搜索电子邮件当然会使用一种全文索引，它不会被压缩。
  • 解压缓存将在电子邮件第一次到达时创建，并且仅在一段时间未查看电子邮件后才会被删除。

您在这方面有什么建议吗？电子邮件存储系统的正常情况是什么？

4

1 回答 1

0
  1. 解码所有 base64 mime 部分，不仅是附件
  2. 计算其内容的安全哈希
  3. 用电子邮件正文中的参考替换部分，或使用提取的 mime 部分列表创建自定义标题
  4. 存储在安全哈希下的 blob 存储中（内容可寻址存储）
  5. 使用引用计数器进行删除和垃圾收集，或更智能的双计数器（https://docs.wildduck.email/#/in-depth/attachment-deduplication，https://medium.com/@andrewsumin/efficient-storage-how -we-went-down-from-50-pb-to-32-pb-99f9c61bf6b4 )
  6. 或将每个引用关系 hash-emailid 存储在 db 中
  7. 仔细检查和控制 base64 折叠，有些邮件中间有较短的行，有些邮件末尾有附加字符（点、空格）
  8. 将编码参数（折叠、尾部）存储在电子邮件正文中的参考中以进行精确重建
  9. 压缩可压缩附件，注意内容可添加存储，因为压缩会改变其内容哈希
  10. jpeg 图像可以使用 JPEG XL 或https://github.com/dropbox/lepton进行显着无损压缩
  11. wav 文件可以使用 flac 等进行压缩。
  12. 内容类型是发件人指定的，同一个附件可以有不同的内容类型
  13. 引用的可打印编码部分很难准确解码和重建。编码器参数很多，因为每个编码器转义不同的字符和折行的方式不同。
  14. 请注意参考格式，因此恶意发件人无法使用参考创建电子邮件并获取他不拥有的附件。或在收到的电子邮件中检测和转义参考
  15. 在系统中存在特定数量的重复之前，小的 mime 部分可能不值得提取
于 2022-01-29T12:35:11.163 回答