使用PHP的AWS DynamoDB分頁

Question

有人知道從表中分頁記錄。 其實我想在php中使用DynamoDb創建一個paginate組件。

現在看來似乎是不可能給分頁像<第一次> <前> 1,2,3，4，5 ... <下> <最后>。

因為Dyanmodb只是提供了我們LIMIT條款，我們可以通過它來閱讀某些號碼。 記錄，我們可以通過LastEvaluatedKey處理下n個記錄。 所以，如果我想直接跳到第5頁，怎么可能？

根據我的理解，我們無法將頁碼顯示在分頁中。 我們能做的就是讀取某些記錄限制並提供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頁和第2頁，則會重復其中兩次掃描）。 因此，我建議的優化是為每個頁面存儲相應的鍵。 你最終得到這樣的地圖：

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

當您翻閱結果時，這些值將被填寫。 現在，當用戶想要第3頁時，您所要做的就是一次掃描，使用6作為ExclusiveStartKey 。

當然，對於每個頁面大小，您需要一個這樣的查找表，並且只有在添加（或刪除）新行之前，該表才是准確的。 也就是說，如果你有很多請求，那么存儲分頁緩存所需的額外內存將非常值得。 剩下的就是為您的分頁緩存設置合理的到期時間，具體取決於在表中添加（或刪除）新數據的頻率。