使用AWS DynamoDB和PHP进行分页

Question

有人知道如何对表中的记录进行分页吗?实际上，我想创建一个paginate组件在php与DynamoDb。

似乎不可能给出<first>& # 60; prev # 62;1、2、3, 4 , 5…& # 60;下# 62;& # 60;这# 62;。

因为Dyanmodb只是提供了我们可以读取某些no的LIMIT子句。我们可以通过LastEvaluatedKey处理接下来的n条记录。所以如果我想直接跳到第五页，怎么可能呢?

根据我的理解我们不能在分页中显示页码。我们能做的就是读取一定限制的记录，并提供NEXT链接来检索下n条记录。

分页是任何web应用程序的基本功能，我们如何将其迁移到DynamoDb这样的云数据库中?

请提供您的意见和建议。由于

Answer 1

是的，你是对的，DynamoDB中没有OFFSET。但只使用Limit和LastEvaluatedKey，我做了这个函数:

public function scan($table, $filter = [], $select = null, $limit = 2)
{
    $page = isset($_GET['page']) ? $_GET['page'] : 0;
    $options = [
        'TableName' => $table,
        'Count' => true,
    ];
    if (!empty($limit)) {
        $options['Limit'] = $limit;
    }
    if (!is_null($select)) {
        $options['Select'] = $select;
    }
    if (!empty($filter)) {
        $options['ScanFilter'] = $filter;
    }
    $results = $results = $this->_client->scan($options);
    while ($page > 0 && isset($results['LastEvaluatedKey'])) {
        $results = $results = $this->_client->scan($options);
        $options['ExclusiveStartKey'] = $results['LastEvaluatedKey'];
        $page--;
    }
    return $results;
}

$this->_client为DynamoDb客户端对象。
基本上，我用LastEvaluatedKey遍历所有条目，直到到达所需的页面。
要获取表中的全部条目，调用$this->scan($this->tableName(), [], null, null)['Count'];(即—不带任何搜索条件，也不带分页，就像普通分页函数一样)。

Answer 2

添加到@Justinas的答案，Dynamo将有相当可怕的分页性能，如果随机访问(即。跳转到任意页面)是需要的。但是，如果您只处理下一页和上一页，则可以传递LastEvaluatedKey，并将由于扫描而产生的开销保持在最低限度。

如评论中所述，您绝对应该尽可能多地缓存结果。至少，可以缓存LastEvaluatedKey结果，这样当用户浏览结果时，就不需要为每个分页请求重新计算它们。下面是我的意思的一个例子:

假设您有一个具有如下模式的表，其中CommentID是散列键。

 CommentID | Author | Comment | ...
-----------+--------+---------+------------
    1      | Joe    | Foo     | ...
    2      | Joe    | Bar     | ...
    3      | John   | Baz     | ...
    4      | Joe    | FooBar  | ...
    5      | Jane   | BooBaz  | ...
    6      | Joesie | Blah    | ...
    7      | Johnny | Blahaha | ...

当你开始分页时，假设你每页请求3个评论，你将获得第一页结果和LastEvaluatedKey = 3;然后，如果您进行第二次扫描请求，对于第2页，使用ExclusiveStartKey=3，您将获得LastEvaluatedKey = 6;要获得第3页，您将使用LastEvaluatedKey = 6进行另一次扫描。等等。

您可以看到，在没有任何缓存的情况下，为了获得第3页，您执行了三次扫描(如果您还请求第1页和第3页之前的两次扫描将会重复)。因此，我建议的优化是为每个页面存储相应的键。你会得到这样一个映射:

 Page | Hash-Key
------+----------
   1  |   null
   2  |     3
   3  |     6
  ..  |    ... 

当您浏览结果时，这些值将被填写。现在，当用户想要第3页时，您所要做的就是扫描一次，使用6作为ExclusiveStartKey。

当然，对于每个页面大小，您都需要一个这样的查找表，并且该表只有在添加(或删除)新行之前才是准确的。也就是说，如果您有很多请求，那么存储分页缓存所需的额外内存是值得的。剩下的就是根据表中添加(或删除)新数据的频率，为分页缓存设置一个合理的过期时间。