GeminiDB Serverless的实时抢购系统应用

主表是支撑高并发写入的核心结构。在GeminiDB中，科学设计分区键（Partition Key）能够确保数据在多个存储节点上实现均衡分布。

除了主键之外，其他列（或属性）无需在建表时预先定义。此处列出的其他字段，旨在帮助理解索引的构建方式和设计逻辑。

• 主键选择策略：我们选用order_id作为主键（Partition Key）。由于订单号是随机生成的，能够将写入压力均匀分布在整个集群的各个分区中，有效避免了类似按日期分区可能导致的热点问题或节点负载不均的情况。
• Schema-less的灵活性：得益于GeminiDB的非结构化特性，如果我们未来需要新增字段，例如优惠券ID或配送备注，可以直接写入数据，无需执行耗时且成本较高的ALTER TABLE操作，极大地提升了系统对业务变更的响应能力。

为了支持多维度的业务查询，我们设计并实现了全局二级索引。该索引本质上是主表的一个副本，但采用了不同的键结构，从而提升了查询的灵活性和效率。

• 用户索引

  该索引主要用于满足用户的订单查询需求，提升查询效率与体验。

  索引组件	字段名称	业务意义
  Partition Key	user_id	将同一用户的所有订单聚合同一分区，便于快速定位。
  Sort Key	create_time	按订单创建时间排序，支持“从最近到最早”的浏览顺序。
  投影字段	order_id, promo_id, status	仅保留关键信息，实现存储与查询效率的平衡。

  典型使用场景：

  • 用户在App中查看自己的历史订单。
  • 快速判断用户是否曾参与过某个促销活动。
• 活动索引
  该索引专为运营端或监控端设计，便于高效管理与追踪活动数据。通过合理设置分区与排序键，帮助您快速定位和分析关键信息。

  索引组件	字段名称	业务意义
  Partition Key	promo_id	按活动ID对数据进行分区，便于将同一活动的数据聚合，提升查询效率。
  Sort Key	create_time	按订单创建时间排序，方便实时查看最新的成交记录，掌握活动实时动态。
  投影字段	order_id, user_id, amount	提供核心字段的投影，用于实时统计订单量、用户参与情况及交易金额等关键指标。

  典型使用场景：

  • 运营后台：实时刷新订单数据，及时掌握活动效果。
  • 活动大屏：展示最新前N条成功下单的用户动态，增强现场或线上活动的互动性与吸引力。

在促销活动中，写入操作不仅仅是数据的存储，更重要的是保证数据的一致性与可靠性。在网络波动或用户频繁点击的情况下，前端可能会发送重复请求。借助GeminiDB的条件表达式，我们可以实现一种轻量级的事务保护机制，有效避免重复操作，保障系统稳定运行。

 response = table.put_item(
     Item={
         'order_id': 'ORD_20250101_001',
         'user_id': 'U12345',
         'status': 0,
         'create_time': 1735689600
     },
     ConditionExpression="attribute_not_exists(order_id)"
 )

当支付等回调发生时，我们需要更新订单状态。通过条件更新，可以确保状态流转的准确性和合理性，避免因并发或重复请求导致的数据不一致问题。

table.update_item(
     Key={'order_id': 'ORD_20250101_001'},
     UpdateExpression="SET #s = :new_status",
     ConditionExpression="#s = :old_status",
     ExpressionAttributeNames={'#s': 'status'},
     ExpressionAttributeValues={
         ':new_status': 1,
         ':old_status': 0
     }
 )