我正在使用Google云平台建立云服务，但我没有太多使用它的经验（尚未）
我的服务除其他外，还将存储具有名称，描述等属性的结构化实体。但是，我也希望每个实体都以某种方式与可能具有数十个甚至数百个图像的集合相关联图像。
查看存储选项GCP提供了我的数据的结构化性质，这表明我应该使用数据存储，而"非结构化"的图像应使用常规存储（可能存储在文件夹中以将图像从特定实体中保持在一起）。p>我的问题是a）这是我用例的合理方法吗？
如果是这样b）我如何将两件事链接在一起？
或如果不是b）存储这些的最佳方法是什么？
您的方法对我来说听起来还不错，我会以同样的方式做。
对于将数据存储的结构化实体链接到图像，Andrei Volgin建议的替代方法是具有多个映射权利 - 每个关联的图像，其中一个包含属性：
： 。- 数据存储结构化实体的键（或密钥ID）
- 图像的存储名称/位置
这种方法的优点（尤其是当与一个结构化实体相关的图像数量很高时）是：
no 1 Write/sec限制添加/删除同一结构化实体的图像
试图从多个同时请求获得图像位置时，对结构化实体本身没有争议
没有性能降解，随着与结构化实体相关的图像数量的增加（由于实体大小增加了序列化）；结构化实体的大小保持很小
缺点是您需要附加查询来获取有关与结构化实体相关的图像的信息。
这些映射实体可以包含其他结构化与图像相关的信息，如果最终需要。
您的数据存储实体可能具有包含图像文件名列表的属性。假设将每个图像放在代表实体ID/名称的"文件夹"中，则可以通过简单地调用（例如）显示图像：
"https://storage.googleapis.com/MY_BUCKET/" + entity.getId() + "/" + IMAGE_NAME;
在我的几个项目中，我需要存储有关每个图像的更多数据，例如它的顺序，方向和大小。在这种情况下，我创建一个实体来表示数据存储中的每个图像。在某些情况下，我使用嵌入式实体 - 例如，产品实体包含代表与此产品相关的图像的嵌入式实体列表。这种方法使我可以显示带有图像的产品列表，而无需额外查询以获取每种产品的图像。
我将使用两种不同的实体。前任。Album和Images并通过使用ancestor path像文件结构一样组织它们。然后，我可以轻松地添加Comment实体类型，作为Images的孩子。
2个实体[TaskList:default, Task:sampleTask]
$taskKey = $datastore->key('TaskList', 'default')
->pathElement('Task', 'sampleTask');
阅读有关祖先路径的更多信息