GFS解決了某些業務情境對Distributed File System需求，很自然的，也有某些業務僅僅靠檔案系統用起來還是不那麼方便，它們需要分散式資料庫系統。BigTable就是Google為瞭解決內部對大規模結構化資料處理的需求而產生的。論文摘要涉及的“關鍵”字為：
1. 結構化資料
2. 資料量大
3. 典型應用：Web索引，Google Earth，Google Finance
4. 批處理和即時需求
5. 資料模型
首先，需要注意的是，這裡所謂的結構化資料和做DBMS的說的結構化資料不完全是一回事。後者定義的結構化資料都是數值、字串等確實比較結構化的資料，而且長度也不會很大；採用的資料模型大多指的就是關聯式模式。其次，資料量大和此前做DBMS的人喜歡說的海量資料庫也不是一個數量級。海量只不過是TB，而這裡的大怎麼著也是PB甚至以上了（這個大概和做OLAP的人說的量級差不多）。既然如此，典型的那些應用顯然也超出了傳統關聯式資料庫能夠擺平的範圍了。
對於批處理業務，可以理解為其處理時間需要的比較多，至少不是秒級的回應時間。而對於即時需求，應該也不是即時作業系統，怎麼也應該是毫秒甚至秒層級的回應時間吧。從上面這些簡單的分析可以看出，很多術語的準確含義是需要上下文才可以對比，否則容易望文生義。
資料模型相對比較好理解，既然BigTable宣稱是個資料庫，那最核心的邏輯概念就是支援的資料模型是什麼。第二節說“大表”是個稀疏的、分布的、持久化的、多維的、有序的Map。那它就不是關聯式模式，也不是物件模型或其他各種傳統的資料模型了。這個定義有點囉嗦，但準確的描述了BigTable的特徵。
對於一個大型的資料管理軟體，我們要關心的問題是有一定通用性的。例如：
1. 資料模型
2. 編程介面
3. 依賴的基礎設施/組件
4. 實現中的最佳化
5. 效能資料以及典型情境
這也是論文的後續章節主要介紹的內容。
在學習BigTable的資料模型/實現時，不妨帶著與關聯式模式/實現的類比去思考以下問題：
1. 它和關聯式模式的區別
2. 它支援ACID嗎
3. 資料的組織和Heap、Cluster B+樹類似嗎
4. 它有索引嗎
5. 模式定義
6. 資料的分區（垂直資料分割和水平資料分割）
7. 許可權控制
8. 行的多版本等等
更重要的，它的並發控制機制是什嗎？如果它和傳統資料庫在這些基本問題上差別/差距越大，那就可以說它越不像一個資料庫:-)。
對於資料管理系統而言，支援的操作/API至少應該包括：
1. 模式定義（建表、改表、刪表）
2. 資料操縱（增刪改查）
3. 許可權控制（許可權的授予和回收）
要不使用者怎麼用啊？這些API裡頭最複雜和最有搞頭的當屬查資料了：
1. 全表掃描
2. 點查詢
3. 範圍查詢
讀第三節的時候，我們可以帶著上述這些問題去思考哪些有交集，哪些是傳統DBMS沒有提供的。
絕大多數實際系統都不是從零開始的，而是要站在巨人的肩膀上。Distributed File System有很多是建立在本地檔案系統之上的，資料庫很多是把資料存在檔案裡頭的。BigTable也不例外。只不過它依賴的基礎設施/組件比我想象的要多，而且多出來的那些組件一個比一個重要：GFS用來存資料檔案和記錄檔，叢集管理系統用來調度作業、管理資源、處理故障等，SSTable定義了檔案格式（Sorted String Table），Chubby提供分布式鎖服務。Chubby是如此的重要和複雜，需要單獨寫篇論文來描述它。
有了資料模型，定義了編程介面，準備好了基礎設施。後續的重要工作就是系統實現和最佳化了。BigTable有三個組要的模組：用戶端/函數庫、Master server、Tablet servers。詳細內容需要閱讀第五節。這裡列出需要注意的問題：
1. Master的職責
2. Tablet的職責
3. tablet的位置管理（為什麼是3層，定位的效率）
4. Master怎麼track各個tablet的死活？
5. 元資訊的特殊處理
6. tablet的增減、合并
7. 日誌
8. 三種compaction
9. 恢複等等。
這裡頭涉及到的細節比較多，需要慢慢的品味。而一涉及效能最佳化，就會比較發散到壓縮、布隆過濾器等等比較通用的演算法/技術。有些東西沒有做過，理解得還比較膚淺，留待後面繼續學習。。。。。
