提问人：knightcool 提问时间：7/3/2020 更新时间：9/20/2020 访问量：187
存储对象时需要元数据存储
Need for metadata store while storing an object
问：
在检查像 pastebin 这样的服务的设计时，我注意到使用了两种不同的存储系统：
- 用于存储实际“粘贴”数据的对象存储（如 Amazon S3）
- 元数据存储，用于存储与该“粘贴”数据相关的其他内容;例如 - URL Hash（用于访问该粘贴数据）、对实际粘贴数据的引用等。
我正在尝试了解对此元数据存储的需求。
这通常是推荐的方式吗？我们从使用元数据存储中获得了什么具体优势？
对象存储系统是否不允许将元数据与实际对象一起存储在同一个存储服务器中？
答：
2赞
root
7/6/2020
#1
对象存储系统通常允许将相当多的元数据附加到对象。
但是，您的元数据将受到对象存储的摆布。
- 元数据搜索仅限于对象存储允许的范围。
- 分析、通知 （a-la inotify） 等仅限于对象存储允许的范围。
- 如果您想从 S3 迁移到 Google Cloud Storage，或者两者兼而有之，则必须规范化元数据。
- 元数据大小限制仅限于对象存储的大小限制。
- 您不能执行跨对象存储元数据（例如，引用多个粘贴数据的链接）。
- 您可能无法拥有二进制 metdata。
通常，元数据既非常重要，又被业务大量使用，因此它具有与数据不同的使用特征，因此将其放在具有不同特征的存储中是有意义的。
我在任何地方都找不到 pastebin.com 是如何赚钱的，所以我不知道他们使用元数据的程度，但仅仅是查找，URL 和粘贴数据之间的转换，不是仅使用对象存储可以安全地完成的事情。
1赞
Ujjwal Vaish
9/20/2020
#2
上面的答案很好，只是为了补充 - 另外两个优点是单独缓存和扩展两个存储系统。
- 如果您只使用对象存储，并假设粘贴为 5 MB，您会缓存所有内容吗？元数据存储还允许通过缓存前 10 或 100 KB 的数据来改善用户体验，例如粘贴供用户预览，同时在后台获取完整的对象。此上限还有助于确定性地设计缓存。
- 您还可以根据性能/容量需求独立扩展对象存储和元数据存储。元数据存储中的查找速度也会更快，因为它不那么笨重。
您的担忧是有道理的，将存储分成 2 个表（或介质）确实会增加一些延迟，但这始终是对系统设计的妥协，几乎没有双赢的局面。
评论