У меня есть таблица необработанных данных в большом запросе, которая имеет сотни миллионов строк. Я запускаю запланированный запрос каждые 24 часа, чтобы получить некоторые агрегаты, которые приводят к тому, что таблица с контрольной отметкой в 33 миллиона строк (6 ГБ) будет расти медленно, примерно вдвое по сравнению с ее текущим размером.
Мне нужен способчтобы получить по одной строке за один раз быстрый доступ по идентификатору к этой статистической таблице в отдельном конвейере, управляемом событиями. то есть процесс уведомляется о том, что человек А только что совершил действие. Что мы знаем об истории этого человека из таблицы агрегации?
Очевидно, большой запрос - это правильный инструмент для создания таблицы агрегирования, но не правильный инструмент длябыстрый поиск. Поэтому мне нужно сместить его во вторичное хранилище данных, например, в Firestore. Но как лучше всего это сделать?
Я могу представить пару стратегий:
1) Запланировать дамп таблицы agg в GCS. Начните задание потока данных для потоковой передачи содержимого дампа gcs на pubsub. Создайте безсерверную функцию для прослушивания темы pubsub и вставьте строки в firestore.
2) Длительный скрипт на вычислительном движке, который просто транслирует таблицу прямо из BQ и выполняет вставки. (Кажется, медленнее, чем стратегия 1)
3) Запланируйте дамп таблицы agg в GCS. Отформатируйте его таким образом, чтобы его можно было напрямую импортировать в firestore через gcloud beta firestore import gs://[BUCKET_NAME]/[EXPORT_PREFIX]/
4) Может быть, какое-то задание потока данных, которое выполняет поиск непосредственно в таблице больших запросов? Не играл с таким подходом раньше. Не знаю, насколько это дорого / производительно.
5) какой-то другой вариант, который я не рассматривал?
Идеальное решение позволило бы мне получить быстрый доступ в миллисекундах к строке агг, который позволил бы мне добавитьданные к событию в реальном времени.
Есть ли явный лучший победитель в стратегии, которую я должен преследовать?