将文档/*LOB 的元数据(或索引数据)与原始数据分开存储是否有优势。
例如，有一个表/集合/桶，索引为(姓名，学校)
ID: 123 name: Johny School: Harvard Transcript: /*2MB text/binary*/
对比
元数据
ID: 123 name: Johny School: Harvard
数据
ID: 123 Transcripts: /*2MB text/binary*/
让我们假设 mongodb，尽管它可能真的与数据库无关。
db.firstModel.find({},{transcripts:0})对比db.secondModel.find()
此外，如果我们对元数据进行聚合/分组，转录本中的重负载是否会压低它(即使聚合在其他字段上)？单独聚合元数据集合，然后通过数据集合中的 id 检索是否更好？还是尊重数据库设计(将所有内容耦合在一个文档中)更好？
最佳答案
在 Couchbase 中，如果它适用于您的用例，一个选项可能是让您的 2MB 文档的对象 ID 类似于 harvard::johny::123。每个对象都会有一个这样的模式，用于在您的应用程序中一致使用的每个对象 ID。因此，您的应用程序可以轻松地将对象 ID 拼凑在一起。这样您就不必查询或使用 View 。你知道它是 harvard and johny and his 123rd object，你可以通过 ID 得到它。您已经知道答案，无需查询，因此 Couchbase 会非常快。
话虽这么说，但您可能还想在该元数据对象中保留其他元数据，并且希望建立索引，然后是的，在 Couchbase 中，最好像您建议的那样分解文档。在 Couchbase 中，将它们放在单独的存储桶中甚至可能更好，这样索引器只会查看它将索引的内容。
举一个可能不完全适用于您的用例的示例，但应该让您了解什么是可能的 go here
综上所述，根据经验，无论数据库如何，我都不喜欢像您建议的那样在数据库中长期保留更大的对象。从运营的角度来看，这很糟糕。您正在将相当于静态数据的数据存储在一个需要非常高性能的层中，通常具有昂贵的存储空间并且必须随着时间的推移备份这些对象。几个月/几年后，它们会成为您脖子上的船 anchor 。我建议将元数据保存在一个快速执行的系统中，如 Couchbase(缓存+复制持久性等)，它也有一个指向大型对象的指针，最适合分发大型静态对象，如 HDFS、Amazon S3 等.
关于oracle - 分开存储元数据和原始数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31200170/