大數據“復活”記
811
2025-04-02
1,數據庫介紹
前言
在當今云化率越來越高的時代,以華為云HCIA數據庫認證為路徑系統學習數據庫知識,并結合傳統數據庫來得出新的思考和觀點,取得進步。
數據庫從誕生之日起至今已近60年,從早期單純地對數據文件的保存和處理,發展出以數據建模和數據庫管理系統核心技術為主的一門內容豐富的學科,成為現代計算機應用系統的基礎和核心.伴隨著互聯網、大數據、人工智能等技術的蓬勃興起,數據庫技術和產品更是百花齊放,帶動了一個巨大的軟件產業的發展。
本章主要講述數據庫的基本概念,數據庫技術的發展歷史,關系型數據庫的關系演進以及關系型數據庫的主流應用場景。
1.1,數據庫技術概述
數據庫技術
數據庫技術是數據管理的有效技術,研究如何對數據進行科學管理,從而為人們提供可共享的、安全的、可靠的數據。數據庫技術包括數據、數據庫、數據庫系統、數據庫管理系統。
數據(Data)
早期的計算機系統主要用于科學計算,處理的數據是數值型數據:
整數:1,2,3,4,5…
浮點數:3.14,100.34,-123.4
現代計算機系統的數據概念是廣義的:
數字、文字、圖形、圖像、音頻、視頻等。
描述事務的符號記錄稱為數據。
數據除了表現形式之外,還有語義。
數據的含義稱為數據的語義。
記錄
記錄是在計算機中表示和存儲數據的一種格式或一種方法。
例如:
數據庫(Database,DB)
數據庫是存放數據的倉庫,是大量數據的集合。
存放在數據庫中數據的特點
永久存儲
有組織
可共享
數據庫管理系統(DBMS)
數據庫管理系統是一個能夠科學地組織和存儲數據,高效地獲取和維護數據的系統軟件,是位于用戶與操作系統之間的數據管理軟件,其主要功能包括:
數據定義功能;
數據組織、存儲和管理功能;
數據操縱功能;
數據庫的事務管理和運行管理功能;
數據庫的建立和維護功能;
與其他軟件系統的通信功能等。
數據庫系統(Database System,DBS)
數據庫是由數據庫、數據庫管理系統(及其應用開發工具)、應用程序和數據庫管理員組成的存儲、管理、處理和維護數據的系統。
思考題
存放在數據庫中的數據的特點是:(永久存儲;有組織;可共享)
屬于數據庫系統這個概念范圍的組成部分有:(數據庫;數據庫管理系統;應用程序)
數據庫應用程序可以不經過數據庫管理系統而直接讀取數據庫文件(錯誤)
1.2,數據庫技術發展史
數據庫技術應數據管理任務的需要而產生。
數據管理的發展
應用需求推動;
軟硬件的飛速發展為基礎;
三個階段:人工管理、文件系統、數據庫系統。
數據管理三個階段比較
數據庫系統優勢
整體數據結構化
數據面向整個系統而不是單個應用,被多個應用共享。
數據的共享性高,冗余度低且易擴充。
數據獨立性高
物理獨立性:應用程序與數據庫中數據的物理存儲是相互獨立的。
邏輯獨立性:應用程序與數據庫的邏輯結構是相互獨立的。
統一管理和控制
數據的安全性保護;
數據的完整性檢查;
并發控制;
數據庫恢復。
數據庫系統發展特點
數據庫系統已經成為計算機信息系統和智能應用系統的核心技術之一和重要基礎。
數據庫系統的發展特點
數據庫的發展集中表現在數據模型的發展上;
與其他計算機技術交叉結合;
面向應用領域發展數據庫新技術。
層次,網狀,關系模型
層次模型
有且只有一個節點沒有雙親,該節點被稱為根節點(root)。
根節點之外的其他節點有且只有一個雙親結點。
網狀模型
允許一個以上的節點無雙親。
一個節點可以有多于一個的雙親。
關系模型(重點)
建立在嚴格的數據概念基礎上。
關系必須是規范化的。
關系的分量必須是一個不可分的數據項。
層次,網狀,關系模型對比
結構化查詢語言 - Structured Query Language
SQL語言
高級的非過程化編程語言,允許用戶在高層數據結構上工作;
不要求用戶指定數據存放方法;
不需要用戶了解具體數據存放方式;
底層結構完全不同的各種關系型數據庫系統可以使用相同的SQL語言作為數據操作和管理的接口。
其他數據模型
面向對象數據模型(Object Oriented Data Model,OO模型)
將語義數據模型和面向對象程序設計方法結合起來,用一系列面向對象核心概念構成模型基礎。
由于面向對象數據庫操作語言過于復雜,沒有得到開發人員認可。
XML數據模型
可擴展標記語言(extensible markup language,簡稱XML),是W3C在1998年指定的一項標準,被作為互聯網信息交換的標準。
XML模型是由若干帶有標簽的節點組成的有向樹,是一種分層自描述模型,具有良好的語義和可擴展性,可以靈活地表示和組織數據,并提供高效的查詢方式,例如XPath,XQuery,關鍵字查詢,子樹匹配等。
RDF數據模型
互聯網的信息沒有統一表達方式,W3C提出資源描述框架(Resource Description Framework,RDF)來描述和注解互聯網資源。
RDF是描述互聯網資源的標記語言,結構為(主語,謂詞,賓語)
主要用于語義網、知識庫的基礎數據模型,是當前知識圖譜技術的基石。
數據管理技術的新挑戰
高度可擴展性和可伸縮性
隨著數據獲取手段的自動化,多樣化和智能化,導致數據量急劇增大。
數據類型多樣和異構處理能力
結構化數據到半結構化/非結構化數據;
文本到圖形圖像,音頻視頻等多媒體數據;
流數據,隊列數據。
數據處理時效性要求
傳感、網絡和通信技術發展對于數據快速流入和處理,實時性方面提出了更高要求。
大數據時代來臨(重點)
傳統關系型數據庫面對海量異構、形式繁雜、高速增長、價值密度低的數據問題遇到全面挑戰。
NoSQL和NewSQL技術順應大數據發展的需要,蓬勃發展。
大數據時代的5V特征
Volume,數量
Variety,多樣性
Value,價值
Velocity,速度
Veracity,真實
大數據時代的管理需求
高可擴展性
高性能
容錯性
高伸縮性
NoSQL技術特點和類型
NoSQL(Not Only SQL)
非關系型、分布式的、不保證滿足ACID特性的一類數據管理系統。
技術特點
對數據進行分區(partitioning),利用大量節點并行處理獲得高性能,同時能夠采用橫向擴展方式(scale out);
降低ACID一致性約束,允許暫時不一致,接受最終一致性。遵循CAP理論和BASE原則;
各數據分區提供備份(一般是三份),應對節點故障,提高系統可用性。
常見的NoSQL數據庫技術
Key-Value,鍵值數據庫
Graph DB,圖數據庫
Column Family,列式數據庫
Document,文檔數據庫
主要NoSQL數據庫簡介
NoSQL并不是為了取代RDBMS
優勢顯著,缺點也明顯
與RDBMS一起構建完整的數據庫生態系統
NewSQL淺談
NewSQL
指追求NoSQL的可擴展性同時能夠支持關系模型(包括ACID特性)的關系型數據庫系統,主要面向OLTP場景。
能夠支持SQL作為主要的使用語言。
NewSQL的分類
采用了新架構重新構建產品
Shared-Nothing,多節點并發控制,分布式處理,利用復制實現容錯,流式控制等技術架構。
Google Spanner,H-Store,VoltDB等。
采用Transparent Sharding中間件技術。
數據分片(sharding)的過程對于用戶來說是透明的(transparent),用戶的應用程序不需要做出變化。
Oracle MySQL Proxy,MariaDB MaxSacle等。
DAAS(Database-as-a-Service,數據庫即服務)。
云服務商提供的數據庫產品,云服務商提供具備NewSQL特性的數據庫產品。
Amazon Aurora,阿里云的Oceanbase,騰訊云的CynosDB。
云數據庫
在全新的時代背景下,商業數據庫因其昂貴、高運維難度以及低擴展性和可用性受到挑戰。在5G+云計算的強力沖擊下,云數據庫的格局已經悄然發生變化。
云數據庫是指被優化或部署到一個虛擬計算環境中的數據庫。
傳統數據庫 VS 云數據庫(1)
Gartner的最新報告(2019年)指出,云將主導數據庫市場的未來,到2022年,75%的數據庫將被部署或遷移至云平臺,只有5%的數據庫會考慮部署在本地。
"易、穩、快、彈、密"是對DBaaS的需求,也是其演進方向。
傳統數據庫 VS 云數據庫(2)
思考題
數據管理的發展歷史上經歷了哪幾個階段?(人工,文件系統,數據庫系統)
允許一個以上的節點無雙親,一個節點可以有多于一個的雙親,這些特性對應哪種數據模型?(網狀模型)
屬于NoSQL數據庫的是:(圖數據庫,文檔數據庫,鍵值數據庫,列分組數據庫)
NoSQL和NewSQL數據庫的出現能夠徹底顛覆和取代原有的關系型數據庫系統。(錯誤)
1.3,關系型數據庫架構演進
數據庫架構發展
隨著業務規模增大,數據庫存儲的數據量和承載的業務壓力也不斷增加,數據庫的架構需要隨之變化,為上層應用提供穩定和高效的數據服務。
單機架構
為了避免應用服務和數據庫服務對資源的競爭,單機架構也從早期的單主機模式發展到數據庫獨立主機模式,把應用和數據服務分開。應用服務可以增加服務器數量,進行負載均衡,增大系統并發能力。
部署集中,運維方便
可擴展性
數據庫單機架構擴展性只有縱向擴展(Scale-up)。通過增加硬件配置來提升性能,但單臺主機的硬件可配置的資源會遇到上線。
存在單點故障
擴容的時候往往需要停機擴容,服務停止。
硬件故障導致整個服務不可用,甚至數據丟失。
單機會遇到性能瓶頸。
分組架構-主備
數據庫部署在兩臺服務器,其中承擔數據讀寫服務的服務器稱為"主機"。
另外一臺服務器利用數據同步機制把主機的數據復制過來,稱為"備機"。
同一時刻,只有一臺服務對外提供數據服務。
應用不需要針對數據庫故障來增加開發量。
相對單機架構提升了數據容錯性。
資源浪費,主備機同等配置,但長期范圍內基本上資源限制,無法利用。
性能壓力還是集中在單機上,無法解決性能瓶頸問題。
當出現故障時候,主備機切換需要一定的人工干預或者監控。
分組架構-主從
部署模式和主備機模式相似,備機(Backup)上升為從機(Slave),對外提供一定的數據服務。
通過讀寫分離方式分散壓力:
寫入、修改、刪除操作,在寫庫(主機)上完成;
把查詢請求,分配到讀庫(從機)。
提升資源利用率,適合讀多寫少的應用場景。
在大并發讀的使用場景,可以使用負載均衡在多個從機間進行平衡。
從機的擴展性比較靈活,擴容操作不會影響到業務進行。
延遲問題,數據同步到從機數據庫時會有延遲,所以應用必須能夠容忍短暫的不一致性。對于一致性要求非常高的場景是不適合的。
寫操作的性能壓力還是集中在主機上。
主機出現故障,需要實現主從切換,人工干預需要響應時間,自動切換復雜度較高。
分組架構-多主
數據庫服務器互為主從,同時對外提供完整的數據服務。
資源利用率較高的同時降低了單點故障的風險。
雙主機都接受寫數據,要實現數據雙向同步。雙向復制同樣會帶來延遲問題,極端情況下有可能數據丟失。
數據庫數量增加會導致數據同步問題變得極為復雜,實際應用中多見雙機模式。
共享存儲多活架構
一種特殊的多主架構
數據庫服務器共享數據存儲,而多個服務器實現負載均衡。
多個計算服務器提供高可用服務,提供了高級別的可用性。可伸縮性,避免了服務器集群的單點故障問題。
比較方便的橫向擴展能夠增加整體系統并行處理能力。
實現技術難度大
當存儲器接口帶寬達到飽和的時候,增加節點并不能獲得更高的性能,存儲IO容易成為整個系統的性能瓶頸。
分片(Sharding)架構
把數據分散在多個節點上的分片方案,每一個分片包括數據庫的一部分,稱為一個shard。
多個節點都擁有相同的數據庫架構,但不同分片的數據之間沒有交集,所有分區數據的并集構成數據總體。
常見的分片算法有:根據列表值,范圍取值和Hash值進行數據分片。
數據分散在集群內的各個節點上,所有節點可以獨立性工作。
無共享(Shard-Nothing)架構
集群中每一個節點(處理單元)都完全擁有自己獨立的CPU/內存/存儲,不存在共享資源。
各節點(處理單元)處理自己本地的數據,處理結果可以向上層匯總或者通過通信協議在節點間流轉。
節點是相互獨立的,擴展能力強。整個集群擁有強大的并行處理能力。
MPP架構(Massively Parallel Processing)
MPP是將任務并行的分散到多個服務器和節點上,在每個節點上計算完成后,將各自部分的結果匯總在一起得到最終的結果。
任務并行執行,分布式計算。
無共享Master:Vertica,Teradata。
共享Master:Greenplum,Netezza。
所有節點對等;
可以通過任意節點查詢或加載數據;
不存在性能瓶頸和單點風險。
數據庫架構特點對比
思考題:
主備架構可以通過讀寫分離方式來提高整體的讀寫并發能力。(錯誤,主從架構才能通過實現讀寫分離方式)
哪種數據庫架構具有良好的線性擴展能力?(Shard-Nothing架構)
分片架構的特點就是通過一定的算法把數據分散在集群的各個數據庫節點上,利用集群內服務器數量的優勢進行并行計算(正確)
1.4,關系型數據庫主流應用場景
聯機事務處理(OnLine Transaction Processing)
面向基本的,日常的事務處理,例如銀行儲蓄業務的存取交易,轉賬交易等。
大吞吐量:大量的短在線事務(插入,更新,刪除),非常快速的查詢處理。
高并發,(準)實時響應
零售系統
金融交易系統
火車票銷售系統
秒殺活動
聯機分析系統(OnLine Analytical Processing)
聯機分析處理的概念最早是E.F.Codd于1993年相對于OLTP系統而提出的。
是指對數據的查詢和分析操作,通常對大量的歷史數據查詢和分析。涉及到的歷史周期比較長,數據量大,在不同層級上的匯總,聚合操作使得事務處理操作比較復雜。
主要面向側重于復雜查詢,回答一些"戰略性"的問題。
數據處理方面聚焦于數據的聚合,匯總,分組計算,窗口計算等"分析型"數據加工和操作。
從多維度去使用和分析數據。
報表系統,CRM系統。
金融風險預測預警系統,反洗錢系統。
數據集市,數據倉庫。
OLTP和OLAP對比分析
數據庫性能衡量指標
職責是指定商務應用基準測試標準(Benchmark)的規范、性能和價格度量,并管理測試結果的發布。
制定的是標準規范而不是代碼,任何廠家依據規范最優地構造自己系統進行評測。
推出了很多基準測試標準,其中針對OLTP和OLAP分別有兩個規范。
面向OLTP系統,主要包括兩個指標
流量指標:tpmC(tpm-transactions per minute,每分鐘測試系統處理的事務數量)
性價比指標:Price(測試系統價格)/tpmC
面向OLAP類系統
流量指標:qphH-Query per hour,每小時處理的復雜查詢數量。
需要考慮測試數據集合大小,分為不同的測試數據集,指定了22個查詢語句,可以根據產品微調。
測試場景:數據加載,Power能力測試和Throughput測試。
思考題:
衡量OLTP系統的測試指標包括:(tpmC,Price/tmpC)
OLAP系統適用下面哪些場景?(報表系統,數據倉庫)
OLAP系統能夠對大量數據進行分析處理,所以同樣能夠滿足OLTP對于小數據量處理的性能要求。(錯誤)
數據庫
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。
版權聲明:本文內容由網絡用戶投稿,版權歸原作者所有,本站不擁有其著作權,亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容,請聯系我們jiasou666@gmail.com 處理,核實后本網站將在24小時內刪除侵權內容。