您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關PostgreSQL中BRIN索引指的是什么,文章內容質量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關知識有一定的了解。
眾所周知,PostgreSQL 各種插件的數據量和他無底洞的功能豐富性,被使用者所嘆服。而PostgreSQL 有一種索引,BRIN 肯能使用的人不是很多,或許你也可能第一次聽說這個索引的名字。相比 GIST ,GIN 這樣的索引類型,BRIN 的名聲可能稍有差距。那今天我們就來看看 BRIN 到底能做什么,為什么而生。
我們先創建一個表
插入一些數據 (當然這些數據是針對Brin 索引的數據)
我們通過下面的查詢來看一下在沒有索引的情況下查詢時間類型的數據會怎樣。
從下圖我們可以對比出,添加索引后和全表掃描之間的cost 差距
從上圖可以看出,添加索引后,查詢的速度提高了,但我們的關鍵點不在這里,我們是要比較,BTREE 索引 和 BRIN 索引之間的不同點。
我們在同樣的表的同樣的字段創建,不一樣類型的索引。通過圖形中我們可以看出創建兩種索引的時間是不一樣的,brin 索引的速度比 BTREE 索引要快大約不到 12倍。
我們在對比一下兩種索引的尺寸,看完下圖,我估計你的嘴應該不會閉上,或許還會發出點聲音。的確 BRIN 索引的尺寸是超小的,當然也是有原因的。
我們繼續,那這樣小的索引,對比BTREE 索引,到底查詢的效率是不是可以滿足要求呢?
我們可以看出,在默認的情況下,系統會默認使用 BTREE 索引,在兩種索引都存在的情況下。
對比 BRIN 索引,雖然BRIN 索引比BTREE 索引慢了 些許毫秒,但對比索引所占用的空間比,BTREE 占用 129MB 而 BRIN 占用 56KB 你就能體會,你第二次長大的嘴,BRIN 索引真的很厲害。
說完上面那些,我們的談談,到底BRIN 索引是怎么做到的,大幅度降低索引的存儲空間,并且還保證超高的索引查詢中的查詢率。
原因,BRIN 索引是一種有損索引,這個索引的簡稱 Block Range Index, 而BRIN 索引產生的主要原因也是為了一些 “超級大表的索引”,試想一下,你有一張6億條記錄的表,很可能你的索引就是幾個G ,而這樣的索引在查詢中,其實隨著數據量的增大,性能是線性下降的。
而BRIN 所以存儲的數據并不是普通索引那樣的 BTREE 的數據,而是存儲元祖數據,以及相關數據的頁面信息,通過這些信息,大大減少了存儲數據的空間,而在判斷數據是否符合條件的情況下,則比BTREE 索引要付出更多的過濾和對比的過程,但相對他超高的性價比,對于大表, 有序型的數據的索引的建立,BRIN 索引是值得被考慮和使用的。
當然如果有人問,這里面BRIN 索引是否牽扯類似壓縮比率這樣的事情
pages_per_range ,如果你將每頁的范圍調整過大,則損失就會越大,所以我們也可以在 “壓縮” 和 準確度,之間做一個平衡。
最后我們來回顧一下,使用BRIN 索引的主要場景和目的
1 大表的索引性能問題
2 表中索引的數據在表中的字段最好是順序型的,例如日期,或者某些可以順序化的場景(其實時序數據庫就符合這樣的類型)
3 對索引占用空間敏感的場景。
關于PostgreSQL中BRIN索引指的是什么就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。