我在 MarkLogic 中構建了一個服務，該服務由下游應用程式使用（GET 方法）。在 REST 端點中，我們有四個引數，例如 startDate、endDate、seqStart 和 seqLength。
必須通過 REST 端點發送的資料總數為 1.5M，我們分批發送 25,000 個
我注意到兩次執行的經過時間不同，這兩次執行具有相同的批量大小和不同的序列開始
1)seq start=1 seqLength=25000 ElapsedTime=40s
2)seq start=100000 seqLength=25000 ElapsedTime=70s
seqLength為什么對于具有相同和不同的 REST 呼叫，我會得到不同的 Elapsed 值seqStart
我fn:subsequence在我的 CTS 查詢中使用。這是正常行為還是我需要對服務進行任何更改。
uj5u.com熱心網友回復：
這實際上是一個常見問題，不僅在 MarkLogic 中，而且在許多其他 DBMS 和搜索引擎系統中也是如此。
您可以在本地運行這樣的查詢來驗證它：
fn:subsequence(cts:search(fn:doc(), cts:true-query(), 1, 10))
然后將經過的時間與查詢進行比較，例如：
fn:subsequence(cts:search(fn:doc(), cts:true-query(), 1000000, 10))
本質上，問題是 MarkLogic 必須解決整個查詢，然后單獨生成和分頁每個結果，直到它完成構建您想要的頁面/批次的結果。
加快此速度的唯一方法是計算頁面/批次的總數，然后在您尋找高于頁面結果集的中點的頁面時以相反的順序迭代。
但是，朝向結果集中心的頁面仍然總是最慢的。
通過以相反的順序構建頁面，類似以下的內容應該可以更快地回傳更接近結果集末尾的頁面：
let $pageNumber := 1000
let $resultCount := xdmp:estimate(cts:search(cts:true-query()))
let $pageSize := 25000
let $totalPages := $resultCount div $pageSize
let $middlePage := $totalPages div 2
let $reverseOrder := if($pageNumber gt $middlePage) then fn:true() else fn:false()
let $searchOrder := if($reverseOrder) then "ascending" else "descending"
let $start := if($reverseOrder) then ($middlePage * $pageSize) - ($pageNumber * $pageSize - $middlePage * $pageSize) else $pageNumber * $pageSize
let $end := $start $pageSize
return fn:subsequence(cts:search(fn:doc(), cts:true-query(), ($searchOrder)), $start, $end)
您還可以使用其他一些新穎的技巧來更快地構建匯出。
如果您要匯出的資料集是完全靜態的或未排序的，您可以將唯一的增量 ID 放入每個檔案中，例如 1、2 等...然后您只需要運行：
cts:search(fn:doc(), cta:and-query((cts:element-range-query(xs:QName("id"), ">=" $start), (cts:element-range-query(xs:QName("id"), "<=" $end))
這將只回傳屬于頁面的結果。
If the set is unsorted or that is to say order doesn't matter then this approach is valid for a bulk export. If order does matter then the time and difficulty it takes to keep the ID up to date is probably not worth it unless changes to the data set is highly infrequent.
Another approach you can look at is using smaller batches, running multiple workers/exporters in parallel and then stitching the export back together yourself after its completed. Sounds like you're doing something similar to this already. I'm just suggesting you continue to further scale it out with more parallel workers. The problem you may run into is that you may get an incomplete export if the data set changes before the export finishes.
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/440215.html