基于DynamoDB的阿拉伯语词典数据库设计方案优化咨询

一、现有单表设计的合理性与优化方向 #

你的现有单表设计核心思路符合DynamoDB单表模式的最佳实践，通过GSI覆盖三类查询需求的逻辑是可行的，但确实存在主键利用率极低的问题。可以通过调整主键设计，用业务语义化的复合主键替代自动生成的wordID，既保留单表优势，又减少对GSI的依赖：

优化后的主键设计 #

• 词根条目：
  • PK = ROOT#<词根内容>（例：ROOT#كتب）
  • SK = ENTRY#<序号>（例：ENTRY#1，用于区分同一词根的多条变体条目）
  • 属性：word（词根显示文本）、definition（释义）、isRoot = true
• 名词条目：
  • PK = NOUN#<词汇内容>（例：NOUN#كتاب）
  • SK = ROOT#<对应词根>（例：ROOT#كتب，直接关联所属词根）
  • 属性：definition（释义）、isRoot = false

三类查询的实现方式 #

1. 查询指定词根的所有词根条目：直接对主表执行Query操作，指定PK为ROOT#<目标词根>，无需依赖GSI，性能更优。
2. 查询指定词汇的所有名词条目：直接对主表执行Query操作，指定PK为NOUN#<目标词汇>，无需依赖GSI。
3. 查询指定词根的所有名词条目：仅需创建1个GSI，配置为：
   • GSI分区键：root（存储词根内容）
   • GSI排序键：word（存储名词词汇）
     执行Query操作该GSI的分区键为目标词根，即可获取所有关联名词条目。

这种设计将主键与业务查询需求绑定，减少了GSI的数量（从2个减至1个），降低了维护成本与额外开销。

二、是否需要更换AWS数据库？ #

你的数据库规模极小（总计约26k条记录），读多写少的场景完全适配DynamoDB的特性：

• 即使依赖GSI，26k级别的数据量也不会产生性能瓶颈，GSI查询延迟极低；
• 无服务器架构无需运维，自动适配读请求量，小流量下成本几乎可以忽略；
• 偶尔的错误修正写入操作，不会对系统性能造成任何影响。

如果更偏好关系型数据库的直观查询逻辑，也可以选择AWS RDS PostgreSQL：

• 可通过创建root和word字段的索引快速满足三类查询；
• 数据量小，存储与计算成本同样极低，也可选用RDS Serverless实现无运维；
• 适合后续可能扩展的复杂查询需求。

但从架构简洁性与长期运维成本来看，优化后的DynamoDB方案是更优选择。

三、额外注意事项 #

• 阿拉伯语文本处理：确保DynamoDB字符集支持阿拉伯语，可在属性中存储标准化后的词汇/词根，避免拼写、变体导致的查询遗漏；
• 条目区分：同一词汇/词根的多条变体条目，需通过SK或额外variant属性明确区分，避免数据混淆；
• 成本控制：DynamoDB的GSI会产生少量额外存储与请求费用，但26k数据量下可忽略不计。

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