基于AWS无服务器架构的求职门户DynamoDB单表设计及搜索咨询

一、单表DynamoDB建模思路 #

1. 核心主键设计 #

采用**复合主键（PK/SK）**统一管理所有实体，格式规则如下：

• PK：[实体类型]#[唯一ID]，例如USER#u_123（求职者/雇主）、JOB#j_456（职位）、APPLICATION#a_789（申请）
• SK：根据实体关联关系定义，比如职位的SK设为COMPANY#c_001（关联雇主ID），申请的SK设为JOB#j_456#USER#u_123（关联职位与求职者）

2. 适配雇主访问模式 #

雇主需求：查询本公司发布的所有职位

• 给职位实体新增属性company_id（对应雇主的USER ID）
• 创建全局二级索引GSI1：
  • 分区键（GSI1PK）：COMPANY#[company_id]
  • 排序键（GSI1SK）：POSTED_AT（职位发布时间戳）
• 查询方式：直接查询GSI1，指定GSI1PK为目标雇主ID，即可按发布时间快速获取所有本公司职位，延迟低、效率高

3. 适配求职者搜索需求 #

求职者核心搜索：硬技能+雇佣类型+经验级别+目标地点的精准匹配
针对DynamoDB不支持灵活多条件过滤的特性，采用多维度组合GSI解决：

• 给职位实体新增属性：skills（数组格式，例如["Python", "Java"]）、employment_type（如FULL_TIME）、experience_level（如MID）、location（如SHANGHAI）
• 创建全局二级索引GSI2：
  • 分区键（GSI2PK）：SKILL#[skill_name]（为每个技能单独生成索引条目，一个职位有N个技能则生成N条GSI2记录）
  • 排序键（GSI2SK）：EMP_TYPE#[employment_type]#EXP#[experience_level]#LOC#[location]
• 查询方式：求职者搜索「Python+全职+中级+上海」时，直接查询GSI2的GSI2PK=SKILL#Python、GSI2SK=EMP_TYPE#FULL_TIME#EXP#MID#LOC#SHANGHAI，即可精准匹配所有符合条件的职位

4. 其他实体的单表存储 #

• 用户（求职者/雇主）：PK=USER#u_123，SK=PROFILE，存储用户名、角色、联系方式等基础信息
• 申请：PK=APPLICATION#a_789，SK=JOB#j_456#USER#u_123，存储申请状态、提交时间；可额外创建GSI3（PK=USER#u_123，SK=APPLIED_AT），方便求职者查询个人所有申请记录

二、搜索方案选型：DynamoDB vs 托管搜索服务（OpenSearch/CloudSearch） #

1. 优先用DynamoDB的场景 #

• 求职者仅需精准的预定义组合查询（无模糊匹配、多技能OR等需求）
• 团队希望简化架构，减少额外服务的运维成本
• 数据规模较小，过滤表达式的性能损耗可接受

2. 优先用OpenSearch/CloudSearch的场景 #

• 需要模糊搜索（如匹配「Python开发」与「Python工程师」）、多技能OR查询（如会Python或Java均可）
• 需要全文搜索（如搜索职位描述关键词）、智能排序（按匹配度、发布时间、薪资等综合排序）
• 数据规模大，DynamoDB过滤表达式的效率无法满足查询延迟要求

3. 平滑过渡方案 #

若初期用DynamoDB满足基础需求，后期可通过DynamoDB Streams + Lambda将职位数据实时同步到OpenSearch/CloudSearch，逐步升级搜索能力，无需重构现有单表架构

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