Хранение метаданных и необработанных данных отдельно

Question

Есть ли преимущество хранения метаданных (или данных индексирования) для документа/* LOB отдельно от необработанных данных.

Например, имеющий таблицу/сбор/ведро с индексом на (имя, школа)

 
ID: 123 
name: Johny 
School: Harvard 
Transcript: /*2MB text/binary*/ 

против

Metadata

 
ID: 123 
name: Johny 
School: Harvard 

данных

 
ID: 123 
Transcripts: /*2MB text/binary*/ 

Предположим, что mongodb, хотя это, возможно, и db агностик.

db.firstModel.find({},{transcripts:0})

против

db.secondModel.find()

Кроме того, если мы агрегация/группировка по метаданным, будет тяжелая полезная нагрузка в транскриптах весить его вниз (даже несмотря на то, агрегации на других областях)? лучше ли агрегировать в коллекции метаданных по отдельности, а затем извлекать по идентификатору из коллекции данных? Или лучше уважать дизайн базы данных (сохраняя все в одном документе)?

Answer 1

В Couchbase, если он работает для вашего прецедента, может потребоваться указать идентификатор объекта для вашего документа 2MB примерно как harvard :: johny :: 123. Каждый объект имеет такой шаблон для каждого идентификатора объекта, который будет использоваться последовательно в вашем приложении. Поэтому ваше приложение легко объединяет идентификатор объекта. Тогда вам не нужно запрашивать или использовать представления. Вы знаете, что это гарвард и джонни и его 123-й объект, вы можете просто получить его по ID. Вы уже знаете ответ, не запрашиваете, и поэтому Couchbase будет очень быстрым.

Это, как говорится, могут быть другие метаданные, которые вы хотите сохранить в этом объекте метаданных и хотите индексировать, а затем да, в Couchbase, возможно, было бы лучше вырвать документы, как вы предлагаете. В Couchbase было бы даже лучше разместить их в отдельных ведрах, чтобы индексы смотрели только на то, что он будет индексировать.

Для примера, которые не могут быть полностью применимы к вашему прецеденту, но должно дать вам представление о том, что возможно go here

Все это, как говорится, из опыта, я не люблю держать больший объект, как вы предлагать в DB на долгосрочной основе, независимо от БД. С оперативной точки зрения это ужасно. Вы сохраняете то, что составляет статические данные в слое, который должен быть очень эффективным, с обычно дорогостоящим хранилищем и с возможностью резервного копирования этих объектов с течением времени. После нескольких месяцев/лет они становятся лодочным якорем на шее. Я предлагаю хранить метаданные в быстродействующей системе, такой как Couchbase (кеш + персистенция с репликацией и т. Д.), Которая также имеет указатель на большие объекты в том, что лучше всего подходит для поиска больших статических объектов, таких как HDFS, Amazon S3 и т. Д. .