iT邦幫忙

6

【好文分享】資料庫效能,究竟有無第一名?

還記得好康妹的工商服務好文推廣時段嗎?
許久不見的新文章隨著新年新氣象來囉~
到底各位大大心目中的資料庫第一名是什麼呢?會比較哪些項目啊?

回顧系列前文:
【好文分享】迷思止步!資料庫應用大無限-SQL Server 其實不簡單!
【好文分享】迷思止步!資料庫應用大無限-Big Data 掏金就得砸大錢蓋礦場
【好文分享】關鍵資料庫太「關鍵」,豈能以不變應萬變?
◆迷思止步 資料庫應用大無限!
資料庫效能,究竟有無第一名?

在DBA心目中,對於各廠牌資料之間的效能高下,往往擁有一番定見;總是有若干人認為,某些供應商從資料庫起家,肯定是這個領域的第一把交椅,在效能部分穩居盟主寶座;然而這般見解,究竟是顛撲不破的真理?還是摻雜了幾許謬誤?讓我們繼續看下去!

絕大多數的企業應用系統,都會隨著時間演進,因而累積大量資料,這些資料都需要被整理為有用資訊,才可成為彌足珍貴的數位資產;在此情況下,賴以管理大量資料的資料庫系統,確實是企業資訊之命脈,除須擁有不容閃失的高穩定度外,當然也應該擁有優異的運作效能。

因此,多數DBA都不會懷疑,懂得選擇一套高效能的資料庫,絕對是他們職涯當中重要的必修學分,否則萬一挑到效能不彰的系統,導致企業應用服務無法流暢運行,進而惹得公司從上到下怨聲載道,這個罪名對於DBA來說,無疑是不可承受之重。

儘管市場上資料庫品牌為數不多,但要想評斷它們孰優孰劣,似乎也沒那麼容易。因為資料庫效能測量環境,需要在相同的商用負載執行情境下,動用時間、人力、財力、能力等可觀資源堆砌而成,而且不論是壓力測試或單元測試,其過程都務求擬真徹底,任何環節都不容疏漏,如此才能確保測試結果的精準度;這一切的一切,顯然並非輕而易舉之事。

既然執行測試大不易,部分DBA寧可選擇抄捷徑,聽取幾個前輩與同業的意見,就這麼演化出一套似是而非的邏輯,未經詳細驗證,直接就認定某某品牌資料庫為首選,心想反正有人強力推薦,其效能勢必出類拔萃,用了準沒錯。

殊不知別人用得虎虎生風的系統,到了自己的環境,卻未必盡如人意;DBA這才有所頓悟,下回面臨資料庫品牌的抉擇之際,還是得老老實實走完概念驗證(POC)程序,眼見為憑最重要,不要繼續人云亦云。

表面看來,這個遲來的頓悟似乎有理,但倘若主其事的DBA依舊思路閉塞,未能釐清一些基本課題,縱使做足了POC,恐怕也未必能覓得最佳資料庫。

評估資料庫效能,需隨情境而調整
不可否認,在若干DBA的印象中,提到效能評價,部分執行於UNIX環境的資料庫品牌,始終凌駕於SQL Server之上,殊不知近期一些用戶端系統的資料庫測試比較,SQL Server反而是輸少贏多的;關鍵除在於SQL Server效能的持續提升外,另透過SQL Server的記憶體優化技術xVelocity 大幅提升查詢效能,針對大量交易系統則採用Snapshot Isolation隔離層級有效降低Block的發生,更搭配分割資料表卓越功能,以致讓SQL Server在各大戰役中無往不利。

值得一提的,SQL Server 2012內建Distributed Replay功能,可有效模擬大量資料對SQL Server進行壓測,無需購買昂貴軟體,亦使SQL Server在校能或性價比上大幅超越對手。SQL Server憑藉友善與完整的管理工具,搭配相對容易取得的專業諮詢服務,即不難被調校出優異狀態,反觀其餘資料庫系統,除了效能有待商榷外,DBA意欲覓得正確資源,將之調校出應有表現,本身即是一大挑戰。

資料庫技術發展數十載,相關技術已經相當成熟,倘若不同廠牌系統並肩而坐,各方皆在相同情境標準的設定下,再佐以應有的專業調優設定,有些時候確實會出現效能難分軒輊的場景,只因眾家系統所運用的資料存取方式與技術,相似度極高,影響所及,彼此之間性能好壞之差別,也可能不甚明顯;換言之,不論是特定資料庫系統長期被人奉為上上之選,抑或 SQL Server 曾被誤解為效能有待加強,說穿了,全都是偽命題,與實情並不吻合。

所有商用資料庫一字排開,SQL Server的效能表現鮮少居於劣勢,優異的表現亦是備受肯定。既然環顧各家資料庫的處理效能,SQL Server始終名列前茅,所以在客觀條件相同的前提下,DBA的評選標準就很簡單,何者的總體持有成本(TCO)最低,便是不二選項,因為就算費盡心力追逐高價系統,也無法換取更佳效能。

效能疲軟,未必是資料庫闖的禍
不可否認,雖然眾家資料庫體質雷同,但只要分別被投放到不同應用環境,實際效能表現總是天差地遠,有的健步如飛,有的卻步履蹣跚;但即使發生後者現象,難道就可對該資料庫系統大加撻伐?非也!絕大多數情況下,原因並不在於系統先天不良,而是其他後天不良因素惹的禍。

如同前述,各資料庫賴以讀寫資料的方法,其實都很類似,因此它們所面臨的效能瓶頸,自然如出一轍,都很容易受限於伺服器、儲存設備或SAN交換器等硬體I/O,所以在大多數情況下,或許僅須將硬體更換為優規設備,就能化解效能疲弱之病態。

只不過,有時換了機器,資料庫運行速度卻未見提升,其癥結顯然就不在I/O瓶頸之上,可能源自於低效的查詢,或是應用程式本身的設計不良;值此時刻,DBA即應保持淡定,先以抽絲剝繭方式找出問題根源,再將練就多時的調優技巧施展開來,看看是要將資料庫的邏輯加以正規化,改採更具效率的索引設計與查詢設計,或是設法分解並隔離慢速的SQL查詢,總之用盡一切的力量,將惱人的效能問題加以革除。


1 則留言

我要留言

立即登入留言