5

这是我们的简单用例：user2 想要将 user1 的文档复制到我们应用程序中他或她自己的存储库中。应该很简单吧？我们需要做的就是在 blobstore 中创建第二个相同的 blob，返回的密钥可以与 user2 关联。我们一定在这里遗漏了一些东西。看来应用引擎blob store的主要功能是处理从浏览器上传和下载的blob，而服务器端发起的简单复制操作并不是那么简单。

显而易见的解决方案似乎是使用java中的实验文件api，但没有爱。它可以工作，直到您的文件大小超过 MB 左右，然后它才会失败，这有点出人意料。当我们只需要在存储层中进行复制时，将它们全部读入服务器层似乎也很愚蠢。此外，我们在生产环境中获得实验性功能的可能性很小，尽管不为零。

关于我们环境的一些信息：该应用程序是用 Java 编写的，我们使用的是 blobstore，而不是云存储，并且目前正在使用它。我们是一个小型部门团队，希望证明应用引擎是一个很好的平台，但这个让我们很难过。S3 使这变得非常简单，我们在这里错过了一些非常愚蠢的东西吗？

4

3 回答 3

1

我们最终放弃了使用文件 api 制作 blob 的编程副本并使用 Kalle 在他的评论中建议的引用的想法，并创建了一个新的外部参照实体来存储有关副本和原始信息的信息。当一个图像或文件被删除时，我们检查 xfef 实体的引用并删除指向该图像/文件的那些（即，如果删除的图像/文件是从另一个复制的，则创建）。如果我们根本找不到任何外部参照，我们会删除 blob 本身。我们不喜欢留下孤立的 blob 所带来的隐私/合规性影响，即使存储很便宜，但每 $$$ 都有帮助。可以这么说，我们也喜欢保持一个干净的房子的想法。

于 2013-04-30T13:00:38.087 回答
0

解决方案 1：我将启动一个 Google Compute Engine 实例并使用命令 gsutil 进行复制。

然后在完成后关闭实例。据我所知，这是最快的复制方式

gsutil 文档

解决方案2：但我个人会选择使用评论中所说的计数器，因为你说的可怕之处与副本相同。因此，只需对那些不那么可怕的人使用具有强大单元测试的计数器。

一个让它不那么可怕的想法是，当您的计数器达到 0 时，您不会立即删除 blob，而是稍后再执行此操作。通过使用Google App Engine 中的计划任务。例如，一个月后删除该文件和您的实际记录。

于 2013-04-28T15:35:44.033 回答
0

正如评论中已经提到的，保留一个 blob 并传递密钥。但你真的永远不需要删除。为存档目的保留 blob 是一种很好的做法。那么delete实际上如何工作呢？在您的数据存储模型中，有一个布尔删除字段。您不会在删除时从实体中删除 blob 键。而是，您将布尔字段标记为true. 这样，您的产品就会记录拥有文件的每个用户。但用户不需要知道。

于 2013-04-28T16:18:10.540 回答