Sql 防止BigQuery垃圾邮件

我有以下软件组件：

• 亚马逊运动事件流
  • 事件表示例：

    产品购买事件

• BigQuery数据库接收+存储事件
  • 查询示例：

    从product purchase events GROUP BY day中选择count（*）作为计数，日期（时间戳）作为日期

• 公开API的微服务确实运行一组预定义的BigQuery查询
  • 示例端点：

    GET/product purchase event/？step=DAY

• 使用查询API公开漂亮图形的公共web应用程序

事实：每次查询的BigQuery账单和flatrate非常昂贵

问题：如果有人向

GET/product purchase事件

端点发送垃圾邮件，每次呼叫都将执行一个新的查询，这意味着在一百万次垃圾邮件查询之后，我将收到一张非常好的账单

我的问题：你能保护BigQuery吗？我知道有24小时缓存，但我希望数据尽可能实时

---

我也知道还有其他解决方案，比如Amazon Redshift，它每小时收费，而不是每查询收费，但我想知道我是否可以用BigQuery解决这个垃圾邮件问题。似乎大多数人只在内部使用它，这意味着没有外部人员可以执行查询，因此垃圾邮件不是问题。

正如您正确猜测的那样，将交互式公共web端点连接到直接运行BigQuery查询的处理程序是个坏主意（tm）。这里有多个因素，包括成本和延迟。此外，查询接收流式插入的表意味着您将无法利用基本的BigQuery，并且一旦您的公共处理程序开始获得合理的负载量，就会很快达到并发限制

这里更典型的模式是通过BigQuery查询定期计算聚合，然后将这些查询结果读取并传播到更适合以点查找方式提供结果的存储层/系统中。例如，数据存储、内存中的键值存储，甚至是云SQL之类的东西

这将使您的服务体系结构与数据处理分离，并且公共处理程序大大简化：它只是从存储层获取聚合

---

您还可以更细致地处理“我们何时重新计算”。您可以将处理定义为只需在固定的时间间隔内重新运行，利用对数据陈旧性的感知，或者基于环境中的其他信号构建一些自定义缓存语义。

Upvoted@shollyman的答案。如果延迟不是一个问题，那么定期将数据聚合到一个小得多的表中，并将web前端连接到摘要表可能是一个选项。BigQuery缓存在这种情况下工作。但如果你真的收到100万个垃圾邮件请求，我相信你仍然会超出BigQuery的配额。SoLyman提出了一些方法来缓存结果，这是你应该考虑的。