Запросы Firebase возвращают слишком много документов в сложной модели данных - PullRequest
0 голосов
/ 30 сентября 2019

Я пытался выяснить, как лучше всего моделировать данные для сложной подачи в Cloud Firestore, не возвращая ненужные документы.

Вот проблема -

Контент создается для определенныхТемы, например: Архитектура, Мосты, Дамбы, Дороги и т. д. Параметры тем могут быть расширены, и в любой момент они могут включать столько, сколько необходимо. Это означает, что это растущий и развивающийся список.

Когда контент создается, он также привязывается к конкретным отраслям. Например, я могу захотеть создать пост в Архитектуре, и я хочу, чтобы его видели в отраслях Строительства, Стали и Бетона.

Вот тут-то и начинается сложная часть. Если я заинтересован в металлургической и строительной отраслях, я хотел бы получить фид, который включает в себя сообщения из обеих этих отраслей с конкретными темами «Мосты» и «Мосты». Плотины. Так как это подача, результаты должны быть в порядке времени. Как бы я мог создать этот канал?

Я рассмотрел следующие варианты:

  1. Запрос для каждой отдельной выбранной темы, которая включает теги для стали и строительства, затем агрегировать исортировать результаты. Проблема, с которой я столкнулся, заключается в том, что он может возвращать слишком много сообщений, что означает, что я читаю документы без необходимости. Если я выберу 5 тем в определенном временном интервале, это будет 5 запросов, и это нормально. Однако каждый может иметь любое возможное количество результатов, что является проблематичным. Я мог бы добавить ограничение, но затем я рискую опустить сообщения в темах, даже если они попадают в диапазон времени.

  2. Создать сообщение "index" таблицы в Cloud SQL и выполните запросы к ней, чтобы получить идентификаторы постов, а затем получите необходимые документы Firestore. Тогда возникает вопрос, почему бы просто не использовать Cloud MySql .... Ну, это проблема масштабирования, стоимости и обслуживания. Весь смысл пожарного магазина не в том, чтобы беспокоиться о администраторах баз данных, нагрузке и масштабе.

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

1 Ответ

1 голос
/ 30 сентября 2019

Идеальная структура состоит в том, чтобы иметь отдельный узел для постов, а затем для каждого поста вы указываете ему родительскую категорию, например, Сталь и строительство. Иметь их также с отметками времени. Если вы думаете, что база данных будет слишком большой для запросов Firebase. Вы можете подключить свою базу данных Firebase кasticsearch и выполнить поиск оттуда. Надеюсь, это поможет.

...