網路課程心得整理

1. 0
現代資料庫
2017/1/10

2. 11
大綱
 History
 Data Warehouse
 OLTP
 Everything Else
 NoSQL
 Array DBMS
 Graph DBMS
 Hadoop
 Summary

3. 2
History

4. 33
歷史演變
1970
1984
1990
2004
大致上發明
了關聯式資
料庫模型
IBM釋出了
DB2系統，
宣告了
RDBMS是一
項主流技術
90年代中，
這項技術佔
據了整個市
場，被稱為
「One-size
fits all」
Google提出
Bigtable，大
家慢慢覺得
RDBMS不再
適用各種場景，
NoSQL及
NEWSQL的
出現
隨著時間的演進，慢慢發現傳統的RDBMS智慧變成又笨又慢的「大象」

5. 44
「大象」的智慧
• 資料存在Disk上
━ SQL語言是你互動的方式
• 使用Cache Memory
━ 將常使用或近期的資料放在Cache Memory，
降低進磁碟撈取資料的頻率
• 建立Index
━ 可大幅縮短查詢的時間
• 支持ACID原則
━ 所有的系統都提供了Locking與Recovery機制

6. 55
OLTP與DW
面向 OLTP DW
目的 交易 分析
資料使用 只使用交易必須資料 使用龐大的歷史資料
資料量 交易資料通常較小 非常龐大，保留完整歷史資料
資料觀點 少維度 多維度(ex:日期可拆分成年、月、日、時)
要求重點 反應快，及時，難以忍受停機 快速提供決策資訊，事先定義資料
更新頻率 極高(交易需及時處理) 低
應用 查詢、更新 計算、分析
資料型態 原始的詳細資料，關聯式，多正規化 衍生資料，彙總計算資料
ID 資產 台幣 外幣
.
.
.
.
A123XXXXXX 1,500 1,000 500
A123XXXXXX 1,500 - 1,500更新
ID 資產
A123XXXXXX 100
A567XXXXXX 105
. 110
. 100
. 120
. 125 平均資產110

7. 66
ACID原則
資料庫管理系統（DBMS）在寫入或更新資料的過程中，為保證交易
（Transaction）是正確可靠的，所必須具備的四個特性：
Atomicity(原子性)
Transaction在執行過程中發生錯誤，會被Rollback到交易開始前的狀態，不會停在中間某個環節。
(ex：A帳戶有1000元，轉錢至B帳戶，在A扣款100元B帳戶尚未入帳時發生錯誤，系統將恢復至A帳戶
還是1000元的狀態)
Consistency(一致性)
在Transaction開始之前和結束以後，資料庫的完整性沒有被破壞。寫入的資料必須完全符合預設規則。
(ex： A帳戶有1000元，B帳戶0元，A轉100元至B帳戶，交易結束後還是維持A+B=1000元的一致性)
Isolation(隔離性)
資料庫允許多個Transaction同時對數據進行讀寫和修改的能力，隔離性可以防止多個Transaction並發
執行時所導致數據的不一致，也就是說，一個交易不會影響到其它交易的執行結果。
(ex：A轉錢至B帳戶，A交易尚未完成前，B此時查詢無法看到新增的錢)
Durability(持久性)
確認交易完成後，資料庫會保存交易後的結果，即便系統故障也不會丟失。

8. 77
「大象」如何做到ACID？
• Dynamic row-level locking(動態列鎖定)
━ 要做到隔離性我們使用鎖定，每次更新一筆紀錄時，你得
進行鎖定以防止其他交易同時更新
• Write-ahead log(預寫式紀錄)
━ 為維持原子性和持久性，所有的交易在提交之前都要先將
紀錄寫入磁碟中，不會發生忽然當機導致無法恢復
• Replication(備份)
━ 故障時需做系統恢復

9. 88
目前資料庫市場
 1/3-Data Warehouse
 1/3-OLTP
 1/3-Everything Else
 NoSQL
 Array DBMS
 Graph DBMS
 Hadoop

10. 9
Data Warehouse

11. 1010
DW架構觀念
• 大多數的DW都有一個Fact Table
• 圍繞著Fact Table的是Dimension Table
• 因此我們叫它Star/Snowflake Schema
供應商
Dimension
table
供應商key
供應商型式銷售Fact table
時間key
產品key
分公司key
地區key
銷售金額
銷售數量
時間
Dimension
table
時間key
時
日
月
年
分公司
Dimension
table
分公司key
分公司名稱
分公司型式
產品
Dimension
table
產品key
產品名稱
品牌
型號
供應商key
地區
Dimension
table
地區key
城市
街道
Dimension table做正規化
延伸成Snowflake Schema
Star Schema

12. 1111
DW - Column store vs. Row store
• Row-store
━ Row store是將資料以row為單位儲存在磁碟上，傳統資料庫都是採用row-store
━ 當要讀取一整個column時，你必需讀進所有的row
• Column-store
• 只讀取需要的column
━ Column-store則是改以column為單位儲存
━ 只會讀取需要的column
• 更高的壓縮比例
━ Row-store你可能有100種屬性存在同個儲存區塊中，壓縮不易，而column-
store儲存區塊內屬性相同，壓縮比高

13. 1212
DW - Vertica
………………………….
原始值 DELTA壓縮
100 100
103 3
105 2
107 2
• Column-store資料以欄進行儲存
━ 將所有屬性由左至右排列，這就是Vertica處理資料的方式，最左邊的被排列了下一
個只有在與左列相符時才會被排列
• 同一欄的值被存在同一個「chunklet」區塊
━ 盡可能的希望能存最多的資料，第一個值被無壓縮的存起來，而其他所有的值則被
壓縮儲存(資料壓縮方式：DELTA編碼紀錄前項的差值、Lempel-zipf、huffman…)
• 儲存區塊只在必要時才被解壓縮
━ 你可以做基本操作而不需要解壓縮，這就是惰性解壓縮，而這些操作是取出一個區
塊然後處理在該欄的屬性數值

14. 1313
DW - 有哪些廠商參與？
• Column-store
━ HP(Vertica)、SAP(Hana)、Amazon(Paraccel)
• Row-store
━ Microsoft、Oracle、DB2、Netezza
• 轉型中
━ Teradata、Asterdata、Greenplum

15. 1414
DW - Summary
• 傳統的「大象」在DW市場毫無發揮的空間
• 未來會成功的DW產品將是Column-store
• 「大象」可以選擇退出或是轉為Column-store，
也是它們需要面臨的困境

16. 15
OLTP

17. 1616
1. 資料存於Disk
━ CPUCacheRamDisk
2. Locking
━ Lock資料造成排隊延遲
3. Data Logging
━ 將每一筆交易各個階段都記錄到Disk
三個主要拖慢OLTP速度的因素
Transaction

18. 1717
OLTP - 實際檢測Main Memory的績效
24%
Locking
24%
Latching
24%
Cache
24%
Recovery
Useful Work
4%
• 以TPC-C標準評測，這
是「交易處理委員會」
的標準交易處理評測
• 測量運行時間，CPU運
作幾個週期，因為一切
都存於主記憶體中
• 如果需要跑得更快，我
們必須要擺脫這四塊餅

19. 1818
OLTP - 時間花費在哪裡？
1. Cache(快取)
資料被高度壓縮在Disk中，要更新這些資料必須找到正確的位置將它解壓縮成主記憶
體格式，更新它，然後逆向把它放回Disk，這些動作大概花費了1/4的時間。
2. Locking(鎖定)
每次更新一筆紀錄時，你得進行鎖定以防止其他交易同時更新，管理這些lock table
大概也花費了1/4的時間。
3. Latching(閉鎖)
傳統資料庫為多執行緒，同時進行很多平行處理，多執行同時接觸共享資料就必須鎖
定它以確保不被毀損，鎖定造成的排隊延遲約佔了1/4的時間。
4. Recovery(恢復)
Write ahead log，每一次更新在提交之前都要先將log寫入Disk，佔了最後1/4的時
間。

20. 1919
OLTP - 新的方法取代舊的方法
擺脫掉Cache耗損 In-Memory not disk
擺脫掉Locking耗損
Concurrency control(MVCC/Time stamp
order) not dynamic locking
擺脫掉Latching耗損 單執行緒系統取代多執行緒
擺脫掉Recovery耗損
1. 故障時切到備份處理，不做系統恢復
2. Command logging not Data logging

21. 2020
OLTP - 新系統的出現
• Microsoft(Hekaton)
• SAP(Hana)
• VoltDB、MemSQL 、SQLFire…
• 這些新系統將比傳統的還快100倍

22. 2121
OLTP - Summary
• In-Memory
• 新的Locking Control方法
• 建立Replication機制

23. 22
Everything Else
• NoSQL
• Array DBMS
• Graph DBMS
• Hadoop

24. 23
NoSQL

25. 2424
NoSQL - Give up SQL
• SQL為高階語言
• 高階語言(SQL)其實很好，不用再學各式各類的低階程式
• 早期NoSQL提倡者說SQL實在是太慢了，建議 give up SQL
SQL

26. 2525
NoSQL - Give up ACID
• 早期NoSQL提倡者說ACID羈絆著我們，如果你不需要用到ACID，
那就give up ACID
• 之前提到的新想法可以讓ACID跑得更快，而NoSQL提倡放棄
ACID是在早期的「大象」時期，現在的技術已經可以夠快且不用
放棄ACID

27. 2626
NoSQL - Schema later
• RDBMS在你載入資料之前必需 Schema before
━ 優點：預先做一點思考可以避免一些災難
━ 缺點：不夠彈性及快速
• 早期NoSQL提倡者說先載入你的資料吧，Schema later
━ 優點：彈性且快速
━ 缺點：資料大多閒置或雜亂無法使用
大家慢慢發現，有些時候還
是脫離不了“SQL”，因
此…

28. 2727
NoSQL - 慢慢的向SQL靠攏
• 類似SQL的高階語言出現
━ MongoDB及Cassandra是較傑出的供應商，他們都發明
了類似SQL的高階查詢語言
• 向ACID移動
━ 即使是NoSQL最有名提倡者Jeff Dean(他主要負責
MapReduce、Big table以及大多數的google資料庫產品
供應)他後來也承認ACID其實是一個好作法，而Google最
新的作品也加入了ACID

29. 2828
NoSQL - Summary
• NoSQL
━ 原本提倡者講的是「完全捨棄SQL」
• Not only SQL
━ 承認SQL有某些優點，但仍有所不足
• Not yet SQL
━ 未來應會持續向SQL靠攏，而傳統SQL也會演化成
NewSQL
• 因此現階段NoSQL偏向非重要任務的低階應用，網路產業應是需
求大戶，但這僅是佔市場的一小部分

30. 29
Array DBMS

31. 3030
Array DBMS
還有一塊是資料分析的市場
• Machine Learning
• Data Clustering
• Predictive models
• Recommendation system
• Regressions
• Estimators

32. 3131
Array DBMS
公司 時間 股價
鴻海 201601 90
鴻海 201603 92
鴻海 201606 95
台積電 201601 100
台積電 201603 102
台積電 201606 105
[0] [1] [2]
[0] 90 92 95
[1] 100 102 105
原始資料 Array
• 如果你使用傳統關聯資料庫，因為table無法運算，必須在table及
array間不斷的轉換。
• Oracle GeoRaster、SciDB…等就是在做這件事。

33. 3232
Array DBMS - Summary
• 資料以Array形式儲存
• 分析大規模科學數據的常用技術方案
• 它們看起來完全不像SQL，也有著獨
立的一小塊市場

34. 33
Graph DBMS

35. 3434
Graph DBMS
圖形是由節點、對應關係及屬性所組成，像是Alice和Bob的最短距離？
分隔距離又是多少？有很多個這樣標準的分析是資料科學家想進行的，
你可以建立一個系統注重在圖學上的快速分析，如Neo4j。

36. 3535
Graph DBMS - Summary
• 網絡資料庫最普遍的形式(如FB及Twitter…)
• 著重在人事物的「關係」及圖學上的快速分析
• 傳統關聯式資料庫也可以模仿圖學，但在處理
「關係」數據不佳，它的剛性架構使得添加不
同的連結及關係變得困難

37. 36
Hadoop

38. 3737
Hadoop是什麼？
• Hadoop並不是大數據的同義詞
• Hadoop很擅長進行簡易平行的操作
━ 它是Google一個叫MapReduce程式的開源版本
Data MAP Reduce Output
由各個工作節點
分別執行運算
將各個節點運算的
結果合併

39. 3838
Hadoop結構
高階查詢語言
MapReduce
HDFS
Hadoop經過這麼多年已經演變成一個完整的結構
━ Hive、Pig(類似SQL)
━ 檔案管理系統
這樣的結構可以在任何數量的節點上執行，這個金字塔堆疊的規模無上限，
FB就存在一個巨大的hadoop金字塔堆疊，大約有2500個節點

40. 3939
Hadoop結構的優缺點？
缺點：
• 使用高階語言做複雜計算，會比現代高效能的DW還要慢100倍
• 統計運算也會比Array DBMS慢100倍
優點：
• 簡易的平行運算比其他系統快

41. 4040
Hadoop在FB的運用
• 簡易平行運算<5%
━ 雖然FB是一個非常大的Hadoop使用者，但他們有超過95%
的流量在HIVE複雜運算裡，簡易平行使用率<5%
• 自行建構執行引擎來處理95+%的“SQL”
━ 像Hortonworks(Yahoo離職員工創立) and Facebook，為
了執行95+%的非簡易平行運算，他們發明了類似現代高效
能的DW，使用類似Hive的高階查詢語言接在HDFS文檔資
料上，捨棄了MapReduce中間層
• 他們快速地朝HIVE靠近，與資料倉儲市場相競爭
━ 因此資料倉儲市場也開放HIVE查詢

42. 4141
Hadoop - Summary
• 未來大概只會有5%的小市場使用簡易平行應用
• 另外95%中有著類似HIVE架構的大市場
• 只有簡易平行運算適合用Hadoop，其他計算
都會比其他系統慢

43. 42
Summary

44. 4343
總結
 「大象」 – 現階段市場佔比仍高
━ 如果你不在乎效能可以繼續使用DB2、Oracle、SQL…等
 DW - 未來將會是Column-store市場導向
 OLTP - 將會是In-Memory市場
 Everything Else
• Array and Graph DBMS可能不會獲得很大的發展推動力
━ 特殊需求市場較小，但起碼我們知道在什麼情況下使用它們是最好的
• NoSQL將受到低階應用的歡迎
━ 尤其是文檔管理或網路應用這些不用用到ACID原則
• Hadoop結構有95%不使用MapReduce
━ 如果你所使用的系統都是在做簡易平行運算，你可以繼續運行，否則
擴大規模時你會遇到阻礙，不得不換到類似HIVE、SQL現代倉儲系統

45. 44
END