如何在DynamoDB中存储带关键词的餐厅数据以支持关键词查询？

针对每条餐厅带50个关键词的存储与查询需求，这里给你几个实用的架构方案，对应不同的场景：

方案1：反规范化单表存储（高频精确查询首选） #

简单说就是给每个餐厅的每个关键词单独创建一条数据，利用DynamoDB的分区键特性实现秒级查询：

• 主键设置：
  • 分区键（Partition Key）：keyword（存具体的关键词，比如"川菜"、"网红打卡"）
  • 排序键（Sort Key）：restaurant_id（餐厅的唯一ID）
• 数据内容：每条条目里可以直接存餐厅的完整信息（名称、地址、评分这些），也可以只存餐厅ID+关键属性——如果想省空间，就用餐厅ID回查主表，但会多一次查询操作
• 查询方式：要查某关键词对应的餐厅，直接用Query操作，指定keyword = "你要查的关键词"，就能立刻拿到所有匹配的餐厅
• 利弊：
  • 优点：查询速度极快，完全不会触发全表扫描；不用额外建索引，成本可控
  • 缺点：数据会有冗余（一个餐厅对应50条数据）；新增或删除餐厅时，得批量操作50条条目，记得用DynamoDB事务保证数据一致

方案2：主表+全局二级索引（GSI） #

适合既要保留餐厅主数据完整性，又要支持关键词查询的场景：

• 主表设置：
  • 分区键：restaurant_id
  • 字段：存餐厅的所有信息，再加一个keywords数组（放50个关键词）
• GSI设置：
  • GSI的分区键：keyword
  • GSI的排序键：restaurant_id
  • 投影属性：可以选择只投影餐厅的核心信息（比如名称、评分），或者全部属性
• 数据同步：可以用DynamoDB Streams搭配Lambda，主表新增/更新餐厅时，自动把每个关键词拆出来写入GSI；也可以在写主表的时候手动批量写GSI条目
• 查询方式：通过GSI的Query操作，指定keyword = "目标关键词"就能拿到匹配的餐厅
• 利弊：
  • 优点：主表数据没有冗余，维护起来方便；GSI的查询效率和方案1差不多
  • 缺点：要额外维护GSI，会增加存储成本；用Streams+Lambda的话，会多一层复杂度

方案3：按关键词类型分组的复合主键（适合有分类的关键词） #

如果你的关键词能明确分成不同类别（比如"菜系"、"商圈"、"口味"），可以用复合主键做更灵活的分类查询：

• 主键设置：
  • 分区键：keyword_type（比如"cuisine"、"area"）
  • 排序键：keyword_value#restaurant_id（比如"川菜#1001"）
• 数据内容：存餐厅的核心信息
• 查询方式：
  • 查某类下的特定关键词：用Query指定keyword_type = "cuisine"，再加begins_with(sort_key, "川菜")
  • 查所有含某关键词的餐厅：可以额外建个GSI，把keyword_value作为分区键
• 利弊：
  • 优点：支持按关键词分类查询，逻辑清晰；适合关键词有明确分类的场景
  • 缺点：关键词没分类的话用不了；查跨类型的关键词得多次执行Query

模糊查询的补充方案 #

如果需要支持模糊匹配（比如输入"川"就能找到"川菜"、"川味"的餐厅），DynamoDB本身不支持原生模糊查询，可以这么搞：

• 预生成关键词的前缀/后缀变体，比如"川菜"可以生成"川"、"川菜"、"菜"作为额外的关键词条目，但会增加数据量
• 搭配Elasticsearch：把餐厅的关键词同步到Elasticsearch，用它做全文检索，DynamoDB只存主数据

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