|
|
聲明：
本文是一篇有爭(zhēng)議的文章，甚至有可能是一篇爭(zhēng)議非常大的文章，可能爭(zhēng)來(lái)爭(zhēng)去依然無(wú)法得到一個(gè)統(tǒng)一的意見(jiàn)。
場(chǎng)景
個(gè)別公司的技術(shù)決策者要求團(tuán)隊(duì)的開(kāi)發(fā)人員在編寫(xiě)數(shù)據(jù)訪問(wèn)層的時(shí)候，禁止在程序中出現(xiàn)任何的SQL語(yǔ)句，禁止使用Entity Library，禁止使用NBear、NHibernate、IBatis、Entity Framework等ORM框架，只允許使用存儲(chǔ)過(guò)程。試想一下，您的公司是否是這樣子的？您的身邊有沒(méi)有這樣的朋友，他們的公司存在這樣或類(lèi)似這樣的情況嗎？
矛盾點(diǎn)
對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)，使用存儲(chǔ)過(guò)程的話(huà)，工作量比以前要大很多，而且涉及到表的字段更改，項(xiàng)目重構(gòu)也是個(gè)非常麻煩的問(wèn)題。使用ORM很方便就可以實(shí)現(xiàn)數(shù)據(jù)的CRUD功能，多表操作也非常的容易，原來(lái)寫(xiě)很少的代碼就可以操作數(shù)據(jù)，現(xiàn)在卻要寫(xiě)很多的代碼。本來(lái)公司給的時(shí)間就短，項(xiàng)目緊，現(xiàn)在這么一搞，工作量一下就增加了不少，再者，如果需求一旦發(fā)生變化，不可避免的數(shù)據(jù)庫(kù)就得增加或修改某些字段，相應(yīng)的存儲(chǔ)過(guò)程跟數(shù)據(jù)訪問(wèn)層的方法都得做調(diào)整，開(kāi)發(fā)人員的日子不好過(guò)了。
對(duì)于公司的決策者來(lái)說(shuō)，性能問(wèn)題是不可以妥協(xié)的，無(wú)論付出多大代價(jià)，既然做出了決定，那么就沒(méi)什么好討論的。
結(jié)果
結(jié)果可想而知，最終是按照決策者的決定，開(kāi)發(fā)人員加班加點(diǎn)的做開(kāi)發(fā)，既然決策者都已經(jīng)做了決定，似乎再討論用不用存儲(chǔ)過(guò)程就是一個(gè)非常敏感的話(huà)題，再討論類(lèi)似的問(wèn)題的話(huà)，開(kāi)發(fā)人員所面臨的處境就可能是尷尬的，在某些公司甚至是危險(xiǎn)的。無(wú)論怎樣，開(kāi)發(fā)人員可能最終都很難改變決策者的決定。
決策者的心聲
帶著這些疑惑，我跟多位決策者進(jìn)行溝通，搜集了他們的意見(jiàn)，總結(jié)下來(lái)的話(huà)，大概就是以下幾點(diǎn)：
- 性能問(wèn)題。經(jīng)過(guò)測(cè)試，使用ORM比直接調(diào)用存儲(chǔ)過(guò)程慢10倍。如果是做軟件項(xiàng)目或軟件產(chǎn)品，使用ORM問(wèn)題不大，可是如果是以運(yùn)營(yíng)為主（訪問(wèn)量較大）的Web網(wǎng)站，性能上就會(huì)有問(wèn)題。
- 并發(fā)問(wèn)題。一旦訪問(wèn)量較大并且達(dá)到一定數(shù)量級(jí)的時(shí)候，ORM就可能會(huì)出現(xiàn)并發(fā)問(wèn)題。
- DBA的能力受限。一旦出現(xiàn)性能問(wèn)題，如果是按照寫(xiě)存儲(chǔ)過(guò)程的方式來(lái)做，公司可以招來(lái)技術(shù)實(shí)力強(qiáng)的DBA直接改存儲(chǔ)過(guò)程進(jìn)行優(yōu)化，而如果是使用ORM的話(huà)，那么DBA就很難進(jìn)行優(yōu)化，因?yàn)镈BA很難讀懂ORM寫(xiě)的程序，更不知道ORM內(nèi)部的實(shí)現(xiàn)方式，這樣一來(lái)，DBA的能力就得不到施展。
- 不愿意被微軟綁架。以Entity Framework為例，Entity Framework不是開(kāi)源的，如果出現(xiàn)性能問(wèn)題，不能夠看到源代碼，這可能是一個(gè)風(fēng)險(xiǎn)。再者，一個(gè)強(qiáng)有力的公司強(qiáng)有力的團(tuán)隊(duì)，如果沒(méi)有自己的技術(shù)，總是使用微軟的不開(kāi)源的框架，這怎么可以？
- Entity Framework是微軟的產(chǎn)品，微軟的產(chǎn)品只適合中小型的公司做開(kāi)發(fā)，大的互聯(lián)網(wǎng)公司是不敢用的，甚至他們可能采用Java+Oracle來(lái)做，一旦達(dá)到一定數(shù)量級(jí)，微軟的東西就可能會(huì)出現(xiàn)問(wèn)題。
筆者的心聲
在充分理解了決策者的心聲以后，我思緒萬(wàn)千，心中久久不能平靜。終于，在把很多東西看淡，拋開(kāi)雜念，在這樣一個(gè)寧?kù)o的夜晚，也坦誠(chéng)的把我的想法一一闡述，分別針對(duì)決策者的心聲，談一談我的個(gè)人看法。
1. 到底什么是性能問(wèn)題？存在不存在性能問(wèn)題？
來(lái)看下測(cè)試是如何做的，使用存儲(chǔ)過(guò)程進(jìn)行插入或刪除操作，分別使用存儲(chǔ)過(guò)程和Entity Framework，循環(huán)10000次或者1000000次操作，然后整體上存儲(chǔ)過(guò)程要比使用Entity Framework要快10倍。實(shí)際場(chǎng)景是怎樣的呢？
實(shí)際的場(chǎng)景是用戶(hù)點(diǎn)擊頁(yè)面上的按鈕，執(zhí)行了1次操作，我們假定按照寫(xiě)存儲(chǔ)過(guò)程的方式來(lái)做，用戶(hù)這1次操作可能需要0.001秒，而使用Entity Framework要慢10倍，用了0.01秒，那么這0.001秒比0.01秒的確是快10倍，但是對(duì)用戶(hù)來(lái)說(shuō)，可能根本就沒(méi)有明顯的差距，因?yàn)檫@么微弱的時(shí)間用戶(hù)是體會(huì)不出來(lái)的。我們開(kāi)發(fā)的程序，對(duì)用戶(hù)來(lái)說(shuō)，我們的產(chǎn)品會(huì)不會(huì)因?yàn)檫@0.001秒跟0.01秒的差距而打折扣呢？這微弱的差距是嚴(yán)重性能問(wèn)題？還是可以忽略不計(jì)？
2. 到底存在不存在并發(fā)問(wèn)題？
誠(chéng)然，可能之前有團(tuán)隊(duì)使用ORM開(kāi)發(fā)高并發(fā)的項(xiàng)目，他們?cè)谶\(yùn)營(yíng)中出現(xiàn)了并發(fā)問(wèn)題，可是DBA又無(wú)法查出來(lái)到底是什么地方導(dǎo)致了并發(fā)問(wèn)題，最終把一切的一切歸咎在ORM上。
親愛(ài)的朋友們，讓我們理智的冷靜的來(lái)分析下兩者的技術(shù)實(shí)現(xiàn)上的不同吧。
直接調(diào)用存儲(chǔ)過(guò)程：打開(kāi)數(shù)據(jù)庫(kù)連接--》執(zhí)行編譯好的數(shù)據(jù)庫(kù)語(yǔ)句--》關(guān)閉數(shù)據(jù)庫(kù)連接；
ORM：打開(kāi)數(shù)據(jù)庫(kù)連接--》把對(duì)象解釋成SQL語(yǔ)句--》執(zhí)行SQL操作--》關(guān)閉數(shù)據(jù)庫(kù)連接。
通過(guò)對(duì)比，我們可以發(fā)現(xiàn)，ORM就可以比作是一個(gè)SQL生成器，它把對(duì)象解釋?zhuān)匆粋€(gè)SQL語(yǔ)句出來(lái)，然后在執(zhí)行這個(gè)SQL語(yǔ)句，由于還需要解釋?zhuān)拖喈?dāng)于多了一步翻譯的工作。因此，就比存儲(chǔ)過(guò)程慢了一點(diǎn)點(diǎn)，那么慢的這一點(diǎn)點(diǎn)會(huì)不會(huì)出現(xiàn)并發(fā)問(wèn)題？我的意見(jiàn)是并發(fā)問(wèn)題多半是由于鎖的影響，只要不產(chǎn)生鎖，就不會(huì)有并發(fā)問(wèn)題。正因?yàn)槿绱耍卟l(fā)的項(xiàng)目開(kāi)發(fā)，多半是忌諱使用事務(wù)，有的程序員手寫(xiě)異常后的數(shù)據(jù)庫(kù)回滾語(yǔ)句（有些滑稽哈，但事實(shí)上就是這樣），項(xiàng)目中也不推薦使用游標(biāo)跟觸發(fā)器。
3. DBA能力受限。誠(chéng)然，DBA看不懂ORM寫(xiě)的程序，更加不明白ORM內(nèi)部的實(shí)現(xiàn)原理。但是，DBA是可以跟程序員配合，利用SQL Profiler等工具，看到最終SQL語(yǔ)句是如何執(zhí)行的。也就是說(shuō)，DBA的能力也是依然可以發(fā)揮出來(lái)的，只不過(guò)是需要跟程序員配合而已，或者DBA需要熟悉如何調(diào)試、跟蹤。如果說(shuō)全部寫(xiě)存儲(chǔ)過(guò)程了，DBA能力是放開(kāi)了，可是程序員的能力就受限了，譬如說(shuō)，在進(jìn)行大批量的數(shù)據(jù)插入的時(shí)候，大家都知道，.ADO.NET2.0的一個(gè)新特性SqlBulkCopy是多么的快，估計(jì)這是DBA無(wú)法優(yōu)化的。對(duì)SqlBulkCopy不熟悉的朋友，請(qǐng)參考《SQLServer中批量插入數(shù)據(jù)方式的性能對(duì)比》。
很多時(shí)候，一個(gè)軟件性能的優(yōu)化，需要從整體去考慮，并不一定是說(shuō)出現(xiàn)數(shù)據(jù)庫(kù)性能問(wèn)題，就一定是DBA的責(zé)任，或者說(shuō)一定是程序員的責(zé)任。在DBA跟程序員之間難道就真的像插銷(xiāo)跟插板之間那樣，職責(zé)分的特別的清楚？很多時(shí)候我們得充分利用存儲(chǔ)過(guò)程的特性，跟.NET平臺(tái)的一些優(yōu)良特性，選擇適合我們的來(lái)進(jìn)行開(kāi)發(fā)，沒(méi)有什么是最佳的，但是對(duì)我們來(lái)說(shuō)，適合我們就好。
從另外的角度考慮，其實(shí)在項(xiàng)目初期，DBA就應(yīng)該參與進(jìn)來(lái)，進(jìn)行數(shù)據(jù)庫(kù)的設(shè)計(jì)了，而一旦數(shù)據(jù)庫(kù)設(shè)計(jì)好了，設(shè)計(jì)得并不規(guī)范，存儲(chǔ)過(guò)程也寫(xiě)了成千上萬(wàn)了，將來(lái)一旦出現(xiàn)性能問(wèn)題，相信也夠DBA喝一壺的。
4. 不愿意被微軟綁架。這個(gè)觀點(diǎn)倒是讓我感覺(jué)到意外，至少我們很多都在用微軟的.NET Framework，我們使用微軟的SQL Server數(shù)據(jù)庫(kù)，如果說(shuō)我們被綁架，可能現(xiàn)在就已經(jīng)被綁架了，SQLServer的存儲(chǔ)過(guò)程跟Oracle、Mysql的存儲(chǔ)過(guò)程是不一樣的，如果將來(lái)進(jìn)行數(shù)據(jù)庫(kù)的遷移，那么可想而知后果是怎樣的。到底怎樣才是真正的被綁架？
關(guān)于這個(gè)問(wèn)題的討論，一直就是個(gè)無(wú)休止的討論。scottgu把這個(gè)比作是“帶有宗教性質(zhì)的技術(shù)爭(zhēng)論”。誠(chéng)然，討論這樣的問(wèn)題的確令人討厭，而且是浪費(fèi)時(shí)間，而且討論的雙方都深切的關(guān)注著。討論來(lái)討論去最終也不會(huì)有結(jié)果。
在目前所運(yùn)行的軟件系統(tǒng)中，我們可以看到其背后的平臺(tái)、語(yǔ)言等是各種各樣，MySpace是基于.NET平臺(tái)的，淘寶網(wǎng)是基于Java的，而Google則推崇使用Python，許多大型的電力系統(tǒng)還依然運(yùn)行在C++平臺(tái)上，最關(guān)鍵的一點(diǎn)，.NET并不是沒(méi)有在大型項(xiàng)目中應(yīng)用。只不過(guò)是Java起步早，.NET起步晚而已，要在前幾年，Java做的大型項(xiàng)目的確是比.NET的大型項(xiàng)目要多。
很多時(shí)候，即使是使用相同的開(kāi)發(fā)語(yǔ)言，不同的程序員開(kāi)發(fā)的程序效率就差30倍以上，甚至幾千倍以上，這點(diǎn)好不夸張。誠(chéng)然，每門(mén)技術(shù)自有其缺點(diǎn)，但它們也都自有其優(yōu)點(diǎn)，如果它的優(yōu)點(diǎn)恰好能符合你的需要，用它就好了。重要的是，你有沒(méi)有使用好它的能力。
總結(jié)
其實(shí)總結(jié)就不必了，說(shuō)點(diǎn)題外話(huà)吧。存儲(chǔ)過(guò)程在單條執(zhí)行操作的時(shí)候，的確要比使用ORM要快，可是如果是執(zhí)行批量的操作，使用存儲(chǔ)過(guò)程就會(huì)非常的費(fèi)勁。之前我是這樣做的。假定更新1000條數(shù)據(jù)，數(shù)據(jù)庫(kù)里只有2個(gè)字段，循環(huán)調(diào)用1000次存儲(chǔ)過(guò)程需要2分鐘左右，當(dāng)時(shí)我把要更新的id以參數(shù)的形式逗號(hào)分隔傳入存儲(chǔ)過(guò)程，在存儲(chǔ)過(guò)程中循環(huán)執(zhí)行1000條數(shù)據(jù)，發(fā)現(xiàn)時(shí)間跟循環(huán)調(diào)用1000次存儲(chǔ)過(guò)程的時(shí)間是差不太多的，最終進(jìn)行了改進(jìn)，改進(jìn)的方法嘛，還是把要更新的Id以參數(shù)形式逗號(hào)分隔傳入存儲(chǔ)過(guò)程，然后使用update table set value=’value’ where id in select id in 分隔函數(shù)(id1,id2,id3…..)，經(jīng)過(guò)這種方式，更新1000條數(shù)據(jù)的時(shí)間從2分鐘變成了200毫秒，可是問(wèn)題依然不完美，方法存在局限性。
首先，使用這種方法參數(shù)的長(zhǎng)度是有限制的，varchar類(lèi)型最大不超過(guò)8000，nvarchar類(lèi)型最大長(zhǎng)度不超過(guò)4000。
其次，如果表中有多個(gè)列，要更新的也是多列，存儲(chǔ)過(guò)程的局限性就出來(lái)了。
再次聲明：文中觀點(diǎn)僅代表個(gè)人觀點(diǎn)，如果您有不同意見(jiàn)，歡迎共同討論。
最后，給大家分享個(gè)幽默視頻，來(lái)緩解下這種緊張而激烈的爭(zhēng)論吧：
NET技術(shù)：數(shù)據(jù)庫(kù)訪問(wèn)的性能問(wèn)題與瓶頸問(wèn)題，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
