以下是我们的简单用例：user2希望将user1的文档复制到我们应用程序中的自己的存储库中。应该简单吧？我们需要做的就是在blobstore中创建第二个相同的blob，并返回我们可以与user2关联的密钥。我们必须在这里遗漏一些东西。似乎app引擎blob存储的主要功能是处理从浏览器上传和下载到浏览器的blob，并且启动服务器端的简单复制操作并不那么简单。
显而易见的解决方案似乎是在java中使用实验文件api，但没有爱。它起作用，直到你的文件大小超过MB左右，然后它失败，有些不可预测。当我们只需要在存储层中制作副本时，将它全部读入服务器层也似乎很愚蠢。此外，我们将实验性功能纳入生产环境的可能性很小，尽管非零。
有关我们环境的一些信息：应用程序是用Java编写的，我们使用的是blobstore，而不是云存储，现在就致力于它。我们是一个小型的部门团队，并希望说明应用引擎是一个很好的平台，但这个让我们感到难过。 S3让这简单明了，我们错过了一些真正愚蠢的东西吗？
答案 0 :(得分：1)
我们最终废弃了使用文件api制作blob的编程副本并使用Kalle在其评论中建议的参考文件的想法，并创建了一个新的外部参照实体，用于存储有关副本和原始文件的信息。当删除图像或文件时，我们检查xfef实体是否有参考，并删除指向该图像/文件的那些（即，如果删除的图像/文件是从另一个复制的，则创建）。如果我们根本找不到任何外部参照，我们会删除blob本身。我们不喜欢留下孤立的blob的隐私/合规性影响，即使每个$$$有助于存储便宜。我们也喜欢保持干净房子的想法。
答案 1 :(得分：0)
解决方案1 ：我将启动Google Compute Engine实例并使用命令gsutil进行复制。
然后在完成后关闭实例。这是根据我的知识进行复制的最快方法
解决方案2 ：但我个人会选择使用评论中所说的计数器，因为你所说的可怕点与副本相同。 因此，只需使用具有强大单元测试的计数器，例如那些不那么可怕的计数器。
让它不那么可怕的一个想法是，当你的计数器达到0时，你不会立即删除blob但是稍后会做一个工作。在Google App Engine中使用Scheduled task。例如，一个月后删除文件及其实际记录。
答案 2 :(得分：0)
正如评论中已经提到的，保留一个blob并传递密钥。但你真的永远不需要删除。保留blob以进行存档是一种很好的做法。那么delete将如何实际运作？在数据存储区模型中，有一个布尔删除字段。删除后，您不会从实体中删除blob密钥。但是，您将布尔字段标记为true。这样，您的产品就拥有了拥有文件的每个用户的记录。但是用户不需要知道。