AWS新手DynamoDB设计咨询：金融科技应用数据库适配问题

我是计算机科学本科生，已修读数据库课程，现基于AWS Plaid演示应用构建金融科技应用，需修改数据库适配需求，现咨询以下最佳实践问题：

1. 演示应用采用单表存储不同Schema、不同PK/SK的数据，此模式在生产环境是否可行？是否需拆分多表？
2. 需添加面向所有用户的信用卡信息真值表，是否可放入同一张DynamoDB表？如何实现便捷编辑及全用户查询？
3. 核心查询为交易数据，需支持按交易名、商户名、卡片类型、日期、类别检索，且需快速按卡片、类别排序并筛选日期范围，是否需创建不同索引？

附当前表的template.yml配置：

Table:
  Type: "AWS::DynamoDB::GlobalTable"
  UpdateReplacePolicy: Delete
  DeletionPolicy: Delete
  Properties:
    AttributeDefinitions:
      - AttributeName: pk
        AttributeType: S
      - AttributeName: sk
        AttributeType: S
      - AttributeName: gsi1pk
        AttributeType: S
      - AttributeName: gsi1sk
        AttributeType: S
    BillingMode: PAY_PER_REQUEST
    GlobalSecondaryIndexes:
      - IndexName: GSI1
        KeySchema:
          - AttributeName: gsi1pk
            KeyType: HASH
          - AttributeName: gsi1sk
            KeyType: RANGE
        Projection:
          ProjectionType: ALL
    KeySchema:
      - AttributeName: pk
        KeyType: HASH
      - AttributeName: sk
        KeyType: RANGE
    Replicas:
      - PointInTimeRecoverySpecification:
          PointInTimeRecoveryEnabled: true
        Region: !Ref "AWS::Region"
        TableClass: STANDARD
        Tags:
          - Key: GITHUB_ORG
            Value: !Ref GitHubOrg
          - Key: GITHUB_REPO
            Value: !Ref GitHubRepo
          - Key: Environment
            Value: !Ref Environment
    SSESpecification:
      SSEEnabled: true
    StreamSpecification:
      StreamViewType: NEW_AND_OLD_IMAGES
    TimeToLiveSpecification:
      AttributeName: expire_at
      Enabled: true

问题1：单表存储模式生产环境可行性及拆分建议 #

单表存储不同Schema、PK/SK的数据在生产环境完全可行，这是DynamoDB官方推荐的单表设计模式，核心是通过PK/SK的命名规范（如USER#123、TRANSACTION#456）区分不同实体类型。

是否需要拆分多表，取决于两个核心因素：

• 访问模式差异：如果某类数据读写量极高、且与其他实体的访问模式完全独立（比如独立的后台统计数据），拆分多表可避免资源竞争；
• 维护成本：如果团队对单表设计的理解不足，后续维护（比如新增实体、调整索引）的学习成本过高，可考虑拆分。

若非上述情况，优先保留单表设计——它能减少跨表事务开销，提升查询效率，更符合DynamoDB的分布式架构特性。

问题2：信用卡信息真值表的单表存储方案 #

可以放入同一张DynamoDB表，具体设计如下：

• 实体标识：用固定PK值（如CARD_TRUTH_TABLE）作为所有信用卡真值记录的HASH键，SK用CARD_TYPE#VISA或具体卡片ID（如CARD#1001）区分不同条目，确保每条记录可唯一定位；
• 便捷编辑：通过PK=CARD_TRUTH_TABLE + SK=具体卡片标识的精确查询，直接执行PutItem或UpdateItem操作，性能可达毫秒级；
• 全用户查询：利用现有GSI或新增GSI实现：
  • 若复用现有GSI，将gsi1pk设为固定值（如ALL_CARD_TRUTHS），gsi1sk设为卡片类型或名称（如VISA#经典卡）；
  • 查询时只需指定gsi1pk=ALL_CARD_TRUTHS，即可扫描所有信用卡真值记录，还能通过gsi1sk做范围筛选（如筛选所有VISA类型卡片）。

问题3：交易数据的索引设计方案 #

需要针对不同高频查询模式创建对应的GSI，核心是围绕查询的HASH+RANGE键组合优化：

• 按卡片类型+日期范围+类别排序/筛选：创建GSI，HASH键设为CARD_TYPE#XXX（如CARD_TYPE#VISA），RANGE键设为复合值DATE#YYYYMMDD#CATEGORY#XXX（如DATE#20240501#CATEGORY#餐饮）。这样可快速按卡片类型过滤，再通过RANGE键筛选日期范围并按类别排序；
• 按商户名+日期范围查询：若商户名查询频繁，创建GSI，HASH键设为MERCHANT#XXX（如MERCHANT#星巴克），RANGE键设为交易日期（如20240501），支持按商户快速筛选指定日期范围内的交易；
• 按类别+日期范围+交易名前缀检索：创建GSI，HASH键设为CATEGORY#XXX（如CATEGORY#餐饮），RANGE键设为DATE#YYYYMMDD#TRANSACTION_NAME#XXX（如DATE#20240501#TRANSACTION_NAME#星），通过BeginsWith操作实现交易名前缀匹配；
• 注意事项：每个GSI对应一类高频查询，避免过度创建索引增加存储和写入开销；若需全模糊查询交易名，可结合Elasticsearch，但优先用DynamoDB原生能力满足大部分场景。

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