資料儲存體會

很多人入行以後都接受了若干習慣性的、實踐上的傳承，比如使用資料庫。不過，使用成品資料庫的目的是什麼？

第乙個答案恐怕首先就是查詢。查詢當然非常重要，不過查詢卻未必是所有問題的核心。我們可以觀察到的乙個現實情況是，很多很小的專案，其查詢實際上十分簡單，如果不考慮資料持久，而是在記憶體中處理，用一些最簡單的查詢方式，比如for迴圈就可以輕鬆搞定。

很多更大的專案也是如此：即便資料量有一定規模，「實體」種類很多，但它們的關係其實並不複雜，只會使用非常有限的資料庫功能。那麼為什麼要使用資料庫產品，這裡面就另有原因，這原因雖然很多人一時說不出來，但卻相當的顯而易見：以容易訪問的方式儲存小的資料片段。

為了達成這個目的，第乙個可用的中介軟體按理說是檔案系統，但大多數時候檔案系統都不在考慮範圍之內，這很大程度上是因為檔案系統有三個問題：

首先是檔案系統的分塊機制，大多數作業系統所支援的檔案系統預設一般是4k左右，最小的單位一般是512。可想而知，如果把比如「使用者名稱」每個存入乙個檔案，由於每個檔案會占用乙個塊，這會帶來極大的浪費。我們可以直接用檔名儲存資訊，但檔案系統並不保證空檔案不占用磁碟。

第二個問題是並不是所有的檔案系統都保證檔名按一定規則排序，這從根本上依賴檔案系統內部的索引方式。而大多數檔案系統僅支援某種預先設定的索引方式；而且這種方式即便是有序的，也沒有承諾檔案系統公升級的時候不會改變；同時，作業系統也沒有義務承諾不更換其它檔案系統。

第三個問題是，即便我們的業務無需依賴於資料排序，我們在乙個檔案系統中定位某一資料的方式也只有檔名，而對檔名的格式卻也不存在任何可靠的保證。比如長度限制、非法字元，有可能乙個檔案系統、在乙個時期內是這樣的，換乙個檔案系統或者換乙個版本又變成了那樣的。

這三個問題，除了第乙個部分的含有從經濟性上的一種考慮，其它問題說穿了就是檔案系統不提供任何穩定的協議可以可靠支撐除了檔案管理本身之外的業務資料管理。正是由於檔案系統的這種從人類約定上的不可依賴性，導致我們對其它解決方案產生了需求。

讓我們看看資料儲存的需求都是些什麼：從經濟性上講要緻密，就是說，無論多小的資料，它們基本上應該是乙個挨著乙個的；從易用性上來講它們應該容易定位，就是說，應該在幾個成本較低的操作之內就找到乙個資料；從很多普遍性的業務需求上來講應支援排序，就是說，找到了2就能馬上找到1和3。

這是最基本的需求，而諸如鏈結（join）一類的特性，實質上是偽需求。這麼說的原因是，它們是因為某類資料庫產品預先設定了資料儲存的模式（或schema），對於這些模式產生的新問題的一種彌補手段。比如，join的存在是因為我們把相關的一組資料放進了兩個不同的關係集合（**）。

實現上述需求，和隨之而來如一致性一類的要求，很顯然要付出一些成本，考慮到自己實現的成本，若眼前的任務能夠存在至少乙個到現有產品之間的同構，自然就可以使用它們。

為什麼要白活這些？掌握了基本事實、考慮自己的需求，就可以在自造、拿來，拿那種等問題上得到最準確的答案。

乙個不做保證的預告：

我最近在實現最基本的資料儲存這一塊，它在某些方面和大多數廣泛使用的產品採取了不同的選擇。比如取消了教科書上介紹的慣用方法中基於塊級別的一些管理手段；比如大多數資料庫產品無論是sql還是nosql都採取了c/s結構，而我的設計是每個程序都自己通過庫訪問檔案。

在這個過程中產生了一些經驗，有空想寫點文章記錄一下。

這些不同的做法（包括我從書上不同方案做出的選擇）並不是絕對的誰對誰錯，而是存在著諸多考慮：比如可變長資料所導致的空間**方式、碎片、利用率問題；比如刪除、更新資料所產生的問題；如何有效利用各種硬體擴充套件方式提高效率等等。

說實話這塊真沒什麼大學問，不過卻還是對技巧有點要求。