google-cloud-platform - 将大文件的小改动同步到 Cloud Storage

Question

我有一个计算引擎 VM，它经常对大文件进行小幅更改。

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

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

• 这会花费很多我的虚拟机 CPU，还是这个操作相对便宜，因为它只是通过网络发送字节？
• 我会为所有这些多余的流量付费吗？

标签： google-cloud-platformgoogle-cloud-storage

Answer 1

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

我唯一的选择是在每次小改动时不断上传完整的大文件吗？

如果您的目标是将这些更改镜像到 Google Cloud Storage，那么是的，您必须不断上传整个文件。Google Cloud Storage 对象是不可变的。这意味着您不能更改现有对象。您必须上传新对象以覆盖现有对象。您可以创建一个包含多个对象的策略，这些对象组合起来代表 SQLite 数据库，然后只更新那些已更改的对象。

这会花费很多我的虚拟机 CPU，还是这个操作相对便宜，因为它只是通过网络发送字节？

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

网络定价

云存储网络定价

我会为所有这些多余的流量付费吗？

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

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

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

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

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

在现实世界中，您应该考虑几种类型的场景：

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

如果数据库损坏或从数据库中删除了必要的数据，您的策略将失败。您只是盲目地覆盖没有备份历史记录的备份对象。您的策略需要包括“时间点”恢复，以便您可以从错误中恢复，例如由于错误或事故而删除表或一组行。根据我的经验，时间点还原比 RTO（频繁备份）更重要，有时比 RPO（您可以接受多少数据丢失）更重要。与计算机相比，人类犯的错误更多，也更频繁。