Question

我有一个关于分页的工作代码，它适用于azure搜索和sql，但是当在documentdb上使用它时，最多需要60秒才能加载。

我们相信这是一个延迟问题，但我无法找到解决方法来加以解决，

任何文档或关于从哪里开始查看的想法？

    public PagedList(IQueryable<T> superset, int pageNumber, int pageSize, string sortExpression = null)
    {
        if (pageNumber < 1)
            throw new ArgumentOutOfRangeException("pageNumber", pageNumber, "PageNumber cannot be below 1.");
        if (pageSize < 1)
            throw new ArgumentOutOfRangeException("pageSize", pageSize, "PageSize cannot be less than 1.");


        // set source to blank list if superset is null to prevent exceptions
        TotalItemCount = superset == null ? 0 : superset.Count();
        if (superset != null && TotalItemCount > 0)
        {
            Subset.AddRange(pageNumber == 1
                ? superset.Skip(0).Take(pageSize).ToList()
                : superset.Skip((pageNumber - 1) * pageSize).Take(pageSize).ToList()
            );
        }
    }

Answer 1

虽然DocumentDB的LINQ提供程序在某些情况下将.Take（）转换为“TOP”SQL子句，但DocumentDB没有Skip的等价物。所以，我有点惊讶它的工作原理，但我怀疑提供商从头开始重新运行查询以模拟Skip。在评论here中，由DocumentDB产品经理主持讨论他们选择不实施SKIP的原因。 TL;博士;它不适用于NoSQL数据库。我可以用MongoDB（它确实具有跳过功能）来确认这一点。后面的页面只是扫描并丢弃早期的文档。你去的列表中的后者越慢。我怀疑LINQ实现正在做类似的事情，除了客户端。

DocumentDB确实有一种以块的形式获取文档的机制，但它的工作方式与SKIP略有不同。它使用延续令牌。您甚至可以设置maxPageSize，但不能保证您将获得该号码。

我建议您实现自己的客户端缓存并使用相当大的maxPageSize。假设您的UI中的每个页面都有10行，而您的缓存当前有27行。如果用户选择第1页或第2页，则您有足够的行来呈现已缓存的数据的结果。如果用户选择了第7页，那么您知道缓存中至少需要70行。使用最后一个延续令牌获取更多，直到缓存中至少有70行，然后呈现行61-70。从好的方面来看，延续令牌是长期存在的，因此您可以根据用户输入稍后使用它们。

使用分页时的Documentdb性能

1 个答案: