Megosztás a következőn keresztül:


迷思止步 - 系列四:資料庫效能,究竟有無第一名?

在 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 查詢,總之用盡一切的力量,將惱人的效能問題加以革除。

Comments

  • Anonymous
    October 17, 2014
    系列一:Big Data 淘金,就得砸大錢蓋礦場?

    全球最大零售業者 Wal-Mart 運用 Hadoop 技術,針對駐留於 Facebook 或 Twitter 等社群媒體的商品討論訊息