一種PostgreSQL塊的制作方法
【技術(shù)領(lǐng)域】
[0001 ]本發(fā)明涉及一種PostgreSQL數(shù)據(jù)庫存儲(chǔ)設(shè)備，尤其涉及一種用于存儲(chǔ)PostgreSQL 數(shù)據(jù)庫中PostgreSQL數(shù)據(jù)表的PostgreSQL塊。
【背景技術(shù)】
[0002] 隨著互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)和物聯(lián)網(wǎng)的發(fā)展，我們迎來了一個(gè)海量數(shù)據(jù)的時(shí)代，而數(shù) 據(jù)庫內(nèi)保存的數(shù)據(jù)也越來越多，而我們需要的查詢時(shí)間反而要越來越小?，F(xiàn)在的眾多應(yīng)用 場景都需要后臺(tái)的存儲(chǔ)具有高并發(fā)，高容量，高響應(yīng)。高速的入庫需求迫使我們不得不放棄 實(shí)時(shí)索引，而大數(shù)據(jù)量的數(shù)據(jù)掃描又被存儲(chǔ)端的10所限制?，F(xiàn)在的PostgreSQL數(shù)據(jù)庫系統(tǒng) 中，高并發(fā)的多數(shù)據(jù)庫掃描需要碰到基本都是隨機(jī)讀，而與此同時(shí)，普通磁盤的吞吐量已經(jīng) 不能滿足需求。
[0003] 為了適應(yīng)大數(shù)據(jù)量的應(yīng)用場景，官方推出的PostgreSQL-XC、PostgreSQL-XL這兩 個(gè)MPP數(shù)據(jù)庫還沒有成熟，而且還存在很多安全性問題。而傳統(tǒng)的提速方案僅僅是利用集中 式存儲(chǔ)的高1/〇(輸入/輸出）來在一定程度上提高整個(gè)系統(tǒng)的。但這種提升依舊存在很大的 資源浪費(fèi)。
[0004] 如圖1所示，原有的PostgreSQL數(shù)據(jù)庫系統(tǒng)底層存儲(chǔ)架構(gòu)在文件系統(tǒng)上，從表到磁 盤需要經(jīng)過:表空間，文件系統(tǒng)，邏輯卷、磁盤這四層最終才會(huì)寫入到物理磁盤內(nèi)。
[0005] 這樣的架構(gòu)首先會(huì)使得磁盤的1/0形成衰減。最終的磁盤1/0利用率只能達(dá)到80% 左右，甚至更低。其次，當(dāng)數(shù)據(jù)庫表存在大量小表的情況下，勢必會(huì)增加文件系統(tǒng)的壓力。而 且對(duì)于數(shù)據(jù)庫操作而言，表的寫入讀出都較為隨機(jī)，極容易造成磁盤碎片，而大量的隨機(jī)讀 寫，也必將會(huì)使得整個(gè)數(shù)據(jù)的讀寫性能下降。對(duì)于小數(shù)據(jù)量的數(shù)據(jù)庫而言，現(xiàn)有的缺點(diǎn)也許 不明顯。但現(xiàn)在更多的使用場景是大數(shù)據(jù)量、高并發(fā)、高1/0。這些使用場景下，這些缺點(diǎn)將 會(huì)大大影響數(shù)據(jù)庫性能。此外在不同的操作系統(tǒng)迀移中也需要極復(fù)雜的數(shù)據(jù)庫迀移操作。
[0006] 普通磁盤的1/0速度較低，傳統(tǒng)的解決方法是使用集中式存儲(chǔ)（即磁盤陣列）。這種 方式只是簡單的提高磁盤的1/0速度，而且成本極高，具有一定的局限性。
[0007] 如圖2和圖3所示，PostgreSQL數(shù)據(jù)庫系統(tǒng)現(xiàn)有的后臺(tái)存儲(chǔ)架構(gòu)：
[0008] 數(shù)據(jù)庫的數(shù)據(jù)操作每條記錄都有幾個(gè)主要標(biāo)識(shí)。表1D、記錄所在black id、文件類 型、行記錄對(duì)應(yīng)的標(biāo)識(shí)?，F(xiàn)有的PostgreSQL數(shù)據(jù)庫系統(tǒng)讀寫表操作需要：
[0009] a根據(jù)表1D查找到這個(gè)表的表空間，然后定位到文件系統(tǒng)中表空間的位置。
[0010] b根據(jù)文件類型要獲取到指定的表文件。一般一個(gè)表會(huì)包含3種類型的文件。
[0011 ] fsm文件:其中存放了數(shù)據(jù)表文件中空閑空間的信息。
[0012] vm文件:標(biāo)記了數(shù)據(jù)表文件中哪些文件塊沒有失效的元組。
[0013]表數(shù)據(jù)文件:此文件主要用戶存儲(chǔ)數(shù)據(jù)，但是此文件大小會(huì)有一定的限制，普通情 況下會(huì)保存2G，超過2G的文件會(huì)分文件保存。
[0014] c根據(jù)記錄號(hào)以及fsm文件，定位page。
[0015] 而一般的操作系統(tǒng)對(duì)于打開的文件數(shù)會(huì)有限制。PostgreSQL數(shù)據(jù)庫系統(tǒng)內(nèi)部使用 自己的虛擬文件管理來管理文件句柄，來保證能夠同時(shí)打開很多的表。對(duì)于數(shù)據(jù)庫而言可 能同時(shí)存在很多的表，而PostgreSQL數(shù)據(jù)庫系統(tǒng)采用1個(gè)表多個(gè)文件方式來保存數(shù)據(jù)。當(dāng)打 開一個(gè)文件的時(shí)候，會(huì)首先到文件句柄管理中找一下是不是存在已經(jīng)打開的文件句柄。根 據(jù)文件句柄設(shè)定一下offset。
[0016] d從文件中取到對(duì)應(yīng)的page，并取到對(duì)應(yīng)的行。
[0017]根據(jù)記錄的blockid定位到文件，讀取指定大小的塊。而這些記錄就保存在page 內(nèi)。
[0018] 現(xiàn)有技術(shù)中，采用集中式存儲(chǔ)作為數(shù)據(jù)庫后端。
[0019] 1、采用集中式存儲(chǔ)(磁盤陣列等)做為存儲(chǔ)后端。把集中式存儲(chǔ)提供的磁盤掛載到 PostgreSQL數(shù)據(jù)庫系統(tǒng)所安裝的機(jī)器。并根據(jù)不同的操作系統(tǒng)格式化成不同的文件系統(tǒng)。
[0020] 2、把數(shù)據(jù)庫中的數(shù)據(jù)指定到集中式存儲(chǔ)提供的磁盤。
[0021] 此種方法僅僅硬性提高后端的I/O吞吐量，并沒有從原理上提高底層I/O的利用 率。而且就安全性而言，這種方法并沒有對(duì)數(shù)據(jù)做任何層面的保護(hù)，依舊讓數(shù)據(jù)暴露在外。 只能夠在一定程度上實(shí)現(xiàn)數(shù)據(jù)庫系統(tǒng)的提速。但是對(duì)于高安全高性能的需求來說，我們不 能僅僅依靠這種純硬件的加速而忽略軟件本身的優(yōu)化。
[0022]以上是原有的PostgreSQL數(shù)據(jù)庫系統(tǒng)存儲(chǔ)架構(gòu)。以上結(jié)構(gòu)存在以下幾個(gè)缺點(diǎn)：
[0023] 第一、對(duì)磁盤的使用必經(jīng)過文件系統(tǒng)層。
[0024] 就linux系統(tǒng)下較為流行的文件系統(tǒng)而言，采用64位空間來記錄塊數(shù)量和i-節(jié)點(diǎn) 數(shù)量，對(duì)于數(shù)據(jù)庫系統(tǒng)，可能存在及大量的表，每個(gè)表都將可能至少存在3個(gè)以上的文件，導(dǎo) 致一個(gè)文件夾內(nèi)存在極多的文件。
[0025] 文件系統(tǒng)進(jìn)行塊分配時(shí)，基本上都是按照4K一個(gè)塊的模式進(jìn)行分配。同時(shí)我們數(shù) 據(jù)庫申請(qǐng)的時(shí)候都是以8K為單位進(jìn)行申請(qǐng)。也就是說系統(tǒng)分配的塊總是比我們的表的塊要 小。這樣導(dǎo)致的直接問題就是數(shù)據(jù)庫的業(yè)務(wù)塊雜亂的分配到磁盤上。導(dǎo)致的直接問題就是 磁盤尋道時(shí)間長，讀寫速度減慢。
[0026] 假如我們的數(shù)據(jù)庫中存在一個(gè)極大的表，文件系統(tǒng)在處理的時(shí)候效率極其低。例 如，在ext3文件系統(tǒng)中100MB的文件就需要近25600個(gè)數(shù)據(jù)塊。而對(duì)于PostgreSQL數(shù)據(jù)庫系 統(tǒng)而言，達(dá)到或超過GB級(jí)別的表處理會(huì)很常見，而且是隨機(jī)的讀寫。
[0027] 第二、文件系統(tǒng)的擴(kuò)容也非常麻煩。除了已知的極個(gè)別商業(yè)文件系統(tǒng)外，其他的文 件系統(tǒng)擴(kuò)容多會(huì)要求關(guān)閉數(shù)據(jù)庫。
[0028] 第三、數(shù)據(jù)庫在不同的系統(tǒng)之間進(jìn)行迀移及其復(fù)雜，對(duì)操作人員專業(yè)知識(shí)要求較 尚。
[0029] 第四、數(shù)據(jù)庫數(shù)據(jù)文件直接暴露在操作系統(tǒng)中，數(shù)據(jù)存在安全隱患，數(shù)據(jù)安全也就 得不到保證，對(duì)于一些對(duì)安全級(jí)別要求較高的使用環(huán)境而言是個(gè)極大的安全漏洞。

【發(fā)明內(nèi)容】

[0030]本發(fā)明要解決的技術(shù)問題是提供一種PostgreSQL塊，該P(yáng)ostgreSQL塊的查詢速 度、讀寫速度能夠有極大提升。
[0031 ]為了解決上述技術(shù)問題，本發(fā)明的PostgreSQL塊是分配給PostgreSQL數(shù)據(jù)庫系統(tǒng) 中數(shù)據(jù)表的最小單位，所述PostgreSQL塊的存儲(chǔ)容量大于4KB。
[0032]所述PostgreSQL塊的存儲(chǔ)容量是8KB的正整數(shù)倍。
[0033]所述PostgreSQL塊的存儲(chǔ)容量是8KB之2的自然數(shù)次方倍。
[0034] 所述 PostgreSQL 塊的存儲(chǔ)容量是 1MB、2MB、4MB、8MB、16MB、32MB、64MB、128MB、 256MB、512MB或1024MB。
[0035] 一種PostgreSQL塊存儲(chǔ)設(shè)備讀寫模塊，所述PostgreSQL塊存儲(chǔ)設(shè)備讀寫模塊是對(duì) PostgreSQL塊存儲(chǔ)設(shè)備中如前面所述的PostgreSQL塊進(jìn)行管理的PostgreSQL塊存儲(chǔ)設(shè)備 讀寫模塊。
[0036]所述PostgreSQL塊存儲(chǔ)設(shè)備讀寫模塊可以架構(gòu)在PostgreSQL數(shù)據(jù)庫系統(tǒng)上。
[0037]所述PostgreSQL塊存儲(chǔ)設(shè)備讀寫模塊通過PostgreSQL塊-數(shù)據(jù)表之間的映射關(guān)系 表和空閑PostgreSQL塊表對(duì)PostgreSQL塊存儲(chǔ)設(shè)備中的PostgreSQL塊進(jìn)行管理。
[0038] 所述PostgreSQL塊-數(shù)據(jù)表之間的映射關(guān)系表包括字段Re If ilenode、 Re 1 tab 1 espace、Forknum、Blocki d、B1 ockno，所述空閑PostgreSQL 塊表包括字段 Blockid、 Isfree、Dev〇
[0039]所述PostgreSQL塊存儲(chǔ)設(shè)備讀寫模塊，具有以下子模塊：
[0040] 分配PostgreSQL塊的子模塊，
[0041]回收PostgreSQL塊的子模塊，
[0042] 定位PostgreSQL塊的子模塊，
[0043]讀出Po s t gr e SQL塊中數(shù)據(jù)的子模塊，
[0044]寫入PostgreSQL塊中數(shù)據(jù)的子模塊。
[0045]所述分配PostgreSQL塊的子模塊采用就近分配策略或冷熱數(shù)據(jù)分層分配策略給 PostgreSQL數(shù)據(jù)表分配PostgreSQL塊，所述就近分配策略是PostgreSQL塊就近分配策略或 空閑PostgreSQL塊表記錄就近分配策略，所述冷熱數(shù)據(jù)表分層分配策略是常用數(shù)據(jù)表分配 策略或近期使用數(shù)據(jù)表分配策略，所述PostgreSQL塊就近分配策略是在數(shù)據(jù)表上次分配的 PostgreSQL塊前后就近尋找空閑PostgreSQL塊分配給數(shù)據(jù)表，所述空閑PostgreSQL塊表記 錄就近分配策略是從空閑PostgreSQL塊表記錄中尋找第一個(gè)空閑PostgreSQL塊，所述常用 數(shù)據(jù)表分配策略是經(jīng)常使用的數(shù)據(jù)表優(yōu)先分配到較快的PostgreSQL塊設(shè)備上，所述近期使 用數(shù)據(jù)表分配策略是將近期使用數(shù)據(jù)表優(yōu)先分配到較快的PostgreSQL塊設(shè)備上，所述冷熱 數(shù)據(jù)表分層分配策略用于具有兩塊以上不同讀寫速度的PostgreSQL塊設(shè)備上；
[0046]所述回收PostgreSQL塊的子模塊用于回收數(shù)據(jù)表不再使用的PostgreSQL塊，從 PostgreSQL塊-數(shù)據(jù)表之間的映射關(guān)系表中刪除對(duì)應(yīng)的PostgreSQL塊記錄，至I」空閑表中將 相應(yīng)PostgreSQL塊的記錄設(shè)置為空閑；
[0047]所述定位PostgreSQL塊的子模塊用于將數(shù)據(jù)表中的頁定位到PostgreSQL塊設(shè)備 指定的位置上；
[0048]所述讀出PostgreSQL塊中數(shù)據(jù)的子模塊用于讀取指