【问题标题】:How can you simulate "serverless" Cloud SQL?如何模拟“无服务器”云 SQL?
【发布时间】:2021-07-18 03:30:14
【问题描述】:

问题: Cloud SQL 实例无限期地运行并且托管成本很高。

目标:在不影响数据库可用性的同时节省资金。

已经快四年了,Google Cloud 还没有满足这个已经通过 Aurora RDS 在 AWS 上实施的功能请求。

由于自动缩放到零的按需 Cloud SQL 似乎不会很快出现,因此以下策略会奏效吗?

  1. 拥有 Cloud SQL 实例、一个 Baby 和一个 Papa。它们遵循主/从复制原则,带有扭曲。宝宝 实例很小,vCPU 很少,内存也很低,它总是运行,但是 这样做很便宜。但是,Papa 实例的 vCPU 和高 内存,但仅在需要时运行。
  2. 首先,只有 Baby Cloud SQL 实例在运行,因此它是接受读/写的主实例。 Papa Cloud SQL 实例未运行。
  3. 由于我使用的是标准应用引擎, 将在没有流量的情况下自动缩放到零,安排一个 cron 作业 如果不存在应用引擎实例,则每 10 分钟检查一次。在这种情况下, 该应用程序没有流量。如果不是这种情况,则启动 Papa Cloud SQL 实例。一旦启动,Papa 实例 成为接受读/写的主人,而婴儿实例 成为只能读取的从属副本。
  4. 如果 cron 作业检测到应用引擎有零个实例在运行,这意味着没有流量。因此,Papa Cloud SQL 实例是 停止,Baby Cloud SQL 副本被提升为主副本,并且可以接受读/写。
  5. 这样,昂贵的 Papa 实例按需运行。如果有交通 当 Papa 实例停止或重新启动时出现峰值,Baby 实例仍将能够响应请求。

此策略可确保昂贵的 Papa Cloud SQL 实例仅在流量下运行。 这种 Baby-Papa 动态是否可以在 Google Cloud 上实现?

【问题讨论】:

  • 有趣的提议,我想知道“爸爸”实例在被召唤时更新其数据需要多长时间。
  • 如果您计划使用此实例至少一年,您是否考虑过committed user discount - cloud.google.com/sql/cud?这种策略对你来说会更便宜吗?
  • @NoCommandLine 是的,有折扣的活动我需要更便宜的解决方案
  • 1) 当我们不接受现状时,就会产生有用的发明。但是,对于 Cloud SQL 等托管服务,请按设计使用它们。您的策略不适用于 Cloud SQL,因为该服务是为企业类型的应用程序而不是无服务器应用程序设计的。如果您想要无服务器 SQL,请使用无服务器 SQL 服务。今天,您可以轻松混合和匹配云供应商的产品。
  • 2) SQL 数据库使用内存来显着提高性能。 Serverless SQL 失去了这个特性,导致性能下降。在设计数据库时,除了价格之外,还有很多因素需要考虑。

标签: google-app-engine google-cloud-platform google-cloud-functions google-cloud-storage google-cloud-sql


【解决方案1】:

Cloud SQL 有一个Admin API,可用于以这种方式操作您的 Cloud SQL 实例。您可以使用Cloud Scheduler 构建您所描述的部分以触发Cloud Function,该Cloud Function 使用API​​ 来启动和停止实例,甚至将它们提升/降级为master。

但是,这可能是个坏主意。这些操作可能需要几分钟才能完成,并且会显着增加请求的冷启动时间。此外,SQL 服务器更喜欢长时间运行是有原因的——它们使用资源来缓存和优化查询以提高性能。启动、停止和调整实例大小可能会导致您失去这些好处。

最好考虑一下 - 您真的需要关系数据库吗?如果没有,最好使用Firestore 之类的东西,这是一个无服务器产品。

如果您确定确实需要关系数据库,是否可以针对较小的 Cloud SQL 实例优化使用?您可以使用上面列出的Memorystore 或 Firestore 缓存查询,还是使用我上面描述的服务来定时导出结果,这样更容易让您的应用使用?

在没有流量时启动和停止 Cloud SQL 实例会更好吗?如果您的流量基于某些可预测的时间,您可以安排您的实例在这些时间段的开始和结束时调整大小。

最后,如果成本确实是一个选项,您可以在 GCE 实例上运行自己的 SQL 服务器。这意味着您必须自己完成几乎所有的管理工作(安装、更新、维护等),但这会更便宜。

所有这些可能比试图硬塞非无服务器基础架构以匹配无服务器工作负载更具功能性的解决方案。

【讨论】:

  • 我确实需要一个 RDB。我也有一个已经使用 SQL 构建的复杂应用程序,我不想从 SQL 迁移。另外我认为您误读了我的策略,我不打算在任何时候调整 Baby 和 Papa 实例的大小。你是对的,Papa 的缓存会被清除,但如果能节省我的钱,我可以承受暂时的性能下降。为什么你说冷启动时间会增加? Baby 实例始终运行,Papa 在完全启动之前不会收到查询。
  • 除非您的流量具有异常一致的速度,否则您可能会在“papa”实例启动之前超出“baby”实例的规模。然后,您可能会有 1-2 分钟的停机时间(或至少是褐变时间),因为 SQL 实例被提升/降级,然后需要通知对您的 App Engine 实例(需要数据库访问权限)的请求更改并重新建立与新主节点的连接,然后才能执行写入命令。
  • 您确定上述需要 1-2 分钟的停机时间吗?如果是这样,您是否建议只使用一个在必要时调整大小的实例?调整大小也会产生 1-2 分钟的停机时间吗?
  • 您需要 1. 启动 L 实例,2. 将 L 实例设置为副本。 3. 等待复制赶上 4. 将 L 实例提升为主实例。实例停机的时间越长,它赶上复制滞后所需的时间就越长。确切的促销时间将取决于所有这些需要多长时间。要调整大小,您必须关闭实例、调整大小、重新启动它。它所花费的确切时间可能因实例的大小而异。
猜你喜欢
  • 1970-01-01
  • 2015-09-19
  • 2011-06-20
  • 2021-12-16
  • 2018-02-19
  • 2021-05-14
  • 1970-01-01
  • 2021-05-22
  • 1970-01-01
相关资源
最近更新 更多