我正在使用Windows Azure表存储来存储数以百万计的实体，但我试图找出最好的解决scheme，轻松地允许两件事情：
1）search一个实体，将检索该实体和至less（pageSize）实体的任何一方的实体数量
2）如果实体两侧的实体数量超过（页面大小）数量的实体数量更多，则显示页面下一页或页面上一个链接，这将继续，直到达到开始或结束。
3）顺序是逆时针顺序
我已经决定，PartitionKey将是由用户提供的标题，因为每个容器在系统中是唯一的。 RowKey是Steve Marx的语法algorithm：
http://blog.smarx.com/posts/using-numbers-as-keys-in-windows-azure
当转换为JavaScript而不是C＃看起来像这样：
pad（new Date（100000000 * 86400000）.getTime（） – new Date（）。getTime（），19）+“_”+ uuid（）
uuid（）是一个JavaScript函数，它返回一个guid，pad增加了长达19个字符的零。 因此系统中的logging如下所示：
PK RK TEST 0008638662595845431_ecf134e4-b10d-47e8-91f2-4de9c4d64388 TEST 0008638662595845432_ae7bb505-8594-43bc-80b7-6bd34bb9541b TEST 0008638662595845433_d527d215-03a5-4e46-8a54-10027b8e23f8 TEST 0008638662595845434_a2ebc3f4-67fe-43e2-becd-eaa41a4132e2 这种模式允许插入的每个新实体位于满足上面第3点的列表的顶部。
通过在系统中添加新logging的好方法，我认为我会创build一个机制，查看RowKey的前半部分，即根据已find的项目的哪个方向进行大于或小于比较。 换句话说，要获得排在0008638662595845431之前，我会做一个像这样的查询：
var tableService = azure.createTableService(); var minPossibleDateTimeNumber = pad(new Date(-100000000*86400000).getTime() - new Date().getTime(), 19); tableService.getTable('testTable', function (error) { if (error === null) { var query = azure.TableQuery .select() .from('testTable') .where('PartitionKey eq ?', 'TEST') .and('RowKey gt ?', minPossibleDateTimeNumber + '_') .and('RowKey lt ?', '0008638662595845431_') .and('Deleted eq ?', 'false');
如果返回的结果大于1000，azure给了我一个连续的标记，那么我想我会记得最后一个项RowKey，即数字部分0008638662595845431。所以现在下一个查询将有记忆值作为起始值等
我正在使用Windows Azure Node.Js SDK和语言是JavaScript。
任何人都可以看到这个方法有问题吗？
我不明白这是如何有效和高效地工作的，尤其是要获得上一页的行。
为了高效，“key”的前缀需要是一个连续递增或递减的值，而不是基于时间戳。 生成时间戳的值会有重复和空白，因此将页面大小映射到行计数的效果最好，效率低下，最难以确定。
此外，这种潜在的算法依赖于单个分区键，破坏了表的可伸缩性。
这里面临的挑战将是产生一个连续递增的密钥的方法。 一种解决方案是使用SQL数据库并对单行进行原子更新，从而按顺序生成递增或递减值。 就像更新…设置X = X + 1并返回X.也许使用存储过程。
所以关键可能是一个零左填充连续生成的数字。 这样分割就是说号码的前N位是分区键，其余的M位是行键。
For example PKey RKey 00001 10321 00001 10322 …. 00954 98912
现在，由于行是按顺序排列的，因此可以使用页面大小的确切键范围来编写查询。
警告。 在生成一个串行密钥和写入表存储之间发生故障的风险很小。 在这种情况下，桌子上可能会出现漏洞。 但是，您的分页算法应该能够通过指定稍大于所需的页面大小或通过重新调整范围来很容易地检测和解决此类实例。