Google Cloud Datastore：订单存储选数组属性还是子实体？

嘿，我来帮你拆解这两种Google Cloud Datastore的订单存储方案，结合Datastore的特性帮你捋清楚各自的优劣势，方便你做选择：

方案一：产品列表作为订单实体的数组属性存储 #

优点 #

• 读取效率拉满：一次get操作就能拿到订单+所有产品的完整数据，不用做多实体查询或者祖先查询，延迟极低，特别适合需要一次性展示完整订单详情的场景（比如用户查看自己的订单页）。
• 事务处理简单：如果要修改订单本身（比如订单状态）和产品列表（比如调整某个产品数量），只需要在一个单实体事务里更新就行，Datastore的单实体事务是最直接高效的，完全不用处理跨实体事务的复杂度。
• 成本更友好：Datastore是按实体读取次数计费的，这种方式只算1次实体读取，比多次读取子实体省钱不少，尤其是订单量很大的时候。

缺点 #

• 实体大小受限：Datastore单个实体的大小上限是1MB，如果你的订单里产品数量特别多，或者每个产品的属性很复杂（比如带长描述、高清图片URL），很容易触发这个限制，导致订单存不进去。
• 产品独立操作麻烦：如果要单独更新某个产品的信息（比如改数量、换规格），必须把整个订单实体取出来，修改数组里的对应项，再完整存回去；而且多个请求同时修改同一个订单时，并发冲突概率很高，得额外处理重试逻辑。
• 查询灵活性差：没法直接针对产品属性做查询（比如“找出所有包含产品X的订单”），因为产品数据是嵌套在订单实体里的，只能先把所有订单读出来再过滤，数据量大的时候性能会崩。

方案二：为每个订单创建产品子实体（使用祖先关系） #

优点 #

• 无存储上限顾虑：每个产品都是独立的实体，不管订单有几百上千个产品都能存，完全不用担心1MB的实体大小限制。
• 产品操作更灵活：可以单独更新、删除某个产品实体，不用动整个订单；并发修改不同产品时几乎不会有冲突，处理起来更省心。
• 查询能力更强：既能通过祖先查询快速拿到某个订单下的所有产品，也能直接针对产品属性做跨订单的复杂查询（比如“统计所有订单里产品X的总销量”），Datastore支持为子实体的属性建索引，查询效率很高。
• 扩展性更好：如果以后产品需要新增属性（比如关联库存、物流信息），或者要和其他实体做关联，子实体的结构更容易调整，不会影响订单实体的核心结构。

缺点 #

• 读取成本和延迟更高：要获取完整订单详情，得先读订单实体，再做一次祖先查询读取所有产品实体，多了一次查询操作，延迟会高一点；而且计费时是按读取的实体数量算的，订单产品越多，成本越高。
• 事务有数量限制：如果要同时修改订单和多个产品，需要用跨实体的祖先事务，但Datastore的单个事务最多只能处理25个实体的写操作。如果你的订单需要一次修改超过25个产品，就没法在一个事务里完成，得拆分处理，复杂度会上升。
• 索引维护成本增加：每个产品实体的查询属性都需要建索引，会额外占用一点存储资源，而且写入产品实体时，索引更新也会增加一点耗时。

选择建议 #

• 如果你的订单产品数量不多（比如几十以内），大部分场景是读取完整订单，且很少单独操作产品，选方案一更合适，简单高效又省钱。
• 如果订单产品数量可能很多，需要单独操作产品，或者要基于产品属性做复杂查询，那方案二是更靠谱的选择，灵活性和扩展性都更强。

内容的提问来源于stack exchange，提问作者Richie