Положительным моментом является то, что вы можете уменьшить общую задержку до нескольких секунд; однако основной недостаток заключается в том, что если ваши транзакционные данные сильно изменяются, вам придется создать схему управления версиями для отслеживания изменений.
рабатываю решение, в котором Google Cloud SQL будет использоваться для хранения всех данных, поступающих от обычного функционирования приложения (вид данных OLTP). Ожидается, что данные со временем вырастут в довольно большой размер. Сами данные носят реляционный характер, и поэтому мы выбрали Cloud SQL вместо Cloud Datastore.
Эти данные должны быть переданы в Big Query для аналитики, и они должны быть близки к аналитике в реальном времени (в лучшем случае), хотя реально можно ожидать некоторой задержки. Но я пытаюсь разработать решение, которое уменьшит эту задержку до минимума.
Мой вопрос состоит из 3 частей -
Должен ли я использовать Cloud SQL для хранения данных, а затем переместить их в BigQuery или изменить сам базовый дизайн и использовать BigQuery для первоначального хранения данных? Подходит ли BigQuery для использования при обычных рабочих нагрузках OLTP с низкой задержкой? (Я так не думаю - верно ли мое предположение?)
Какова рекомендуемая / лучшая практика для загрузки данных Cloud SQL в BigQuery и работает ли эта интеграция практически в реальном времени?
Является ли Cloud Dataflow хорошим вариантом? Если я подключу Cloud SQL к Cloud DataFlow и далее к BigQuery - это будет работать? Или есть другой способ добиться этого, который лучше (как задано в вопросе 2)?