NoSQL I/O五分鐘法則

在 1987 年，Jim Gray 與 Gianfranco Putzolu 發表了這個"五分鐘法則"的觀點，簡而言之，如果一條記錄頻繁被訪問，就應該放到內存裡，否則的話就應該待在硬盤上按需要再訪問。這個臨界點就是五分鐘。 看上去像一條經驗性的法則，實際上五分鐘的評估標準是根據投入成本判斷的，根據當時的硬件發展水準，在內存中保持 1KB 的數據成本相當於硬盤中存據 400 秒的開銷(接近五分鐘)。這個法則在 1997 年左右的時候進行過一次回顧，證實了五分鐘法則依然有效（硬盤、內存實際上冇有質的飛躍)，而這次的回顧則是針對 SSD 這個"新的舊硬件"可能帶來的影響。

隨著閃存時代的來臨，五分鐘法則一分為二：是把 SSD 當成較慢的內存（extended buffer pool ）使用還是當成較快的硬盤（extended disk）使用。小內存頁在內存和閃存之間的移動對比大內存頁在閃存和磁盤之間的移動。在這個法則首次提出的 20 年之後，在閃存時代，5 分鐘法則依然有效，隻不過適合更大的內存頁(適合 64KB 的頁，這個頁大小的變化恰恰體現了計算機硬件工藝的發展，以及帶寬、延時)。

不要刪除數據

Oren Eini（又名Ayende Rahien）建議開發者儘量避免數據庫的軟刪除操作，讀者可能因此認為硬刪除是合理的選擇。作為對Ayende文章的回應，Udi Dahan強烈建議完全避免數據刪除。

所謂軟刪除主張在表中增加一個IsDeleted列以保持數據完整。如果某一行設置了IsDeleted標誌列，那麼這一行就被認為是已刪除的。Ayende覺得這種方法“簡單、容易理解、容易實現、容易溝通”，但“往往是錯的”。問題在於：

刪除一行或一個實體幾乎總不是簡單的事件。它不僅影響模型中的數據，還會影響模型的外觀。所以我們才要有外鍵去確保不會出現“訂單行”冇有對應的父“訂單”的情況。而這個例子隻能算是最簡單的情況。……

當采用軟刪除的時候，不管我們是否情願，都很容易出現數據受損，比如誰都不在意的一個小調整，就可能使“客戶”的“最新訂單”指向一條已經軟刪除的訂單。

如果開發者接到的要求就是從數據庫中刪除數據，要是不建議用軟刪除，那就隻能硬刪除了。為了保證數據一致性，開發者除了刪除直接有關的數據行，還應該級聯地刪除相關數據。可Udi Dahan提醒讀者注意，真實的世界並不是級聯的：

假設市場部決定從商品目錄中刪除一樣商品，那是不是說所有包含了該商品的舊訂單都要一並消失？再級聯下去，這些訂單對應的所有發票是不是也該刪除？這麼一步步刪下去，我們公司的損益報表是不是應該重做了？

冇天理了。

問題似乎出在對“刪除”這詞的解讀上。Dahan給出了這樣的例子：

我說的“刪除”其實是指這產品“停售”了。我們以後不再賣這種產品，清掉庫存以後不再進貨。以後顧客搜索商品或者翻閱目錄的時候不會再看見這種商品，但管倉庫的人暫時還得繼續管理它們。“刪除”是個貪方便的說法。

他接著舉了一些站在用戶角度的正確解讀：

訂單不是被刪除的，是被“取消”的。訂單取消得太晚，還會產生花費。

員工不是被刪除的，是被“解雇”的（也可能是退休了）。還有相應的補償金要處理。

職位不是被刪除的，是被“填補”的（或者招聘申請被撤回）。

在上麵這些例子中，我們的著眼點應該放在用戶希望完成的任務上，而非發生在某個
實體身上的技術動作。幾乎在所有的情況下，需要考慮的實體總不止一個。

為了代替IsDeleted標誌，Dahan建議用一個代表相關數據狀態的字段：有效、停用、取消、棄置等等。用戶可以借助這樣一個狀態字段回顧過去的數據，作為決策的依據。

刪除數據除了破壞數據一致性，還有其它負麵的後果。Dahan建議把所有數據都留在數據庫裡：“彆刪除。就是彆
刪除。”