我有一个非常简单的应用程序引擎应用程序，提供存储在 blobstore 中的 1.8Kb - 3.6Kb gzip 文件。从数字文件 ID 到 blobkey 的映射存储在数据存储中并缓存在内存缓存中。 servlet 实现很简单:在请求中接收到一个数字文件 ID；从内存缓存/数据存储中检索 blobkey，并调用标准 BlobstoreService.serve(blobKey, resp) 来提供响应。正如预期的那样，应用程序日志显示响应大小始终与提供的 blobstore 文件大小相匹配。
我一直在进行一些集中的容量测试，这表明传出带宽配额利用率一直报告为大约是我预期的给定收到请求的 2 倍。我一次运行 10 万个请求，对客户端收到的字节求和，将其与应用程序日志进行比较，除传出带宽配额利用率外，所有内容均保持平衡。
对于理解如何为我上面描述的简单应用程序确定传出带宽配额利用率有什么帮助吗？我缺少或没有考虑什么？为什么它不符合应用日志中显示的响应大小总数？
[更新 2013.03.04:我放弃了 blobstore 的使用，转而将 blob 直接存储在数据存储中。传出带宽利用率现在与预期完全一样。 2x 乘数似乎与 blobstore 的使用有某种关系(但仍然无法解释)。我在使用 blobstore 服务时遇到了其他几个问题；最有问题的是额外的数据存储读取和写入(这与数据存储中管理的 blobinfo 和 blobindex 元数据相关 - 这正是我最初试图通过将数据迁移到 blobstore 来减少的内容)。对我来说一个特别严重的问题是:https://code.google.com/p/googleappengine/issues/detail?id=6849 .我认为这是 blobstore 服务内存泄漏；创建 blob 后，您永远无法删除数据存储中的 blob 元数据。我将永远为此付出代价，因为我愚蠢到运行 24 小时容量和性能测试，现在无法释放测试期间使用的存储空间。看来 blobstore 目前只适用于非常特定的场景(即永久静态数据)。具有大量变动的对象或经常刷新或更改的数据不应存储在 blobstore 中。]
最佳答案
可以删除 blobstore 数据(我不推荐它，因为它会导致意外行为)，但前提是您知道它保存在 __BlobInfo__ 中的表。和 __BlobFileIndex__ .这样就完成了，因此您上传的文件没有相同的名称，并且不小心替换了旧文件。
要获得存储在数据存储中的表的完整列表，您可以运行 SELECT * FROM __kind__ .
我不确定为什么您的 App Engine 应用会消耗 2 倍的传出带宽，但我会亲自测试一下。
另一种方法是使用 Google Cloud Storage。如果您使用 default bucket for your app engine app, you get 5GB free storage
Objects with a great deal of churn or data that is frequently refreshed or altered should not be stored in the blobstore.
没错，您可以使用云存储或数据存储(云存储是一种不可变的对象存储服务)。 Blobstore 更适合通过 <input type='file' /> 上传文件形式。 (最近，从应用程序内部写入文件已被弃用，取而代之的是云存储)
关于google-app-engine - 传出带宽是总响应带宽的 2 倍，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14933517/