app後端設計 資料增量更新

2021-07-04 10:14:55 字數 1655 閱讀 8217

因為分頁機制的存在,這個演算法實現起來是挺多需要注意的地方,下面我舉乙個簡化的例子詳細說明:

一些假設:

count: 每頁的顯示條數(預設為3)

page: 當前頁碼(預設為1)

since: 時間戳,若指定此引數,則返回時間戳大於等於since的結果(應該是上次獲取的最新資料的update_time)

max: 時間戳,若指定此引數,則返回時間戳少於等於max的結果(應該是傳送時的時間)

在sql的查詢時,使用條件 since<=update_time<= max

2. api 返回的資料報含

,現在開始討論:

伺服器的資料表的資料

idupdate_time id

update_time

傳送的請求為:http://test/api/timeline?count=3&page=1&since=0&max=1105

api返回的資料

,伺服器的資料表的資料

idupdate_time id

update_time

這裡是策略的重點(1)api返回資料中的max必須為最後一條資料的update_time

伺服器的資料表的資料

idupdate_time

可看到,比起上次拉取資料的時候,伺服器的資料表多了id為4,5,6,7的資料。

這時傳送api請求,策略的重點(2):當api的返回資料size=total時,since值比上次獲取大一點,因為這時資料已經獲取完整了,沒必要重複獲取資料上次已經獲取的資料(記得條件since<=update_time<= max 嗎?)所以since值設定為1101+1=1102,max為現在的時間點:1120,請求的url如下:

api返回的資料,id

update_time

a.update_time剛好是1119

b.update_time大於1119

伺服器的資料表的資料

idupdate_time

這時傳送api請求,這裡是策略的重點(4):當api的返回資料size少於total,為了避免有資料丟失,since為上次收到api的返回資料的max值:1119,max為現在的時間點:1130。關於策略重點(4),請結合策略的重點(3)一起理解。

請求的url如下:

api返回的資料,

idupdate_time

ok,整個增量更新的策略已經分析完畢了。在這個策略中,page引數幾乎沒用,之所以要保留,是為了相容分頁不帶since,max的情況。對於這個增量更新的策略,請仔細理解策略的重點(1)(2)(3)(4)(5)的分析。

app後端設計 資料增量更新

因為分頁機制的存在,這個演算法實現起來是挺多需要注意的地方,下面我舉乙個簡化的例子詳細說明 一些假設 count 每頁的顯示條數 預設為3 page 當前頁碼 預設為1 since 時間戳,若指定此引數,則返回時間戳大於等於since的結果 應該是上次獲取的最新資料的update time max ...

app後端設計 資料庫分表

當專案上線後,隨著使用者的增長,有些資料表的規模會以幾何級增長,當資料達到一定規模的時候 例如100萬條 查詢,讀取效能就下降得很厲害,這時,我們就要考慮分表。更新表資料時會導致索引更新,當單錶資料量很大時這個過程比較耗時,這就是為什麼對大表進行新增操作會比較慢的原因,並且更新表資料會進行表級鎖或者...

Package設計2 增量更新

ssis 設計系列 一般來說,etl實現增量更新的方式有兩種,第一種 記錄欄位的最大值,如果資料來源中存在持續增加的資料列,記錄上次處理的資料集中,該列的最大值 第二種是,儲存hashvalue,快速檢查所有資料,發現異動的資料之後,只同步更新被修改的資料。1,欄位的最大值 記錄欄位的最大值,使用d...