找源碼的網(wǎng)站數(shù)字營銷服務(wù)商seo
數(shù)據(jù)存儲(chǔ)模型
?專欄內(nèi)容:
- postgresql內(nèi)核源碼分析
- 手寫數(shù)據(jù)庫toadb
- 并發(fā)編程
- toadb開源庫
個(gè)人主頁:我的主頁
座右銘:天行健,君子以自強(qiáng)不息;地勢坤,君子以厚德載物.
概述
在數(shù)據(jù)庫的發(fā)展過程中,關(guān)系型數(shù)據(jù)庫是一個(gè)里程碑式的階段,現(xiàn)在關(guān)系型數(shù)據(jù)仍然占據(jù)著重要地位。
在關(guān)系型數(shù)據(jù)中,每張表都是一個(gè)關(guān)系,每行數(shù)據(jù)就是關(guān)系的一條記錄,在存儲(chǔ)時(shí)每行數(shù)據(jù)存儲(chǔ)在連續(xù)的位置,行與行也是連續(xù)存放;
這樣方便一次能拿到一整條記錄。
處理業(yè)務(wù)類型
隨著互聯(lián)網(wǎng)的興起,存儲(chǔ)容量的提升和計(jì)算能力的飛越,我們的生活中不斷增加了越來越多的被智能設(shè)備,產(chǎn)生了無盡的信息。
這樣的信息規(guī)模已經(jīng)超越了某一單體的能力限制,它們被不斷分類,對于數(shù)據(jù)庫處理模型,常常分為:
- 在線事務(wù)處理模型(OLTP), 主要以事務(wù)一致性,關(guān)系型數(shù)據(jù)為主;
- 在線分析處理模型(OLAP), 主要以分析統(tǒng)計(jì)為主,更多的是從大量數(shù)據(jù)中提取某幾個(gè)維度的數(shù)據(jù);
但是這樣的劃分,還遠(yuǎn)遠(yuǎn)不能滿足信息爆炸帶來的需求,它不是非黑即白的界線明晰的分類,還有大量同時(shí)存在OLTP和OLAP的特點(diǎn)的數(shù)據(jù)和業(yè)務(wù),此時(shí)就需要一種混合性數(shù)據(jù)庫存儲(chǔ)模型。
數(shù)據(jù)存儲(chǔ)模型原理
是什么
通過SQL插入的數(shù)據(jù),在數(shù)據(jù)庫中實(shí)際也是要存到磁盤上的,此時(shí)還要考慮我們寫入的效率,讀取的效率,如何產(chǎn)生的IO次數(shù)更少,那以什么格式組織這些數(shù)據(jù),才能達(dá)到這樣的目標(biāo)呢?
我們使用的文件系統(tǒng),都是以塊為單位進(jìn)行讀寫物理存儲(chǔ)設(shè)備,常用的塊大小有2k, 4k等;那么數(shù)據(jù)庫為了提升性能,也選擇以塊為單位來組織數(shù)據(jù),每次按塊進(jìn)行讀寫數(shù)據(jù)文件。
每個(gè)數(shù)據(jù)塊內(nèi)又分為:塊頭信息域,數(shù)據(jù)域的起始偏移,數(shù)據(jù)域,在數(shù)據(jù)域中按邏輯表的行進(jìn)行連續(xù)存儲(chǔ)。當(dāng)然行數(shù)據(jù),又分為定長或變長兩種不同的組織方式;定長,就是每種數(shù)據(jù)類型固定了長度,這樣一行數(shù)據(jù)的長度也是確定的;變長類型,就是像字符,文本等長度是可變的,那么存儲(chǔ)時(shí)需要記錄長度。
它們最大的區(qū)別在于更新時(shí),定長是可以直接覆蓋更新的,而變長就需要追加更新。
為什么存儲(chǔ)模型這么重要
因?yàn)槲覀兊拇鎯?chǔ)到數(shù)據(jù)庫中的數(shù)據(jù)都是持久化到磁盤中,當(dāng)我們查詢時(shí),再從磁盤中讀出,
雖然我們數(shù)據(jù)庫和操作系統(tǒng)層面都已經(jīng)做了緩存,當(dāng)數(shù)據(jù)量大時(shí)還是會(huì)產(chǎn)生大量的磁盤IO,而且數(shù)據(jù)庫大多數(shù)情況下都是隨機(jī)訪問,緩存并不保證全部命中。相較與內(nèi)存速度來講,磁盤速度是極底的,但是內(nèi)存往往是有限的,所以存儲(chǔ)模型至關(guān)重要,通過將隨機(jī)寫轉(zhuǎn)換為順序?qū)?#xff0c;少的IO就可以精確找到數(shù)據(jù),減少遍歷,這些都可以做到減少IO次數(shù),提升性能。
數(shù)據(jù)存儲(chǔ)模型類型
NSM模型
故名思義,就是按行數(shù)據(jù)排列的數(shù)組形式, 數(shù)據(jù)的物理結(jié)構(gòu)和他們的邏輯結(jié)構(gòu)是一樣的,也就是我們常說的行存儲(chǔ)模型,這也是大多數(shù)關(guān)系型數(shù)據(jù)庫采用的存儲(chǔ)模型。
物理存儲(chǔ)結(jié)構(gòu)
磁盤是由一個(gè)一個(gè)數(shù)據(jù)塊組成的,因此連續(xù)的數(shù)據(jù)也分在了連續(xù)的數(shù)據(jù)塊。
每個(gè)數(shù)據(jù)塊中又分塊頭信息,記錄塊中數(shù)據(jù)的起始偏移,每行數(shù)據(jù)分為 行的數(shù)據(jù)偏移item,從塊頭后面連續(xù)存儲(chǔ), 以及真正的行數(shù)據(jù),它從塊的末尾開始向頭部方向連續(xù)存儲(chǔ),這是為了方便空閑空間的管理。表數(shù)據(jù)與物理存儲(chǔ)結(jié)構(gòu)對應(yīng) 如下圖所示 :
應(yīng)用場景
- 它的優(yōu)勢在于對關(guān)聯(lián)數(shù)據(jù)的查詢非???#xff0c;比如根據(jù)身份證號就可以一次讀出姓名,住址等一系列信息。
在此基礎(chǔ)上對于復(fù)雜的嵌套join就非常有優(yōu)勢,因?yàn)樗母髁袛?shù)據(jù)都在一起。
不適合場景
- 對于只查找部分列屬性數(shù)據(jù)的業(yè)務(wù),就會(huì)增加IO的成本,它需要全行數(shù)據(jù)的讀出。對于按3NF設(shè)計(jì),還是一張大寬表,都避免不了緩存效率的降低。
DSM模型
分解的存儲(chǔ)模型,也就是將一行中的各字段存儲(chǔ)到不同的數(shù)據(jù)單元中,當(dāng)需要某列數(shù)據(jù)時(shí),只從磁盤加載部分?jǐn)?shù)據(jù),如果需要整行數(shù)據(jù),那就加載全量數(shù)據(jù),然后進(jìn)行行組裝。
可以是每一列都分別存儲(chǔ),也可以根據(jù)業(yè)務(wù)需要不規(guī)則的劃分,比如有三列經(jīng)常會(huì)相時(shí)查詢,那這三列可以一起存儲(chǔ),剩余的列分別存儲(chǔ)。
物理存儲(chǔ)結(jié)構(gòu)
常見的格式有:
- PAX
- RCFile(record columnar file)
- Apache ORC
- Parquet (An Open Columnar Storage for Hadoop)
它們中更多偏向分析型列式存儲(chǔ),可以處理大量的時(shí)序,流式數(shù)據(jù),也有一些偏向于行列的混合型,每種格式都有成熟的產(chǎn)品應(yīng)用。
應(yīng)用場景
它們的場景更多偏向分析型,如hdoop系列的,使用ORC, Parquet。
混合型數(shù)據(jù)存儲(chǔ)模型
為了綜合以上NSM和DSM各自的優(yōu)勢,互補(bǔ)長短,目前一些數(shù)據(jù)庫已經(jīng)采用了一些混合的存儲(chǔ)模型。
常見混合模型實(shí)踐
- 數(shù)據(jù)冗余型
在存儲(chǔ)數(shù)據(jù)時(shí),干脆兩種格式同時(shí)進(jìn)行存儲(chǔ),一種按行進(jìn)行存儲(chǔ),一種按列分別存儲(chǔ),這樣避免了轉(zhuǎn)換帶的復(fù)雜度,用空間來換取性能;在優(yōu)化引擎中可以選擇更適合的路徑;
- 數(shù)據(jù)轉(zhuǎn)換型
因?yàn)樾写姹仨殠鞩O的放大,也以實(shí)際存儲(chǔ)采用列式存儲(chǔ),在使用時(shí)進(jìn)行組裝成邏輯行數(shù)據(jù);這種模型的難點(diǎn)在于,如何準(zhǔn)確的找到邏輯行中的各字段,大多都采用PAX中提到的分組的方式。
難點(diǎn)
在大數(shù)據(jù)處理中,已經(jīng)不局限于關(guān)系型數(shù)據(jù),更多的是非關(guān)系型,如文本,json數(shù)據(jù),如何將它們轉(zhuǎn)換成列數(shù)據(jù),可以快速查找,這將是混合型存儲(chǔ)模型面臨的一項(xiàng)挑戰(zhàn)。
最近興起的向量數(shù)據(jù)量,向量與大模型維度是對應(yīng)的,底層數(shù)據(jù)庫存儲(chǔ)就需要將各類型數(shù)據(jù)進(jìn)行分別存儲(chǔ)。
結(jié)尾
非常感謝大家的支持,在瀏覽的同時(shí)別忘了留下您寶貴的評論,如果覺得值得鼓勵(lì),請點(diǎn)贊,收藏,我會(huì)更加努力!
作者郵箱:study@senllang.onaliyun.com
如有錯(cuò)誤或者疏漏歡迎指出,互相學(xué)習(xí)。
注:未經(jīng)同意,不得轉(zhuǎn)載!