面向约会应用的Google Cloud Datastore关联数据结构最佳设计咨询

实体结构设计选择 #

不需要完全照搬SQL的四类表结构，也不建议全量嵌套，根据不同数据的查询场景区分设计即可：

• users 独立实体：必选，以用户唯一id作为主键，存储昵称、年龄、简介、注册时间等用户基础单值属性即可。
• photos 可选独立/嵌套：
  如果单个用户的照片数量上限不超过50张，且所有照片查询都伴随用户信息一起获取，直接嵌套在users实体的photos数组字段即可，单个数组元素结构示例：{"url":"xxx", "is_avatar": true, "sort_order": 1}
  如果有照片单独审核、单独统计等跨用户的照片查询需求，就做独立实体，使用父键关联对应用户：Key(users, [用户id], photos, [照片id])，查询单个用户的所有照片直接按父键过滤即可，效率远高于SQL外键关联查询。
• swipes 必选独立实体：绝对不能嵌套在users实体中，用户滑动记录量级可达数万条，嵌套会导致users实体体积过大，查询效率指数级下降。
  独立swipes实体主键使用{swiper_id}_{swiped_id}的组合id，避免重复写入，属性存储swiper_key（指向滑动发起者的users实体Key）、swiped_key（指向被滑动者的users实体Key）、is_like（是否右滑）、create_time即可，查询A是否滑过B直接用组合主键查询即可，毫秒级返回。
• matches 优先独立实体：不推荐嵌套在users实体中，嵌套需要额外处理双向同步的事务逻辑，很容易出现匹配记录只更新了一方的一致性问题。
  独立matches实体主键使用{较小的用户id}_{较大的用户id}的规范组合id，属性存储user_keys（两个用户的实体Key数组）、match_time、last_interact_time等，查询单个用户的所有匹配记录只要加复合索引过滤user_keys包含当前用户Key的条目即可，无需双向同步。

类SQL外键的关联逻辑处理 #

Datastore没有原生外键约束，关联逻辑全部在业务侧实现即可：

• 关联字段统一使用Key类型存储，而非纯字符串id，可直接通过Key读取对应实体，无需手动拼接实体路径
• 级联操作自行实现：比如删除用户时，业务代码要同步删除关联的swipes、matches、photos实体，Datastore不会自动触发级联删除
• 避免需要Join的查询设计：Datastore不支持多实体联合查询，设计时尽量保证单次查询就能拿到业务所需的全量数据，嵌套小量级关联属性就是为了避免多次查询

嵌套存储的适用边界 #

仅在同时满足以下两个条件时选择嵌套：

1. 子实体和父实体是1对少的关系，单父实体对应的子实体数量不超过100条
2. 所有子实体的查询场景都伴随父实体查询，没有跨父实体的子实体查询、排序、过滤需求

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