我正在使用Google Cloud Platform构建云服务,但我没有太多使用它的经验(还)
除其他外,我的服务将存储具有诸如名称,描述等属性的结构化实体。但是,我还希望每个实体以某种方式与可能具有数十甚至数百个的图像集合相关联。图像。
查看存储选项GCP提供的数据的结构化特性表明我应该使用数据存储,并且图像是非结构化的'应该使用常规存储(可能存储在文件夹中以保持特定实体的图像在一起)。
我的问题是a)对我的用例来说这是一种合理的方法吗?
如果是这样的话b)我如何将这两件事连在一起?
或者如果不是b)存储这些的最佳方法是什么?
答案 0 :(得分:2)
您的数据存储区实体可能具有包含图像文件名列表的属性。假设您将每个图像放在表示实体ID /名称的“文件夹”中,您只需调用(例如)即可显示图像:
"https://storage.googleapis.com/MY_BUCKET/" + entity.getId() + "/" + IMAGE_NAME;
在我的几个项目中,我需要存储关于每个图像的更多数据,例如:它的顺序,方向和大小。在这种情况下,我创建一个实体来表示数据存储区中的每个图像。在某些情况下,我使用嵌入式实体 - 例如,产品实体包含表示与此产品相关的图像的嵌入式实体列表。这种方法允许我显示带有图像的产品列表,而无需额外的查询来获取每个产品的图像。
答案 1 :(得分:2)
你的方法对我来说听起来不错,我也是这样做的。
至于将数据存储结构化实体链接到图像,Andrei Volgin建议的另一种更具可扩展性的方法是拥有多个映射权限 - 每个关联图像一个,包含属性:
这种方法的优点(特别是当与一个结构化实体相关的图像数量很高时)是:
在添加/删除同一结构化实体的图像时没有1次写入/秒限制
尝试从多个同时请求中获取图像位置时,对结构化实体本身没有争用
随着与结构化实体关联的图像数量的增加,性能不会降低(由于需要序列化的实体大小增加);结构化实体的规模仍然很小
缺点是您需要一个额外的查询来获取有关与结构化实体关联的图像的信息。
如果最终需要,这些映射实体可以包含其他结构化图像相关信息。
答案 2 :(得分:0)
我会使用两种不同的实体。恩。 Album
和Images
并使用ancestor path
类似文件结构来组织它们。然后,我可以轻松添加Comment
实体种类作为Images
的子项。
2个实体[TaskList:default, Task:sampleTask]
$taskKey = $datastore->key('TaskList', 'default')
->pathElement('Task', 'sampleTask');
详细了解Ancestor paths