App Engine：在哪里存储 html - 数据存储或云存储答案

【问题标题】：App Engine: Where to store html - datastore or cloud storageApp Engine：在哪里存储 html - 数据存储或云存储
【发布时间】：2014-04-28 01:54:54
【问题描述】：

我会自动创建一个 html 页面，用唯一标识符存储它，而不是在有人访问 http://www.example.com/view/unique_identifier 时显示它。

我应该在哪里存储 html 页面、数据存储或云存储？如果是数据存储，那么唯一标识符就是关键，我只需获取并提供 html。如果是云存储，文件是用唯一标识符命名的，我只是提供它。

什么更快？从长远来看，这两种方法的优缺点是什么？

我在 App Engine 上使用 PHP。

【问题讨论】：

标签： php google-app-engine google-cloud-datastore google-cloud-storage

【解决方案1】：

始终使用云存储 - 这里有两种情况适合您。

如果您想在提供 html 文件之前对其实施某种类型的访问控制。

将其放入云存储并使用 CloudStorageTools::serve() 提供文件，检查用户是否有权访问。

这允许您在云存储中拥有任何大小的 html 文件 - 它还使您的应用程序更高效，因为这些文件不是由您的实例提供服务，而是购买应用程序引擎基础架构。你的 PHP 脚本看起来像

<?php

use google\appengine\api\cloud_storage\CloudStorageTools;
CloudStorageTools::serve('gs://my_bucket/unique_identifier.html');

这些页面是公开的 - 您只想为它们提供服务。

将页面放入 Google Cloud Storage，然后从应用返回 301 或 302 重定向到页面 - Cloud Storage 将放入正确的缓存标头，以便用户在边缘缓存等中更快地获取页面。

你的 php 脚本可能看起来像

<?php

use google\appengine\api\cloud_storage\CloudStorageTools;
header('Location: ' . CloudStorageTools::getPublicUrl('gs://my_bucket/unique_identifier.html'));

注意：如果您不希望用户必须发出 2 次请求才能获取该页面，您仍然可以对公共页面执行 (1)。

【讨论】：

也许并不总是使用云存储。因为（来自文档）：您只能将 CNAME 重定向与 HTTP 一起使用，而不能与 HTTPS 一起使用！这个不起作用：h ttps://www.example.com/view/unique_identifier。
在这种情况下，您使用 CloudStorageTools::serve 就像我在答案中所说的那样。
我接受了这个答案并使用了云存储，因为 html 永远不会改变，我喜欢它减轻我的实例的负担。使用 memcache 来加速是否有意义？
我不确定你为什么认为你需要 memcache - 除非它是将唯一标识符映射到文件名。
我认为您也可以从您的实例中提供它。如果您设置了适当的缓存指令（无论如何您都必须在云存储上执行），则内容由 appengine 前端服务器缓存，因此它不会经常访问您的实例。 GCS 有其自身的问题（即碎片化/可移植性和可靠性）

【解决方案2】：

出于以下原因，使用 Datastore 将 HTML 页面保留为数据内容：

HTML 文档大多足够小，不需要 Cloud Storage (
页面 URL 将是您在应用程序域名中命名它们的名称
应用程序可以
- 使用 Memcache 加快检索速度
- 可选择将 HTML 页面作为模板处理
- 应用更细粒度、上下文相关的访问控制
- 执行动态可变重定向
- 让有权限的用户在应用程序中编辑 HTML

【讨论】：

【解决方案3】：

云存储要便宜得多。这是您的用例的唯一实质性区别。

【讨论】：

我认为这取决于使用情况。数据存储区的价格/请求较小。
云存储中“按请求”不收费（标准选项）。
当然是。 :) 目前每个操作的费用为 0.10 美元或 0.01 美元，具体取决于其类别）。
你能提供一个链接吗？
1.这些用于 JSON/XML API 调用，而不是用户浏览器加载资源时的用户请求。 2. 这些是每 10,000 个操作，而不是每个操作。在 Datastore 中，用户无法直接加载资源，因此每次调用都必须通过您的实例并计入计费。

【解决方案4】：

像往常一样，这取决于您的用例。

这些 HTML 文件有多大？
您打算更改这些文件吗？
您需要访问控制吗？
您是否需要重复使用来自其他应用的这些数据？

不要给您的应用增加不必要的复杂性，因为这个框架或这个服务提供了您实际上并不需要的功能。

如果您需要的很简单，请使用@Martin Berends 的答案。

【讨论】：