存储对象时需要元数据存储

Question

在检查pastebin之类的服务设计时，我注意到两种不同存储系统的用法：

1. 用于存储实际“粘贴”数据的对象存储（例如Amazon S3）
2. 元数据存储区，用于存储与该“粘贴”数据有关的其他内容；例如- URL哈希（用于访问粘贴数据），对实际粘贴数据的引用等。

我正在尝试了解此元数据存储的需求。

这通常是推荐的方法吗？通过使用元数据存储，我们有什么特别的优势？

对象存储系统是否不允许将元数据与实际对象一起存储在相同存储服务器中？

Answer 1

对象存储系统通常确实允许将大量元数据附加到对象。

但是您的元数据却受对象存储的支配。

• 您的元数据搜索仅限于对象存储所允许的内容。
• 分析，通知（a-la inotify）等仅限于对象存储允许的范围。
• 如果您想从S3迁移到Google Cloud Storage，或者同时执行这两项操作，则必须对元数据进行规范化。
• 您的元数据大小限制仅限于对象库的大小。
• 您不能进行跨对象存储的元数据（例如，引用多个粘贴数据的链接）。
• 您可能无法使用二进制元数据。

通常，元数据不仅非常重要，而且业务使用率很高，因此它具有与数据不同的使用特征，因此将其存储在具有不同特征的存储中是很有意义的。

我在任何地方都找不到pastebin.com是如何赚钱的，所以我不知道它们使用元数据的程度，但是仅仅是查找（URL和粘贴数据之间的转换），您不能对对象进行安全的处理单独存储。

Answer 2

上面的一个很好的答案，只是要补充-还有两个优点是分别缓存和扩展两个存储系统。

1. 如果您仅使用对象存储，并且说粘贴为5 MB，您是否会缓存全部？元数据存储还可以通过缓存例如粘贴的前10或100 KB数据供用户预览来改善UX，同时完整的对象在后台获取。此上限还有助于确定性地设计缓存。
2. 您还可以根据性能/容量需求，彼此独立地缩放对象存储和元数据存储。元数据存储区中的查询也更快捷，因为它的体积较小。

您的担心是合理的，即将存储分为2个表（或介质）确实会增加一些延迟，但是这始终是系统设计的折衷方案，几乎没有双赢的情况。