将较小的更改同步到大文件到Cloud Storage

问题描述 投票:0回答:1

我有一个计算引擎VM,它经常对大文件进行细微更改。

我想尽可能经常地将这些写入同步到GCS。

我的唯一选择是在每次小更改时不断上传完整的大文件吗?这意味着每次上传时,我的VM和GCS之间可能会发送99%不变的字节。

  • 这会花费我很多VM的CPU,还是该操作相对便宜,因为它只是通过网络发送字节?
  • 我是否要为所有这些多余的流量付费?
google-cloud-platform google-cloud-storage
1个回答
0
投票

您的问题没有简单的答案。最佳答案取决于对超出您实际问题之外的许多因素的仔细审查。

这是我不断上传完整的大文件的唯一选择每个零钱?

[如果您的目标是将这些更改反映到Google Cloud Storage,那么是的,您必须不断上传整个文件。 Google云端存储对象是不可变的。这意味着您不能更改现有对象。您必须上载新对象以覆盖现有对象。您可以创建多个对象的策略,这些对象组合起来代表SQLite数据库,然后仅更新那些已更改的对象。

这会花费我很多VM的CPU,还是该操作会相对便宜,因为它只是通过网络发送字节?

您的问题含糊。 “花费很多”是什么意思。您需要支付从Google Compute Engine到Cloud Storage的网络出口流量。多少取决于Cloud Storage的类型,Compute Engine实例和Cloud Storage存储桶的位置以及所使用的寻址类型(公共/专用IP网络)。一些组合是免费的。查看以下链接以确定您的价格。

Network Pricing

Cloud Storage Network Pricing

我是否要为所有这些多余的流量付费?

是。 Google Cloud不会分析您的出口数据来确定数据重复。

您需要检查将文件不断复制到Cloud Storage的策略。要考虑三个主要因素。我将在稍后的答复中提及第四点。

  1. RPO-恢复点目标
  2. RTO-恢复时间目标
  3. 实施成本

#1和#2的值越小,则成本越高。您需要确定对于给定的RPO和RTO合理的成本。

个人而言,我不会将Cloud Storage用作近乎实时的复制系统。如果成本是我的主要考虑因素,我将向Compute Engine实例添加另一个磁盘。然后定期冻结SQLite数据库,并在第二张磁盘上创建带有时间戳的副本。然后,以较慢的时间间隔将复制的副本(带时间戳的对象名称)复制到Cloud Storage。每个操作的执行频率取决于上面的三个项目符号。

在现实世界中,您应该考虑几种类型的方案:

  1. 数据丢失
  2. 数据损坏

如果数据库已损坏或从数据库中删除了必要的数据,您的策略将失败。您只是盲目地覆盖没有备份历史记录的备份对象。您的策略需要包括“时间点”还原,以便您可以从由于错误或意外而删除表或一组行的错误中恢复。以我的经验,即时点还原比RTO(频繁备份)更为重要,有时甚至比RPO更重要(您可以接受多少数据丢失)。人类比计算机犯更多的错误,而且犯错误的频率更高。

热门问题
推荐问题
最新问题