《NoSQL權威指南》——第2章 列式資料庫

nosql權威指南

簡介

從打孔卡和錄音帶的年代開始，檔案就是實體裝置上連續的位元組，通路的方式是從檔案開始（打開檔案）到檔案結束（檔案結束的标志為<code>true</code>）。是的，存儲可以在磁盤上被分割成資料頁，并且各種資料頁可以通過指針鍊連接配接，但這種模型仍然與前面提到的打孔卡、錄音帶是相同的。後來，檔案被拆分成記錄（record，更多實體連續的位元組），記錄又被拆分成字段（field，仍然是更多實體連續的位元組）。

檔案被一條記錄一條記錄地處理（讀/取一條，然後下一條）或按照實體存儲位置順序地處理（從頭到檔案結尾，或遵循一個指針鍊前進/後退n條記錄，等等）。在這種模型中沒有任何并行。這裡還有一個假設：檔案中記錄（行）和記錄中字段是實體排序的。為了使對這些資料的通路有效，花了大量的時間和資源來對記錄進行排序。在錄音帶上無法做到随機存取，打孔卡上也無法做到。

到了rdbms和sql時代，這種檔案系統模型仍然占主導地位。codd博士也陷入了困境。首先，他必須在所有表中擁有一個主鍵（<code>primary key</code>），主鍵對應于順序檔案的排列次序；後來，他意識到鍵就是鍵，沒有必要在rdbms中讓其中一個鍵成為特殊的字段。但是，sql已經納入了已有的技術特性，而且早期的sql引擎也是建立在既有檔案系統上的，是以在這個環節上卡住了。

列式模式采用了一種完全不同的方法。但它是一種可以與sql和關系模型很好地一起工作的模型。在rdbms中，表（bable）是一個具有完全相同類型的行（row）的無序集合。一個行是相同類型的無序列（column）的集合，每列儲存與既定列相關的标量值。可以通過列名稱來通路對應的列，而不是通過存儲中的實體位置，當然，也可以使用<code>"select*"</code>等簡單方式來通路，以節省要輸入。

對應的邏輯模型如下：表是行的集合，有且僅有一種結構；行是一組列的集合；列是取自一個且僅一個已知域的标量值。存儲通常會在傳統的檔案系統中遵循這種模式，用檔案表示表，用記錄表示行，用字段表示列。但這都與實體存儲無關。

在列式模型中，我們設計一個表，并且使用列式資料庫特有的資料結構來存儲每個列。行和表可以從這些行重新組合生成。看看平常的表的設計，可以看到為什麼它們稱為垂直存儲模型，而不是水準存儲模型。