數(shù)據(jù)庫工程師：DBA在系統(tǒng)設計開發(fā)中的重要性
許多應用系統(tǒng)的性能或穩(wěn)定性并不理想，這在系統(tǒng)上線后不久就逐漸變?yōu)榧值膯栴}，造成這些問題的原因，往往體現(xiàn)了一點：開發(fā)設計這些系統(tǒng)的人，對數(shù)據(jù)庫本身不是很了解！而DBA又不了解業(yè)務！這就導致了很多本來可以避免的問題產(chǎn)生；另一方面，隨著數(shù)據(jù)庫自我調(diào)整、管理的能力不斷加強，而應用又往往是系統(tǒng)性能最大的殺手，所以，DBA的工作范疇，從只負責數(shù)據(jù)庫服務器維護，逐步走向管理應用系統(tǒng)的設計、開發(fā)，是必然的趨勢！
一、 現(xiàn)階段DBA對系統(tǒng)性能及穩(wěn)定性所做的調(diào)整工作
目前DBA對系統(tǒng)性能的調(diào)整工作大致是這么幾個方面：
1、 在硬件層面進行調(diào)優(yōu)，這通常就是直接花錢，買設備、擴容。
2、 在DB層面進行調(diào)優(yōu)，比如調(diào)整初始化參數(shù)，調(diào)整數(shù)據(jù)庫物理結(jié)構(gòu)。
3、 對應用的SQL進行優(yōu)化，比如在數(shù)據(jù)庫分析statspack，調(diào)整Top SQL。
4、 只有非常少數(shù)的，通常是對系統(tǒng)穩(wěn)定要求較高的一些公司的應用，才會在新的應用上線前，讓DBA對sql進行充分的審核與評估。
問題：在應用系統(tǒng)的分析、設計、開發(fā)階段，就目前情況看，很少有DBA參與，而應用系統(tǒng)上線或者開發(fā)工作基本結(jié)束后，DBA所能做的調(diào)優(yōu)工作其實是很有限的。
二、 許多應用系統(tǒng)的性能或穩(wěn)定性仍不理想
許多應用系統(tǒng)的性能并不理想，或者系統(tǒng)數(shù)據(jù)會出現(xiàn)一些難以重現(xiàn)的奇怪的錯誤，這些問題（尤其是性能問題）有時并不是在系統(tǒng)初期就會體現(xiàn)出來，但是隨著系統(tǒng)的運行、數(shù)據(jù)的增多而逐步變得難以解決，給系統(tǒng)后期的功能擴展和用戶使用上帶來了不少麻煩，造成這些問題的原因，往往體現(xiàn)了一點：開發(fā)、設計這些系統(tǒng)的人不了解數(shù)據(jù)庫！以基于Oracle的應用為例，簡要舉例說明：
底層數(shù)據(jù)結(jié)構(gòu)不合理
由于缺少專業(yè)DBA的協(xié)助，很多系統(tǒng)設計出來的底層數(shù)據(jù)庫表結(jié)構(gòu)問題重重。而做過系統(tǒng)的人都知道，底層數(shù)據(jù)庫結(jié)構(gòu)不合理，帶來的改造代價之大幾乎等于一次重構(gòu)！我見過一個OLTP系統(tǒng)，其核心表竟有100個字段，平均一條記錄超過8K，如果按Oracle默認的8K一個Block，一半以上的行必須產(chǎn)生行鏈接！
而最糟糕的是，設計這樣表結(jié)構(gòu)的人還認為自己充分利用了冗余來降低表之間的連接，事實上，其人根本不曉得什么是范式、什么是更新異常，按照范式，這個表應該拆分為兩個表的，但如果要改幾乎所有的程序都要改！雖然范式不是越高越好，但絕對是設計的人必須吃透的一個東西。在冗余上，相信大多數(shù)DBA都認為，級聯(lián)更新的代價是非常高的，因此冗余應當避免發(fā)生級聯(lián)更新的情況，對于關(guān)系型數(shù)據(jù)庫設計中冗余的使用，絕不是門很容易掌握的技巧。
不合理的底層數(shù)據(jù)庫結(jié)構(gòu)設計，給系統(tǒng)的性能埋下了重磅的定時炸彈，這個系統(tǒng)在客戶那里跑不到一年，數(shù)據(jù)量稍微上去些，性能、穩(wěn)定性就直線下降，而重構(gòu)的成本又極高，買新服務器肯定是只能治標。而假如底層數(shù)據(jù)表結(jié)構(gòu)是資深DBA設計的又會如何？當然，如果完全讓DBA去做數(shù)據(jù)庫表結(jié)構(gòu)的設計，DBA就必須非常清楚地了解整個系統(tǒng)的業(yè)務細節(jié)信息，這在DBA來說，人力資源上是有一定困難的，畢竟維護好線上服務器就已經(jīng)占用了DBA很多的資源，并且領(lǐng)導們通常更看重這點。
很少有領(lǐng)導能認識到DBA在系統(tǒng)開發(fā)設計中所起到的作用，和維護線上系統(tǒng)、處理DB故障相比，對整個系統(tǒng)的穩(wěn)定性和性能，是同樣重要的！
SQL性能問題
系統(tǒng)的開發(fā)，通常和DBA是沒有什么關(guān)系的，但是，如果DBA對系統(tǒng)有足夠的了解，這時候也是可以做不少貢獻的。比如，檢查系統(tǒng)業(yè)務的數(shù)據(jù)流是否正確，這個需要通過一些手段，比如sqltrace、10046等，詳細對系統(tǒng)的邏輯實現(xiàn)進行檢查，一方面查出系統(tǒng)中過于消耗資源的或編寫不規(guī)范的SQL及時進行調(diào)整優(yōu)化，另一方面，查出系統(tǒng)中不合理的數(shù)據(jù)庫訪問，不要到了線上才發(fā)現(xiàn)問題，那時可能已經(jīng)宕機了。簡單舉個例子，當一個頁面需要多處顯示商品的類目列表時，程序往往容易犯一個錯誤，就是多次以同樣的SQL讀取出同樣的數(shù)據(jù)，并應用于每一個列表顯示上，如果你只讀取一次，或者干脆在Web層進行cache（要有適當?shù)乃⑿虏呗裕?，就可以大大減少單次訪問該頁面在DB上的I/O消耗。有時甚至會檢查出根本不需要被執(zhí)行的SQL，也在這些和自己毫不相干的功能中頻繁地執(zhí)行著……同時，對數(shù)據(jù)流的檢查還能夠查出一些隱藏得較深的系統(tǒng)Bug，這個更需要基于DBA對業(yè)務細節(jié)的了解。
誰說DBA只會花錢？如果一個服務器I/O負載達到極限，大多數(shù)人只能選擇擴容，最多重構(gòu)部分功能來作些優(yōu)化，而從statspack往往可以看出，系統(tǒng)的I/O資源多數(shù)是被一些并不該如此頻繁執(zhí)行的SQL給占用了，它們單次執(zhí)行并不慢，但占用系統(tǒng)資源比例卻異常高，這些問題，細化在每一個業(yè)務中，對這些問題的檢查和數(shù)據(jù)流優(yōu)化，就是對系統(tǒng)資源的最大節(jié)省，就是省錢！這個工作，或許只有DBA才能稱職。
并發(fā)問題
誰都知道系統(tǒng)有并發(fā)存在，可是我們在設計系統(tǒng)的時候，又往往是按照單一業(yè)務的思維模式來設計、編碼，很少考慮同一業(yè)務、不同業(yè)務之間并發(fā)運作可能產(chǎn)生的問題。通常，系統(tǒng)無規(guī)律地出現(xiàn)一些“奇怪的”、“不可能的”錯誤，極有可能就是并發(fā)惹的禍，而背后的問題，往往體現(xiàn)了設計人員不了解數(shù)據(jù)庫的鎖機制，無法和業(yè)務很好地結(jié)合。設計的人不了解數(shù)據(jù)庫，而DBA又不了解業(yè)務，這就導致了很多本來可以避免的問題產(chǎn)生。
最經(jīng)典的就是Tom Kytes舉的酒店預定的例子，當兩個服務員同時按下查找預定房間的按鈕，結(jié)果是兩個人都預訂到了同一間客房，這個問題很經(jīng)典，在目前看來也很容易解決，不就是加上鎖么？但是，這只是一個例子，在你實際應用的系統(tǒng)中，你這樣貿(mào)然地加上for update，又可能導致別的問題！比如：死鎖。在一個復雜的業(yè)務系統(tǒng)中，死鎖不難見到，這個是設計者的設計漏洞，需要設計者全面衡量業(yè)務關(guān)系，然后對表的鎖定制定規(guī)則來盡量避免的。學會使用鎖來保證數(shù)據(jù)的完整性還是不夠的，還要靈活應用鎖，適當采用樂觀鎖定。
如果對于重要的業(yè)務，一律免談，直接悲觀鎖定也是不可取的，會給系統(tǒng)的維護帶來一些問題，某些業(yè)務這樣做甚至會帶來數(shù)據(jù)的大面積鎖定時，在OLTP上的代價很高，嚴重影響系統(tǒng)并發(fā)能力。我曾經(jīng)碰到一個錯誤數(shù)據(jù)的問題，分析后，確定是兩個不同的業(yè)務間并發(fā)，同時缺少必要的鎖定，而造成的錯誤數(shù)據(jù)。但基于該業(yè)務的特殊性，加鎖的代價是昂貴的，在DBA的仔細追究下，確認了可以通過樂觀鎖定也即提交時檢驗的方式來達到兩全其美的目的。從這里可以看出，數(shù)據(jù)的健康和完整性，與系統(tǒng)的并發(fā)能力有時是矛盾的，但有經(jīng)驗的DBA能夠教你如何獲取最佳方案，當然，前提是DBA參與設計并熟悉業(yè)務。
系統(tǒng)架構(gòu)的問題
DBA不是系統(tǒng)架構(gòu)師，但數(shù)據(jù)庫是一個應用系統(tǒng)核心的部分，同時，由于數(shù)據(jù)庫服務器不像應用服務器那樣便于擴展，因此往往也是整個系統(tǒng)性能的瓶頸所在，所以架構(gòu)師在設計系統(tǒng)架構(gòu)時，應該充分考慮DBA的意見，要考慮到DBA對數(shù)據(jù)庫中的SQL進行性能調(diào)整的便利性甚至是可行性！
否則就可能導致DBA及開發(fā)團隊對系統(tǒng)的性能問題反應過慢甚至束手無策！我曾經(jīng)見過一個架構(gòu)，它無法實現(xiàn)oracle最普通的分頁SQL!綁定變量就根本不在考慮中！再就是有些第三方組件或架構(gòu)，能夠幫助我們的系統(tǒng)生成SQL，這當然很省事，能夠加快開發(fā)速度，可是在這樣的系統(tǒng)中，DBA如果想要優(yōu)化一條SQL可能很難，因為開發(fā)人員要修改的東西相對較多，修改的工作量大、耗時長，并且工作量多肯定就更容易帶來新的錯誤！Oracle大師Tom Kytes也曾在經(jīng)典著作Export one on one中反對使用這種自動產(chǎn)生SQL的組件或架構(gòu)，這種東西很可能給你的系統(tǒng)帶來性能和維護上的問題！
這些問題，如果咨詢過資深DBA，相信會盡早發(fā)現(xiàn)并在架構(gòu)上得到修復或調(diào)整。而到了系統(tǒng)開發(fā)的后期，架構(gòu)的問題已經(jīng)很難做本質(zhì)的調(diào)整了。假如你的系統(tǒng)要求非常高效，并且并發(fā)訪問較大，那么建議架構(gòu)師傾向于尊重DBA的意見，這對整個系統(tǒng)的性能以及持續(xù)地調(diào)優(yōu)將非常重要。而DBA，對系統(tǒng)架構(gòu)也要有一定的認識，并明確自己在現(xiàn)有架構(gòu)中遇到的困難是什么。
三、 提高應用系統(tǒng)的性能、穩(wěn)定性
除了DBA原本的DB調(diào)優(yōu)、SQL調(diào)優(yōu)、服務器維護等日常工作以外，擴展DBA的工作范疇，強化DBA在系統(tǒng)開發(fā)過程中的控制能力和決定權(quán)。
1、 讓DBA參與到需求分析中去，并充分理解用戶需求，從DB的角度來理解和考慮這些需求實現(xiàn)的成本。
2、 Schema的設計必須由DBA設計確定或者審核確定，這點也要求DBA必須了解業(yè)務系統(tǒng)，才能整理出正確的、有良好擴展性的E-R關(guān)系。
3、 讓DBA更深入的參與系統(tǒng)的設計，盡可能地讓DBA了解應用的業(yè)務設計細節(jié)，這對于DBA審核數(shù)據(jù)流是起到?jīng)Q定性作用的，如果有條件，業(yè)務的數(shù)據(jù)流應當作為系統(tǒng)的文檔之一，以便將來的反復核查。
4、 在系統(tǒng)上線之前，由DBA審核sqltrace中的sql以及數(shù)據(jù)流邏輯，最好是能給出一些重要業(yè)務功能在DB成本（比如I/O）上的評估結(jié)果。
5、 系統(tǒng)上線后的性能監(jiān)控，及時作出調(diào)整甚至一定范圍內(nèi)重構(gòu)優(yōu)化數(shù)據(jù)訪問邏輯。
如上所述，則DBA的人力資源必然不足，因此，細化DBA的工作，進行分工是正確并且高效的，在一些公司，已經(jīng)將DBA分為專管線上服務器的產(chǎn)品DBA和專管開發(fā)、參與系統(tǒng)設計的開發(fā)DBA，從不同方面全面保障系統(tǒng)的穩(wěn)定和高效，值得借鑒！
【編輯推薦】
