我使用頁碼和限制在 Go 中創(chuàng)建了分頁。在哪里L(fēng)imit & Page Number are INT我創(chuàng)建了如下分頁：MONGO_SESSION.Find(nil).Skip(pageNumber*limit).Limit(limit).Sort("_id").All(&RETURN_STRUCT)它工作正常。但是當(dāng)我發(fā)送頁碼或限制為零時。默認情況下，mongo DB 返回所有記錄，因為沒有什么可以跳過和限制的。所以我的問題是，在零限制和零頁碼的情況下，什么是好的做法。實踐一：發(fā)送所有數(shù)據(jù)。不要發(fā)送錯誤響應(yīng)。實踐 2：發(fā)送錯誤響應(yīng)說“頁碼和限制不能為零”注意：我不能硬編碼限制或頁碼。任何建議將不勝感激。
3 回答
慕運維8079593
TA貢獻1876條經(jīng)驗 獲得超5個贊
這個問題有點基于意見（因此對于 StackOverflow 來說有點偏離主題），但我認為一些建議或一般做法可能對其他人有幫助和有用。因此，以下答案是我的意見。
作為服務(wù)器應(yīng)用程序的開發(fā)人員，您應(yīng)對服務(wù)器的安全和保障以及服務(wù)器資源的利用負責(zé)。作為開發(fā)人員，您應(yīng)該在必要的最低限度內(nèi)信任客戶。
也就是說，當(dāng)客戶未能指定限制（無意或有意）時發(fā)送所有文件是處理這種情況的最糟糕方法。這就像尖叫：“嘿，客戶和黑客，這是一個端點，如果你想對我的服務(wù)器進行DoS 攻擊，只需調(diào)用這個端點幾次”。
為了保護您的服務(wù)器，即使對于“l(fā)imit”參數(shù)，您也應(yīng)該有一個安全限制，因為允許它的任何值都可能同樣糟糕：僅僅因為您強制客戶端指定一個限制并不能保護您的服務(wù)器，“bad”客戶也可以發(fā)送一個限制，比如1e9很可能包括您的所有文件。
我的建議是始終具有有意義的默認值和安全限制。應(yīng)始終記錄默認值，安全限制并不那么重要（但也可以記錄）。
那么你應(yīng)該如何處理它：
如果缺少限制，請應(yīng)用默認值。如果您不能有默認值，請?zhí)^此步驟（盡管必須有充分的理由不具有/允許默認值）。
應(yīng)根據(jù)安全限值檢查限值。如果超過安全值，則使用安全限制（最大允許限制）。
如果服務(wù)器“有權(quán)”更改請求的限制（例如，在缺少限制時使用默認值，或根據(jù)安全限制限制限制），服務(wù)器應(yīng)將實際用于服務(wù)的限制傳達給客戶端要求。
關(guān)于高效的 MongoDB 分頁：我只建議使用Query.Skip()andQuery.Limit()用于“小”文檔計數(shù)。
HUX布斯
TA貢獻1876條經(jīng)驗 獲得超6個贊
我相信，分頁應(yīng)該只用于集合大小很大的情況（否則只是一次顯示所有數(shù)據(jù)并且根本不要擺弄分頁）。
但是，如果集合相當(dāng)大，那么發(fā)送所有數(shù)據(jù)并不是一個好主意。
“skip”語句還有一個問題（雖然它不是 mongo 獨有的）：為了跳過 N 條記錄，數(shù)據(jù)庫必須進行全掃描（如果是 mongo，則為全集合掃描），因此需要更多時間獲取第 N + 1 頁的結(jié)果而不是第 N 頁的結(jié)果。
現(xiàn)在，為了處理它，有一個“技巧”：根本不要使用 skip，而是“記住”最后一個文檔 ID（無論如何它已經(jīng)編入索引并且您仍然可以排序_id）。然后查詢將是（偽代碼，因為我不會說“Go”）：
對于第一個查詢：
Find().sort(_id).limit(limitSize)對于后續(xù)查詢：
Find ().where(_id > lastMemorizedId).sort(_id).limit(limitSize)
holdtom
TA貢獻1805條經(jīng)驗 獲得超10個贊
我也遇到了同樣的問題。我更喜歡發(fā)送錯誤響應(yīng)而不是顯示所有數(shù)據(jù)。
因為如果 DB 必須發(fā)送所有數(shù)據(jù)，這對 DB 來說是一項繁重的事務(wù)。在小型集合上，它工作正常，但對于大型集合，它會掛起 DB。
所以發(fā)送一個錯誤響應(yīng)。
- 3 回答
- 0 關(guān)注
- 197 瀏覽
添加回答
舉報
0/150
提交
取消