Оптимальный способ решения запросов (избыточных) данных

Question

У меня возникла дилемма, как решить возможные избыточные запросы данных.

Я использую MongoDB с сервером и клиентом Apollo. В моем MongoDB есть несколько коллекций данных. Основная коллекция состоит из идентификаторов, указывающих на поддерживающие коллекции.

Я не уверен, как решить сопоставление идентификаторов моей основной коллекции с идентификаторами вспомогательных коллекций для получения фактических значений. Дело в том, что в основном у меня уже есть данные поддерживающих коллекций, кэшированные в клиентском кеше Apollo.

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

Я ценю любое понимание! Спасибо.

Answer 1

Как всегда, это зависит. Я предполагаю, что это ваша установка, с основной коллекцией .

type OtherDoc {
  id: String
  field: String
}

type MainDoc {
  id: String
  otherDocs(param: String): [OtherDoc]
}

type Query {
  mainDocs: [MainDoc]
}

В таком случае, запрос на mainDocs { id otherDocs("...") { id field } }, безусловно, является естественным способом получить эти данные. Это может быть избыточным с точки зрения получения OtherDoc, когда разные param приводят к одним и тем же документам. Если это так, вы можете подумать о том, чтобы запрашивать только их идентификаторы, а затем запрашивать отдельные документы, если у клиента их нет.

Я бы сказал, что это правильное решение, но определенно не то, что вы должны рассмотреть с самого начала. Эта оптимизация определенно ограничит пропускную способность, но увеличит количество запросов. Более того, вы не знаете, когда на самом деле повторно набрать OtherDoc. Ну, может быть, вы делаете, но вы должны подумать и построить это, где без вас это будет готово.

Другой подход, более дружественный к кэшу, может изменить схему, чтобы ограничить такие ситуации, когда ваши данные перекрываются. Это не всегда возможно из-за бизнес-логики, но стоит подумать, если это так.