存储与原始数据分开的文档/ * LOB的元数据（或索引数据）是否有利。
例如，有一个表（/名称，学校）的表/集合/桶
ID: 123 name: Johny School: Harvard Transcript: /*2MB text/binary*/
VS
元数据
ID: 123 name: Johny School: Harvard
数据
ID: 123 Transcripts: /*2MB text/binary*/
让我们假设mongodb，虽然它可能真的与数据库无关。
db.firstModel.find({},{transcripts:0}) vs db.secondModel.find()
此外，如果我们对元数据进行聚合/分组，那么成绩单中的重负载会不会对其进行权衡（即使聚合在其他字段上）？最好是单独聚合元数据集合，然后通过数据集合中的id检索？或者更好地尊重数据库设计（将所有内容保存在一个文档中）？
答案 0 :(得分：0)
在Couchbase中，如果它适用于您的用例，则选项可能是使您的2MB文档的对象ID类似于 harvard :: johny :: 123 。对于在应用程序中一致使用的每个对象ID，每个对象都有这样的模式。因此，您的应用程序可以轻松拼凑对象ID。然后您不必查询或使用视图。你知道这是哈佛和johny以及他的第123个对象，你可以通过ID获得它。你已经知道了答案，没有查询，所以Couchbase会非常快。
话虽如此，可能还有其他元数据要保留在该元数据对象中，并且您希望索引然后是，在Couchbase中，最好像您建议的那样分解文档。在Couchbase中，将它们放在单独的桶中可能更好，因此索引器只会查看它将索引的内容。
有关可能不完全适用于您的用例的示例，但应该让您了解可能的内容go here
所有这一切，根据经验，我不喜欢像DB中长期建议的更大的对象，无论数据库如何。从运营的角度来看，这很糟糕。您在一个需要非常高效的层中存储多少静态数据，通常是昂贵的存储，并且必须随着时间的推移备份这些对象。几个月/几年后，它们成为你脖子上的船锚。我建议将元数据保存在一个快速执行的系统中，例如Couchbase（缓存+带复制的持久性等），它还有一个指向大对象的指针，最适合抛出大型静态对象，如HDFS，Amazon S3等。