Azure 存储表分页答案

【问题标题】：Azure Storage Table PagingAzure 存储表分页
【发布时间】：2011-06-13 08:14:56
【问题描述】：

在 Azure 存储中实现简单分页相对简单：Paging with Windows Azure Table Storage。这可以通过延续令牌功能来实现。

但是。

这只是正式寻呼的开始。第一个问题是排序。您不能在 Azure 表中执行 OrderBy。克服这个问题的最佳解决方案是什么？页面必须排序，这是事实。

第二个问题，当涉及到分页时，要知道总页数，仅使用延续令牌功能这是不可能的。在我看来，在每一页都执行“.Count()”效率非常低（例如，分区可能位于多个服务器上）。

第三个问题是，与第二个相关，即使你可以计算你有多少页，如何将计数的页面“连接”到实际的延续令牌？这对我来说是最大的谜团。 如何从特定的表格行获得延续？

如果能提供正确的解决方案，我将非常高兴。我必须承认我也有一个，我会写在下面的答案之一中。

【问题讨论】：

对此问题和答案有任何反馈吗？
如果您需要排序和计数 Table Storage 不是合适的产品。 SQL Azure 提供排序和计数。表存储用于存储大量行，主要搜索分区键和行键。它用于序列化大量的类。
听起来你需要一个关系数据库，而不是 NoSQL 数据库。

标签： c# architecture azure azure-storage azure-table-storage

【解决方案1】：

我知道这并不能按照您要求的方式解决您的问题，但我仍然认为不应该按照您建议的方式执行分页。我的意思是，由于 Azure 表存储不支持您需要的功能，它可能不太适合。

我会在本地缓存中获取数据，在那里执行排序和分页并完成它。有一个建议的解决方法是仔细构建 rowkey/partitionkey，但我强烈建议您不要遵循此限制。

Blog blog=  new Blog();
// Note the fixed length of 19 being used since the max tick value is 19 digits long.
string rowKeyToUse = string.Format("{0:D19}", 
        DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks);
blog.RowKey = rowKeyToUse;

因此，日期为 2008 年 10 月 1 日上午 10:00:00 的博客 b1 将具有 2521794455999999999 作为 RowKey，而日期为 2008 年 10 月 2 日上午 10:00:00 的博客 b2 将具有 2521793591999999999 作为 RowKey，因此 b2 将在 b1 之前。

要检索 2008 年 10 月 1 日上午 10:00:00 之后的所有博客，我们将使用以下查询：

     string rowKeyToUse = string.Format("{0:D19}", 
        DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks);
var blogs = 
    from blog in context.CreateQuery<Blog>("Blogs")
    where blog.PartitionKey == "Football" 
        && blog.RowKey.CompareTo(rowKeyToUse) > 0
  select blog;

（取自 Windows Azure Table，2008 年 12 月文档provided 由 Microsoft 提供）

至于计算页数，这很简单，这里只需简单的除法运算即可；至于延续令牌，一种方法是（根据初始请求）在每个页面上“行走”并获取延续令牌，它基本上只是告诉您接下来是哪些行和分区键。但是拥有所有这些意味着您容易受到一致性错误的影响（例如，如果有人将某些内容发布到同一个表存储中）。

就我个人而言，如上所述，我会根据行键进行分页，或者，如果这是必需的，则转移到支持它的存储引擎。

更详细地说，如果您知道您将只有一个“OrderBy”子句，您可以选择所有子句，并通过一些暗示，猜测页面边界将是什么。

另一方面，我相信提供的分页不是为了允许在前端进行分页，而是为了减轻 1000 个结果的限制。但这只是我的 0.02 美元。

【讨论】：