前言
決定應該賦予數據庫什么樣的存儲和 配置,已經成為一項雜亂無章的工作,這種現象我見得多了。數據庫工程師一般都是數據庫的專家,而對于存儲配置的低層細節幾乎一無所知。另外存儲管理員和工 程師也往往不知道數據庫如何利用下層的存儲,以及數據庫、索引文件、記錄文件,當然還有文件系統和卷管理器的需求和最佳配置又是什么。
這往往造成了存儲資源利用率低,增加了整體成本,導致性能降低甚至可能無法滿足你的需求,此外預算也總是很緊張,而管理上又要求有效地利用可獲得的預算。本文將解決數據庫管理員和存儲工程師在解決架構問題而進行協作時的一些問題。
數據庫與存儲架構配置
組件
大部分數據庫的端到端存儲架構所需硬件和軟件如下:
數據庫
控制文件(Control file)
表空間(Table space)
索引文件(Index file)
重做日志(亦稱在線日志,Redo log)
操作系統
文件系統和卷管理器(如果數據庫運行在裸設備上,這一項可能沒有關系)
主機總線適配器(HBA)
存儲硬件
以上每一部分都擁有多個組件,具有多種特性和功能,對整體性能影響顯著。
數據庫
數據庫應用本身具有多重特性和功能,必須加以考慮。Oracle的組件如下:
控制文件----記錄數據庫的物理結構,用于激活數據庫
表空間----來自數據庫各行各列的實際數據
索引文件/空間----Oracle中并不需要索引,不過大型數據庫總會用到索引,因為在數據庫中進行查找時,索引可以大幅提升查找速度
重做日志----被激活的數據庫請求,允許你在數據庫崩潰后進行重建并重新啟動(這些日志本質上類似于文件系統日志)
因為上述組件都有不同類型的訪問模式,所以每種文件類型均被存儲在不同的文件系統中,并有調節選項。其它數據庫也擁有相似的文件類型,需要以相似的方式考慮。
控制文件
大部分數據庫都建議使用多個控制文件以確保可靠性。控制文件并不需要常寫常讀,不過你必須確定各文件被放置在不同的RAID集上,適用于不同的RAID控制器。
表空間
表空間一般是數據庫中量最大的數據。當讀取列上的大表時,表空間可以由更大的I/O請求訪問。根據大小和更新頻率的不同,表空間常常位于更大的數據條帶化RAID-5上,以便獲得較RAID-1更高的密度和提升的性能。
索引文件/空間
在許多數據庫中,索引文件是被訪 問頻率最高的數據。查找索引文件有可能需要很大的IOPS(每秒I/O操作)。另外,有時候數據庫被重新索引,這在計算上非常密集,并且需要大量的I/O 帶寬。因為數據庫和所需的查找類型不同,索引空間也許會很大,一般來說,根據傳統的UNIX文件尺寸,索引文件的大小為2 GB。
重做日志
重做日志文件中存放了各種記錄,你可以撤銷對數據庫的各種操作,這些被稱為重做記錄。重做記錄用于循環緩沖器中,因為它一般是小I/O,所以用RAID-1就不錯。由于需要兩個或以上的重做日志文件,通常將日志文件放在不同的RAID-1卷上。
操作系統
數據庫一般都需要具備操作系統的一些特性和功能,如共享內存和標志等。另外,數據庫也經常利用計算機內大量的內存,這通常由改變數據庫中的可調參數來實現。
在許多操作系統中,I/O請求的大小限制在256 KB或128 KB,不能改變,所以如果必須對存儲和操作系統完成更多的請求,就會影響到I/O性能。
文件系統和卷管理器
架構決策中最重要的事情之一就是為每個數據庫組件確定最理想的卷管理器和文件系統設置,對于每種類型的I/O,你可能希望進行不同的設置,請考慮以下的I/O類型:
長和短的連續塊
長和短的多重數據流塊
所有的讀
所有的寫
多線程
對所有這些類型的I/O來說,只有一組設置的文件系統表現得都不好,而且我敢說對于上述任何兩種類型的I/O來說,只有一組可調參數的文件系統也無法做好,也不可能通過改變參數來提升性能。
設計中要確定的兩個關鍵因素是:
1.對于所要處理的I/O類型,什么是最好的卷管理器和文件系統
2.對于該文件系統和卷管理器,什么又是最好的可調參數
幾年前我曾做過一個數據庫,由于一些原因而無法進行擴展,不過我認為其中最主要的原因是RAID緩存在進行索引查找時未得到有效利用。RAID的讀訪問率小于20%,而且我認為大部分是不規則的連續讀(先對幾個請求連續讀,然后隨機跳過幾個,又開始連續讀)。
檢查卷管理器后,我發現了問題所在。每個文件系統有32個LUN(邏輯單元號),每個LUN為8 GB。文件系統上的數據條設置為32 KB,與RAID分配相符。每個索引文件是2 GB。
考慮到RAID緩存的工作方式,你必須先讀兩個連續塊再讀第三個塊,這是常用的算法,因此在下一個I/O到達緩存之前,需要32 KB*32 LUN*2,即2 MB的連續讀數據。
RAID緩存利用率如此低下并不奇怪。客戶被告知他們有兩個辦法提升性能,一是為卷管理器數據條分配2 GB,這樣每個索引文件均被連續分配;二是使用另一種文件系統,可以使數據進行循環而不是條帶化。循環狀態下,每個開放的系統請求都會被分配給另一個LUN,并且被打開的文件中所有數據也都會被分配在那個LUN上。
當我們使用循環分配方法和讀緩存測試這種配置時,訪問率從20%上升到80%,性能也超過了當時客戶的要求。