Использование Firestore в качестве кэша для агрегации SQL

Я не уверен, что это место, чтобы спросить об этом, но у меня есть вопрос с лучшей практикой.

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

В настоящее время данные регулярно вытаскиваются и хранятся в базе данных SQL, которая сопоставляется с REST API, которую клиентское приложение вызывает для получения агрегирования между двумя значениями даты, и будет дополнительно подаваться вызовами Webhook через триггеры SF SF.

Я хочу знать, хорошая ли идея наличия коллекции Firestore в качестве кэша для агрегированного SQL, или если есть лучший подход. Преимущества, которые я вижу, уменьшают трафик на моем SQL-сервере, мгновенные обновления (если обновляется «кеш» (Firestore), значение клиента также мгновенно обновляется).

Когда данные извлекаются из SF или новая запись принимается через Insert Trigger / Webhook, я могу обновить запись Firestore, и клиент немедленно получит это изменение.

Моя идея для документа Firestore была бы

{
  user: "123",
  sfOwnerId: "124",
  sfTaskType: "Opportunities Closed Won This Week",
  count: 23
} 

Это хорошая идея? Есть ли там лучший?

Заранее благодарю!

Всего 1 ответ


Ваша стратегия хранения агрегированных данных - это то, что предлагает документация Firestore для агрегации, поэтому я думаю, что это довольно прочная идея.

Альтернативной стратегией было бы только сохранение данных Salesforce в Firestore по мере их поступления, а не агрегирование, и пусть клиент выполняет агрегацию. Это может быть достигнуто путем подписки на обновления в реальном времени на запрос коллекции . В этой настройке вы будете выполнять вычисления в onSnapshot (при условии, что вы используете веб-среду).

Преимуществом здесь является возможное повышение производительности, поскольку функции облачности часто страдают от задержки «холодного запуска».

Примечание. Некоторые рекомендации в этом документе сосредоточены вокруг так называемого холодного запуска. Функции не имеют состояния, и среда выполнения часто инициализируется с нуля, что называется холодным запуском. Холодный запуск может занять значительное количество времени. Лучше всего избегать ненужных холодных запусков и оптимизировать процесс холодного запуска в любой возможной степени (например, избегая ненужных зависимостей).

Источник


Есть идеи?

10000