DynamoDB控制台分页与过滤机制及自定义服务实现问询

1. 这14条记录存储在哪里？ #

• 这14条剩余记录通常存储在客户端内存中，比如浏览器的运行时变量、前端框架的状态容器（如React的useState、Vue的data，或者Redux、Pinia这类状态管理工具）。如果是服务端主导的分页机制，也有可能暂存在服务端的临时缓存（如内存缓存、Redis）里，但前端暂存是更普遍的实现方式——目的是在用户触发“下一页”操作时快速读取，避免重复调用API扫描数据。

2. 在自有服务中实现该机制是否可行？如何实现仅展示25条的效果？ #

• 完全可行。要实现仅展示25条的效果，可以从客户端或服务端两个方向改造：

  客户端侧实现方案 #

  • 在发起API调用时，维护一个累计计数器和暂存列表：
    1. 每次调用API获取扫描结果后，过滤出匹配status的记录，将其加入暂存列表。
    2. 检查暂存列表的长度：如果达到或超过25条，就取出前25条展示，剩下的14条留在暂存列表中，同时停止后续API调用。
    3. 用户点击“下一页”时，先展示暂存的14条，再继续调用API，补充剩余需要的记录（比如还需要11条），重复上述累计、过滤、暂存的逻辑。

  服务端侧实现方案 #

  • 服务端需要为每个分页请求维护会话状态：
    1. 接收客户端的分页请求后，循环调用底层存储扫描数据，过滤匹配status的记录，累计到25条为止。
    2. 将超出的14条记录暂存在服务端缓存（如Redis、内存缓存）中，同时记录当前的last evaluated key和会话标识，返回前25条给客户端。
    3. 客户端请求下一页时，服务端先取出缓存中的14条返回，再用之前的last evaluated key继续扫描底层存储，补充足够的记录（比如11条），更新缓存和last evaluated key。
  • 注意：无论哪种方案，都需要准确跟踪已收集的匹配记录数、当前的last evaluated key以及暂存的剩余记录，避免数据重复或遗漏。

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