Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a 架構設計-資料存取的選擇
Similar a 架構設計-資料存取的選擇 (20)
Más de 國昭 張
架構設計-資料存取的選擇
- 2. 大綱 • 架構設計的個人想法 • 架構設計演化的原因 • 關聯式資料庫的喜與悲 • CAP理論 • NoSQL的掘起 • NoSQL分類 • 混合式資料存取系統 • RDBMS的逆襲
- 3. 架構設計的個人想法 • 為什麼我會想要架構設計 • 原因 • 過程 • 挫折 • 轉變 • 想法 • 架構設計給我的感受 • 合理的約束
- 5. 避免脫序- 合理的約束 • 車軌是火車的約束 • 車軌帶來了: • 摩擦力 • 穩定
- 6. 架構設計的囧境 • 很多時候架構設計需要考量的不止是技術方面,還有管理方面: • 沒人瞭解你設計的架構 • 新人上手難度 • 死亡時間的壓力 • 市場壓力
- 8. 架構設計的意義是什麼
- 9. 回到設計的意義 • 內顯- • 設計是用來解決特定問題的 • 外顯- • 設計是意圖的表達
- 12. 品質屬性之間的矛盾
- 14. 又再度分析癱瘓
- 15. 再回歸原點思考系統當下 • 系統會隨著專案的進行的而改變,要隨時重新分析系統的風險。 • 某些風險會隨著時間消失或是重現。 • 設立一個CheckPoint,重新回顧和思考系統當下的風險
- 17. 關聯式資料庫的喜與悲 • 關聯式資料庫為保障資料的一致性,採用鎖的方式處理。 • 關聯式資料庫因為產品化的關係,放了很多你不一定需要的模組。 • 關聯式資料庫有擴充上的瓶頸。
- 18. ACID的回顧 • 原子性(Atomic): 一個交易中所有的操作,不是全部完成就是全部取 消。 • 一致性(Consistency): 交易一旦允諾(Commit),則所有Client的資料會 是相同。 • 隔離性(Isolation): 多個交易同時執行時,彼此不會互相干擾。 • 持久性(Durability): 交易完成後,異動過的資料不會消失。
- 19. 要想達到ACID,得付出多少?
- 20. 衍生的問題 • 鎖不止消耗資源,還帶來死結。 • 當系統規模需要擴充的時候,鎖更是一個絆腳石。 • 當系統ScaleUp的時候,鎖會讓CPU的能量無法發揮
- 21. CAP理論 • 在CAP理論中,強調不會出 現 • 在出現網路實體分裂的狀 態下,資料仍能保持一致性 且系統仍具可用性 • CAP理論大多描述三者取 二,這是因為當網路實體分 裂的時候,必需要從A或C中 犧牲其中一個。 • 但….網路實體分裂又不是 每天都會,有必要考慮這個 而放棄C和A其中之一嗎? 一致性 每個用戶 總是 看到同樣的資料 A C P 分區容忍 縱使實體網路 遭到分割系統 依然能夠運作 可用性 每個用戶 總是 隨時可讀可寫 AP Dynamo Vodemort Tokyo Cabinet KAI Cassandra SimpleDB CouchDB Riak CP BigTable Hypertable HBase MongoDb Terrastore Scalaris Berkerley DB MemcacheDB Redis CA RDBMS (SQL Server, MySQL..) Aster Data Greenplum Vertica
- 22. CAP理論的反思 • 若分區不常出現,那麼CA就可以保持住,一旦P發生時系統再去犧牲 C和A中其中一個。若要做到這個則需要: • 未發生P時,系統運行時要保持CA • 偵測P是否發生 • 當P發生時限制某些操作,並著手啟動恢復機制 • 恢復後一致化每個分區的資料 分區恢復 進入分區模式 狀態: S2 狀態: S1狀態: S 狀態: S’ 發生分區 分區結束
- 23. 最終一致性 • 關聯式資料庫選擇CA是因為過去時空因素,具超大型跨洲際系統並 不多,但隨著資訊的發展,跨洲際系統已經是常態了。 • 關聯式資料庫也有提供許多P方面的機制(但是Lic的費用太貴了..) • NoSQL在CAP的選擇中多半是選擇AP而選擇性的犧牲掉C。 • 其實NoSQL並非是直接地犧牲掉C,而是讓C晚一點發生,它們通常稱 之為- 最終一致性。
- 25. NoSQL的特性 • 執行在一堆便宜的機器上。 • 降低效能瓶頸 • 適量的功能模組 • 開放原始碼 • SchemaLess
- 26. NoSQL的分類 儲存類型 NoSQL產品 特性 Document MongoDb Document儲存一般會使 用類似於Json格式,如此 就可以針對某些欄位建 立索引 欄(Column) Hbase,Cassandra,Hyperta ble 依欄位儲存,方便將儲存 的內容結構化(壓縮) 圖形 Neo4J,FlockDB 用於社群系統的實體之 間的關係處理 鍵值組 Redis,Tokyo Cabinet 透過鍵,快速檢索到值;值 沒有特定格式
- 27. 聚合導向 • 定義: 一組相關的物件,被視為一個整體來操作。 • NoSQL中的鍵值對/Document/欄儲存 這三種都是屬於聚合導向的 NoSQL資料庫。 • 採用聚合的好處,就是當處在分散式的環境中,可以依資料特性放 置到同一台機器上,藉此減少通訊成本。(不需要考慮資料表之間 的關聯) • NoSQL中聚合導向類型的資料庫,雖然不允許跨聚合結構進行交易 控制,但可以從應用程式開發的角度去思考,如何以聚合結構來處 理交易問題。
- 29. MongoDb • 2007年10gen公司想開發一個PaaS的雲端平台,但開發人員只對他 們的資料庫有興趣,後來抽出來成為MongoDb。 • MongoDb是以C++撰寫,採用GNU_AGPL方式授權。 • 2009年11月推出1.0版,其後每三個月改版一次,目前穩定版本是 2.4.10。 • 是一種以Document-Oriented的資料庫。 • 適合Web環境。
- 30. MongoDb的資料結構 • MongoDb的資料庫結構如下: • DataBase • Collection: 類似於RDBMS中的Table • Document: 類似於RDBMS中的一筆資料 • Field: 類似於RDBMS中的欄 • 一個Database可以擁有好幾個Collection,一個Collection可以有好幾 筆Document。
- 31. MongoDb的前題假設 • 假設有足夠大的硬碟空間。 • 記憶體足夠放入所有的熱資料。 • 系統是64位元。 • 系統採用Little-Endian。 • 多台提供給MongoDb使用的機器。 • 允許安全性不高的環境。
- 32. MongoDb的HA • MongoDb提供兩種ScaleOut的機制: • Replica • Sharding • Replica採用主從式叢集架構,資料的儲存都由主節點來提供服務,而 從節點則僅供讀取。 • Sharding是資料水平分割技術,設定好分割條件後MongoDb會自動 將資料進行分割/移轉/合併等工作。
- 33. MongoDb的WriteConcern/ReadPrefer • MongoDb支援ScaleOut,但是這也引發了資料一致性的議題: • 寫入到所有節點才算成功? • 讀到的資料一定要最新? • MongoDb在寫入方面提供Write Concern機制,讓應用程式寫入時可 以決定寫入的深度到什麼程度。 • 在讀取方面,基於效能考量MongoDb提供讀取的機制稱之為Read Prefer;應用程式可以決定讀取的資料是來自最新的主節點或是某 個最靠近的從節點。
- 34. MongoDb的適用與不適用場景 • 適用: • 網站登入/出 • 快取(Cache) • 大型檔案的儲存(其實不怎麼好…) • ScaleOut • 事件紀錄(Log) • 不適用: • 高交易需求的系統 • BI應用
- 35. Redis • 屬於鍵值對型的資料庫,與Memcached不同的是,它內部擁有豐富 的資料結構,可利用這些資料結構搭配出合適的資料儲存的操作。 • 未避免資源競爭,Redis採用單執行緒處理。 • Redis與Memcached同樣都是記憶體型資料庫,但是Redis提供持久 化(Durability)的機制 • 快照 • Log檔(Append式) • Redis還提供訊息推播的功能,用戶端與訊息發送端可以藉由這個 功能同步訊息,目前在.Net技術中應用最廣泛的當屬SignalR。
- 36. Redis的內部結構 • 由於Redis的誕生是某公司老闆一時氣憤下的產物,當時並沒有想到未來 會有這麼多人使用,故其資料庫系統的設計方面稍嫌薄弱;Redis一個實 體僅提供16個資料庫,並且資料庫以整數命名。 • Redis在設計上其資料結構分為:內/外兩層;其內部資料結構是用來實現 外部資料結構的底層設計,而外部資料結構是供使用者使用的資料結構 亦即值的資料型別。 • Redis提供的資料型別: • 字串 • HashTable • List • Set • 有序Set redisObject 字串 List 有序集合 HashTable 集合 整數 字串 雙端鏈結串列 跳躍表 壓縮串列 字典 整數集合
- 38. Redis的資料復原機制 • Redis提供兩種資料復原機制: • RDB • AOF • RDB是Redis會對有儲存在資料庫中的資料定期快照並儲存在硬碟 中。 • AOF彷彿RDBMS的寫入日誌一般,可設定在什麼條件下觸發寫入硬 碟中;Log中的資料操作是Append,不會有修改或刪除。
- 39. Redis適用與不適用場景 • 適用 • 小型資料的操作(<100k效能最佳) • 快速的資料處理需求 • 快取 • 不適用 • 大型資料操作 • 交易處理(語法錯誤有RollBack效果,語意錯誤則無) • 多CPU環境(浪費資源)
- 40. Cassandra • 由Facebook提供,交遞給Apache協會,但是自家用的是另一個版本的 Cassandra。 • 以Amazon專有的Dynamo為基礎,結合Google BigTable的欄儲存型 NoSQL。 • 一度曾是欄儲存型NoSQL的霸主,後來在Twitter甚至是Facebook棄 用之後衰敗,後由DataStax公司重啟V2.0後重登寶座。
- 41. Cassandra的資料結構 • 基本儲存單元: 行,每個行都是一個名值對。名也作為鍵使用。 • 每個行都有一個時間戳記,可以控制值的生命週期或寫入沖突。 列1列鍵 1 列 名稱1: 值1 名稱2: 值2 列2
- 42. Cassandra的內部結構 • 由相似的業務或結構所組成的集合稱之為-欄族(Column Family)。 • 標準欄族 – 欄族內部的名值對都只有一層。 • 超欄族- 欄族內部的名值對呈現巢狀。 名稱1: 值1 列1 名稱2: 值2 列2列鍵 2 名稱1: 值1 列1 名稱2: 值2 列2列鍵 1 列 列 列族 { “pramod-sadalage” : { firstnName : “Pramod”, lastName : “Sadalage”, lastVisit: “2012/12/12” }, “martin-sadalage” : { firstnName : “Martin”, lastName : “Forler”, lastVisit: “2012/12/12” } }
- 43. Cassandra的資料操作 • 寫入操作: • 先將資料寫入提交日誌(CommitLog) • 再將資料寫入SSTable(i.e. 記憶體型資料表) • 當SSTable中的快取寫入資料庫,此SSTable就無用了,將會被回收。 • 讀取操作: • 讀取資料時,等待過半節點響應 • 節點響應後,回傳時間戳記中最近的資料 • 將最新資料覆寫資料已陳舊的節點 • Cassandra列的操作是原子級別
- 45. Cassandra的適用與不適用場景 • 適用: • 高併發交易環境 • 不適用: • 開發初期,專案查詢模式尚未確立
- 46. Neo4J • 以Java撰寫,兼容ACID的圖型資料庫。 • 核心是一種極快的圖型引擎,針對圖型網絡進行優化。 • 提供REST服務層,可以使用REST的方式操作。 • 大多應用在社交網路的應用上。
- 47. Neo4J的內部結構 • Neo4J利用圖型理論來儲存資料庫,每個節點之間的連線可以放置 屬性來說明兩個節點之間的關係。 • 修改或對現有節點進行修改時都需要啟動交易。 • 若刪除的節點身上仍有連線則刪除會失敗,這是為了保障圖的完整 性。
- 48. 圖資料庫的價值 • 其實圖資料庫檢索關係也可以使用RDBMS來完成,那圖資料庫的價 值在那裡? • 圖資料庫可以從任意一個節點開始,遍覽所有節點,特別是深度大 於1的時候。 • Neo4J具有索引的功能,查詢時會先查詢索引中的資料,而查詢引擎 採用的是Lucene
- 49. Neo4J的叢集 • Neo4J的叢集由主節點負責所有資料的儲存,而後複製給從節點;從 節點僅能做讀取使用。 • Neo4J會盡可能將所有資料放入記憶體中,但若資料量過大則叢集 會發生問題,為避免這個狀況,可在應用程式面處理,將資料依領域 特定知識切割。 北美 路易斯安那 紐約 芝加哥 代理商 供貨商 分銷商 貨倉 供貨商 亞洲 孟買 新加坡 西安 生產 供貨商 分銷商 生產 供貨商 應用程式
- 50. Neo4J適用與不適用場景 • 適用: • 關係型資料。 • 路徑規劃 • 推薦引擎 • 不適用: • 高併發交易
- 54. ColumnStore Index • 開發專案名稱: Apollo • 讓超大量資料能夠有效率的執行彙總操作(Sum,Average…)。 • 在SQL Server 2012的ColumnStore Index中,必需設定資料表為唯讀 才能使用,但是SQL Server 2014之後若將ColumnStoreIndex建在叢集 索引上,則可以對資料進行異動。 • 以Column為導向的儲存,因為是相同的資料型別,所以可以進行高 壓縮,這讓資料的容量和存取的效率可以大幅的提升。
- 56. CCI允許資料異動的秘密 • 資料新增: • 新資料會直接插入DeltaStore資料表,當DeltaStore資料表Row的筆數超過之 後會由背景Job將其轉成Row Group並轉變成ColumnStore。 • 資料修改: • 若欲修改資料在ColumnStore中,則標註此筆資料已刪除,並且新增一筆資 料到DeltaStore資料表中;反之,則直接修改DeltaStore中的資料。 • 資料刪除: • 若欲刪除資料在ColumnStore中,則標註此筆資料已刪除;反之,則是直接刪 除DeltaStore中的資料。
- 57. In-Memory Table • 模組名稱: Hekaton • 其用意在於提升資料表存取的速度;放棄傳統採用悲觀鎖定的方式 而改用樂觀版本鎖藉此提高效能。 • 在使用上建議搭配Native式的預存程序;這種預存程序經過特殊優 化,可讓硬體指令碼數量減少藉此提高CPU使用率。 • Hekaton的Durability是可選的,若採用Durability則因其需要進行Log 而會降低效能。 • 由於是In-Memory,因此,當記憶體不足的時候並不會Crash而是進入 唯讀狀態。
- 58. Hekaton的概觀
- 59. 選擇癱瘓?