适用于具有自动递增id的原始JSON事件的Google Cloud数据存储选项

Question

我正在寻找一个合适的google数据/存储选项，作为一个位置来流式传输原始的，JSON事件。

这些事件是由用户在响应非常大的电子邮件广播时生成的，因此在短时间内吞吐量可能非常低，最高可达每秒约25,000个事件。这些事件的JSON表示可能只有1kb左右

我想简单地将这些事件存储为原始和未处理的JSON字符串，仅附加，并为插入的每个记录使用单独的连续数字标识符。我计划使用这个标识符作为消费应用程序的一种方式，以便能够顺序地处理流(类似于Kafka消费者通过流跟踪他们的偏移量的方式)-这将允许我从我选择的点重放事件流。

我正在利用Google Cloud Logging聚合来自计算引擎节点的事件流，从这里我可以直接流到BigQuery表或发布/订阅主题中。

BigQuery似乎完全有能力处理流插入，但是它似乎没有自动递增id列的概念，并且还建议它的查询模型最适合聚合查询，而不是窄结果集。我查询下一个最高行的要求显然与此背道而驰。

我目前最好的想法是推入Pub/Sub，并让它将每个事件写入到云SQL数据库中。这样，如果Cloud SQL跟不上，发布/订阅就可以缓冲事件。我想要一个自动标识符，可能还有一个日期戳列，这让我觉得这是一个‘表格’用例，因此我觉得NoSQL选项可能也不合适

如果有人有更好的建议，我很乐意得到一些意见。

Answer 1

我们知道许多客户已经成功地使用BigQuery实现了这一目的，但如果您想提供自己的标识符，则需要进行一些工作来选择适当的标识符。从您的示例中，我不清楚为什么不能只使用时间戳作为标识符，并使用摄取时间分区表流摄取选项？

https://cloud.google.com/bigquery/streaming-data-into-bigquery#streaming_into_ingestion-time_partitioned_tables

就Cloud Bigtable而言，Les在评论中指出：

Cloud Bigtable绝对可以跟上，但并不是真的为使用顺序键的顺序添加而设计的，因为这会创建热点。

请参阅:您可以参考此https://cloud.google.com/bigtable/docs/schema-design-time-series#design_your_row_key_with_your_queries_in_mind

您可以在这里再次使用时间戳作为键，尽管您可能需要做一些工作，例如添加散列或其他唯一标识符，以确保在25k写入/秒的峰值时不会使单个节点不堪重负(我们通常可以处理每个节点每秒约10k行的修改，如果您只使用字典顺序的ID，如递增的数字，则所有写入都将发送到同一服务器)。

无论如何，看起来BigQuery可能是您想要使用的。您还可以参考此博客文章，以获取通过BigQuery：https://medium.com/streak-developer-blog/using-google-bigquery-for-event-tracking-23316e187cbd进行事件跟踪的示例