使用分頁時的Documentdb性能

我有一個分頁工作代碼，它可以很好地與azure搜索和sql結合使用，但是在documentdb上使用它時，最多需要60秒才能加載。使用分頁時的Documentdb性能

我們相信這是一個延遲的問題，但我不能找到一個解決辦法來固定它，

任何文件，或從哪裏開始尋找想法？

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() 
      ); 
     } 
    }

來源

2016-03-03 Saikios

雖然DocumentDB的LINQ提供程序在某些情況下將.Take（）轉換爲「TOP」SQL子句，但DocumentDB與Skip沒有等效。所以，我有點驚訝它的工作原理，但我懷疑提供程序是從頭開始重新運行查詢以模擬Skip。在評論here是由DocumentDB產品經理領導的關於他們爲什麼選擇不實施SKIP的討論。 TL;博士;它不針對NoSQL數據庫進行擴展。我可以用MongoDB確認這一點（它具有跳過功能）。後來的頁面只是掃描並扔掉早期的文檔。列表中後面的那個，它越慢。我懷疑，除了客戶端之外，LINQ實現正在做類似的事情。

DocumentDB確實有一個獲取文檔塊的機制，但它的工作方式與SKIP有點不同。它使用連續令牌。你甚至可以設置一個maxPageSize，但是不能保證你會得到這個數字。

我建議您實現自己的客戶端緩存並使用相當大的maxPageSize。假設您的用戶界面中的每個頁面都是10行，而您的緩存目前有27行。如果用戶選擇頁面1或頁面2，則有足夠的行可以顯示已緩存數據的結果。如果用戶選擇第7頁，那麼您知道在緩存中至少需要70行。直到您的緩存中至少有70行，然後渲染第61-70行爲止，請使用最後一個連續令牌獲取更多。從好的一面來看，延續令牌很長時間，所以你可以在以後根據用戶輸入使用它們。

來源

2016-03-03 02:35:15

謝謝Larry，我們正在考慮遷移到cassandra或couchdatabase，我們預計電子商務每天會有超過一百萬的請求，您對這個主題有何興趣？（特別是訂單和購物車） – Saikios

我是PaaS產品的忠實擁躉。在用Cassandra，Couch（pre-Couchbase）和MongoDB構建解決方案後，我發現所有這些解決方案的負擔過重（尤其是MongoDB）。所以，我最喜歡的是DocumentDB。我特別喜歡用JavaScript編寫ACID事務的能力。在AWS和Google上有很好的無操作選擇，如果與我合作的組織有偏好，但我會使用這些選擇，但沒有哪一個適合我的心智模式比DocumentDB更好，我會錯過它。 –

感謝您的見解，我們嘗試了令牌化，但它攔截了我們的apis，我讀他們正在更新json過濾器，但我們無法等待，我正在檢查orientdb以查看它是否會更好地執行 – Saikios

使用分頁時的Documentdb性能

回答

相關問題