AP與DBMaker的搭配 – Performance Tuning初探

AP與DBMaker的搭配 – Performance Tuning初探

節錄

Database的原理，與上述的情形頗為類似，其中所謂的三層館藏，指的是實際存放資料的硬碟或其他儲存媒體，「工作平台」指的是記憶體。所有資料庫的搜尋或傳給客戶端的資料，都必須一定要先放在記憶體，搜尋動作會損耗CPU資源，但資料的處理、搜尋都必須先放在記憶體中，此處意指記憶體有 3000個單位(pages)。

所謂「客戶詢問」，指的便是由客戶端來的各式各樣的query，而無論客戶端的query如何，資料庫一定得將資料找到，並傳回客戶端。

---

索引如同其他資料頁一樣，必須先載入至記憶體後，CPU才能針對其中的內容，進行「比較」運算；而由於磁碟速度極慢，DBMaker會將常用的資料頁(含索引頁)儘量放在記憶體中，如此一來，當要再搜尋某資料頁時，就有相對較大的可能，可以在記憶體中找到，而不須到磁碟上去搜尋。

---

在定義索引時，自然也是以「排除效果」(filter effect)大的為佳，在條件判斷過程中，並不是只搜尋索引頁，而是有可能進一步搜尋資料頁，所以要想辦法讓第一次搜尋索引頁時，儘可能第一時間排除所有「不可能」的資料，上述中，作者的排除效果顯然就沒有書名好，也可以想作，書名比較「unique」

---

有許多SA，在設計之初，將所有query可能用到的欄位，都一一設定成索引。由上述的推演可以看出，這樣的作法不見得明智，理論上，DBMaker會從最符合的索引開始搜尋(如上述的書藉-作者索引)，但搜尋所花的工夫，卻還不如用單一的作者索引來得快。在設計索引時，必須要將這些因素考量在內，複合鍵有時會造成索引變大，甚至過肥， I/O加重的結果，反而拖慢了performance。

有些query是很難去定義出一個好的index，這時只要是「還好」的索引，可能就夠了，上述的 query，若將全部欄位建立成索引，可能會造成索引肥大，不見得好，建議將排除效果的欄位先建立好，若是能將所有搜尋的資料頁降低到25%以下，就算是不錯的索引，有些SA甚至會定義「血型」、「性別」為索引，這種索引的排除效果都不是甚佳，除非必要，這樣的索引應儘量避免。

另外常見的情形，便是一個常被變動的表格，本身資料量也很大，也常被查詢，表格本身可能有十個以上的索引，因為常變動，任何的變動都會造成索引值須被更新，十個以上的索引頁，都須被放入記憶體以便進行「新增索引」的動作，想想，這會造成系統效能多大的負擔?!

---

記憶體的大小調整，是所有DBA在系統效能調整時，必須先考量的，有些評比報告，常將兩個不同記憶體大小的資料庫效能加以比較，在先天上將造成了不公平，評比的結果自然也讓人存疑，在linux journal中文版雜誌2001年9月號，針對某家資料庫的效能調整，全文都在探討如何放大記憶體，由此可見記憶體大小對performance的重要。
記憶體當然能放大就儘量放大，讓所有資料能儘量在記憶體中，減少I/O的次數。但這樣也須付出代價，便是當系統毀損時，變動的資料都可能還在記憶體中，雖然DBMaker有LOG可記錄所有變動，但還是會讓recovery的時間拉長。有些個案甚至造成了資料庫的毀損，所以在設計系統時，亦將此因素一併考量，DBMaker在4.0後，會針對系統可用的資源，自動幫使用者劃好可用記憶體，但若使用者本身有其他考量，當然也可自己設定，而不依賴系統的調整； DBMaker要調整記憶體大小，相當容易，只要去調整dmconfig.ini中的DB_NBUFS即可，詳細內容，請參閱Administrator Guide。