我正在设计一个解决方案，其中谷歌云SQL将用于存储应用程序正常运行中的所有数据（一种联机事务处理数据）。随着时间的推移，数据预计会变得相当大。数据本身本质上是关系的，因此我们选择了云SQL而不是云数据存储。
这些数据需要输入Big Query进行分析，这需要接近实时分析（最好的情况），尽管实际上可以预期会有一些滞后。但我正在尝试设计一个解决方案，将这种滞后降至最低。
我的问题有三个部分-
>
我应该使用云SQL存储数据，然后将其移动到BigQuery，还是改变基本设计本身，最初也使用BigQuery存储数据？BigQuery适合用于常规、低延迟的联机事务处理工作负载吗？（我不这么认为-我的假设正确吗？）
将云SQL数据加载到BigQuery并使这种集成近乎实时地工作的推荐/最佳实践是什么？
云数据流是一个好的选择吗？如果我将云SQL连接到云数据流并进一步连接到BigQuery-它会工作吗？或者有没有其他更好的方法来实现这一点（如问题2所问）？
看看WePay是如何做到这一点的：
MySQL到GCS运算符对MySQL表执行SELECT查询。SELECT拉取大于（或等于）最后一个高水印的所有数据。高水印要么是表的主键（如果表是仅追加的），要么是修改时间戳列（如果表接收更新）。同样，SELECT语句还可以追溯一点时间（或行），以捕获上次查询中可能删除的行（由于上述问题）。
使用Airflow，他们设法每15分钟将BigQuery同步到他们的MySQL数据库。
BigQuery支持云SQL联合查询，让您可以直接从BigQuery查询云SQL数据库。为了保持云SQL表与BigQuery同步，您可以编写一个简单的脚本，并使用以下查询每小时同步两个表。
INSERT
demo.customers (column1)
SELECT
*
FROM
EXTERNAL_QUERY(
"project.us.connection",
"SELECT column1 FROM mysql_table WHERE timestamp > ${timestamp};");
只需记住将${timestamp_}替换为当前时间戳-1小时。
另一种方法是将写入过程拆分为CloudSQL和Cloud Pub/Sub，然后有一个数据流阅读器来流式传输到BigQuery。当您的BigQuery表的目标模式有很大不同时，这很有效——这在非规范化关系数据时很常见。
好处是您可以将整体延迟减少到几秒钟；然而，主要的缺点是，如果您的事务数据高度变异，您将不得不创建版本控制方案来跟踪更改。
