關(guān)系數(shù)據(jù)庫管理系統(tǒng)仍然穩(wěn)居業(yè)界主導(dǎo)之地位。然而即使大家是徹頭徹尾的甲骨文粉兒、為老式RAC中的PL/SQL架構(gòu)所深深吸引，也請穩(wěn)下心神、保持冷靜。時代不同了，如今我們需要在著手執(zhí)行任務(wù)之前認(rèn)真考量，而絕不能僅憑個人好惡來選擇解決方案。本文列出了十件事，是大家在使用關(guān)系數(shù)據(jù)庫的時候一定要避免的。

我是位NoSQL用戶，同時在大數(shù)據(jù)方面也廣有涉獵。這種技能組合相當(dāng)應(yīng)景，正如大家所看到，如今數(shù)據(jù)庫技術(shù)人員討論最多的可能就是“數(shù)據(jù)增長失控”這個話題。

正所謂“積習(xí)難改”，關(guān)系數(shù)據(jù)庫管理系統(tǒng)仍然穩(wěn)居業(yè)界主導(dǎo)之地位。然而即使大家是徹頭徹尾的甲骨文粉兒、為老式RAC中的PL/SQL架構(gòu)所深深吸引，也請穩(wěn)下心神、保持冷靜。時代不同了，如今我們需要在著手執(zhí)行任務(wù)之前認(rèn)真考量，而絕不能僅憑個人好惡來選擇解決方案。

1. 搜索: 即使是最敬業(yè)的甲骨文專家也會盡量避免使用Oracle Text組件。盡管甲骨文公司斥資將其納入自家數(shù)據(jù)庫產(chǎn)品，但其實(shí)際表現(xiàn)相當(dāng)乏善可陳。相反，我們會看到很多用戶還在使用like及or等命令實(shí)現(xiàn)復(fù)雜的查詢工作。由此引發(fā)的結(jié)果自然是使用者抱怨?jié)M載、實(shí)際性能羸弱不堪——而且甲骨文公司所設(shè)定的數(shù)據(jù)獲取方式本身也令人極為惱火。當(dāng)然，甲骨文并不是惟一一家在搜索功能方面有所欠缺的廠商。除他們之外，大多數(shù)其它RDBMS產(chǎn)品也沒能實(shí)現(xiàn)真正的搜索擴(kuò)展。

在Hibernate Search、Apache Solr或者Autonomy的幫助下，我們能夠獲得更好的檢索性能表現(xiàn)。別猶豫，讓它們成為大家全文本搜索工作中的有力助手吧。

2. 推薦: 我用過大量ATG及其它商用類產(chǎn)品，這項(xiàng)功能絕對是我見到最令人無法忍受的東西。產(chǎn)品會追蹤使用者的大量日常信息，并嘗試推薦用戶可能需要的其它產(chǎn)品。凡是我工作過的地方，一般都會出于可擴(kuò)展性方面的考慮而把一切推薦功能第一時間關(guān)閉掉。

大家不妨設(shè)想社交網(wǎng)絡(luò)的運(yùn)行情況。如果我希望某位用戶能夠購買他(她)的朋友以及朋友的朋友所選購的襪子，這種跨越式關(guān)系會讓RDBMS非常被動。要實(shí)現(xiàn)這一訴求，我們需要采用自連接表格與多查詢層。這很像是Neo4j等圖形類數(shù)據(jù)庫中的兩行代碼。雖然大家可以通過對社交網(wǎng)絡(luò)架構(gòu)的預(yù)扁平化及數(shù)據(jù)臨時調(diào)整達(dá)成目標(biāo)，但這也會令關(guān)系數(shù)據(jù)庫失去其實(shí)時性。

3. 頻繁交易: 大家可能會以為交易系統(tǒng)是RDBMS的長項(xiàng)所在，因?yàn)閿?shù)據(jù)多少都會蘊(yùn)含一些交易屬性，不是嗎?錯。我甚至懷疑第一個將頻繁交易通過NoSQL實(shí)現(xiàn)的操作者就是NoSQL開發(fā)團(tuán)隊(duì)中的一員。頻繁交易活動中，低延遲是最關(guān)鍵也最寶貴的因素。沒錯，如果大家跳出固有思路，也能在RDBMS中獲得較低的延遲效果——但我還是提醒各位，關(guān)系數(shù)據(jù)庫在設(shè)計上并不適合這類任務(wù)。

甲骨文公司試圖通過收購TimesTen來解決這一難題，后者一直在努力將內(nèi)存數(shù)據(jù)庫與RDBMS相結(jié)合——然而上車就算加了翅膀也不會變成飛機(jī)，我們只能把這看作一定程度上的小小改善。相反，我們倒是發(fā)現(xiàn)很多頻繁交易操作者自發(fā)選擇Riak等鍵-值方案甚至是更為復(fù)雜的Gemfire。

4. 產(chǎn)品目錄: 這一條看上去似乎平淡無奇，但我曾在之前的文章中談到，我個人工作中最可怕的SQL查詢噩夢之一正是產(chǎn)品數(shù)據(jù)映射工作。當(dāng)時我正為一家移動電話制造商工作。手機(jī)這東西大家都知道，同一個型號“XYZ”有可能代表著多款機(jī)型，而且這些機(jī)型在不同的市場中還被賦予了不同的“昵稱”。甚至同一款機(jī)型也會使用多種差異化組件。要想對這類復(fù)雜而模糊的“類”進(jìn)行扁平化處理簡直難于登天，因此在處理此類工作時，以Neo4j為代表的圖形類數(shù)據(jù)庫就成了上上之選。

后來我供職于一家化工企業(yè)時也遇到過類似的問題。當(dāng)時我們選擇的字符映射方案非常愚蠢、極耗人力。而在把產(chǎn)品信息轉(zhuǎn)移到圖形類數(shù)據(jù)庫中后，映射工作就變得簡單易行了。甚至像CouchBase 2.0或者M(jìn)ongoDB這樣的文件數(shù)據(jù)庫都比關(guān)系數(shù)據(jù)庫表現(xiàn)得更好。

5. 用戶/群組與ACL: 在某種角度來看，LDAP其實(shí)就是最原始的NoSQL數(shù)據(jù)庫。LDAP專門為用戶、群組及ACL所設(shè)計，能夠恰到好處地滿足此類需求。遺憾的是，很多人都出于誤解而將其作為新技術(shù)的衍生品，企業(yè)也試圖用它來處理某些荒謬甚至可怕的任務(wù)。還有不少公司用它建立起一套官僚意味濃厚的管理機(jī)制，許多開發(fā)人員為了免受影響只能被迫通過篡改數(shù)據(jù)庫表格來維護(hù)日常工作流程。這顯然有違集中式用戶訪問控制的初衷。我認(rèn)為，“用戶”與“角色”等表格在任何企業(yè)環(huán)境下都毫無必要，應(yīng)當(dāng)早日摒棄。

6. 日志分析: 如果大家還不清楚這方面問題的危害，不妨打開Hadoop或者小型集群服務(wù)器版本RHQ/JBossON中的日志分析功能，設(shè)定日志級別、讓日志捕捉除錯誤之外的其它信息。執(zhí)行過程越復(fù)雜、我們的工作狀態(tài)也就越混亂?？梢钥吹?，像日志信息這樣多少帶有些非結(jié)構(gòu)化特性的數(shù)據(jù)，正是MapReduce公司的Hadoop以及像PIG這樣的語言所擅長的領(lǐng)域。然而我們遺憾地看到目前各類主流監(jiān)控工具仍然在以RDBMS為主要對象——關(guān)系數(shù)據(jù)庫根本不需要這么多分析及匯總工作，低延遲才是其最大賣點(diǎn)及首要訴求。

7. 媒體資源庫: 雖然保存元數(shù)據(jù)的效果還算可以(其實(shí)Couchbase 2.0或者M(jìn)ongoDB在這方面表現(xiàn)更好)，不過RDBMS中的BLOB在經(jīng)過了多年的演變后仍然很不給力。大家最好為自己的圖像及其它二進(jìn)制文件選擇某種類型的分布式存儲方案或集群文件系統(tǒng)。盡管表現(xiàn)令人失望，許多CMS引擎仍然會把一切存儲任務(wù)都推給RDBMS，這也是大家需要注意的一點(diǎn)。

8. 電子郵件:我知道，這一點(diǎn)幾乎已經(jīng)成為共識。在項(xiàng)目完成、著手將電子郵件整理到RDBMS當(dāng)中時，我發(fā)現(xiàn)很多人已經(jīng)明白：電子郵件實(shí)際是一種具備適度非結(jié)構(gòu)化特性的元數(shù)據(jù)，而關(guān)系數(shù)據(jù)庫并不擅長存儲這類資料。我們已經(jīng)盡可能對RDBMS進(jìn)行了優(yōu)化，最大程度修整BLOB等相關(guān)組件。然而電子郵件管理工作涉及到元數(shù)據(jù)、搜索以及內(nèi)容，這些東西之間并沒有明顯的關(guān)聯(lián)代數(shù)可供參考，而且與交易扯不上關(guān)系。關(guān)系數(shù)據(jù)庫本身的文件系統(tǒng)沒有問題，只是文件類數(shù)據(jù)庫在處理元數(shù)據(jù)時表現(xiàn)更出色。

9. 分類廣告: 廣告是一種規(guī)模龐大的信息集合，海量用戶查詢及發(fā)布這類數(shù)據(jù)，其內(nèi)容短小卻極具吸引力。Craigslist這家知名廣告網(wǎng)站使用的正是文件類數(shù)據(jù)庫MongoDB，它擅長搜索、打理元數(shù)據(jù)、非常適合廣告的固有特性，連信息一致性也有足夠的保障。面對幾乎等于是為廣告量身打造的文件類數(shù)據(jù)庫，RDBMS最好的選擇就是繞道而行。

10. 時間排序/預(yù)報: 這一點(diǎn)在本文的十大排行中最具普遍性，但其具體表現(xiàn)形式卻多種多樣，從商品到數(shù)據(jù)分析再到太陽黑子預(yù)測都包含在內(nèi)。關(guān)系數(shù)據(jù)庫在時間排序問題方面的表現(xiàn)一直飽受爭議。當(dāng)然，現(xiàn)在情況已經(jīng)大大改善;而且經(jīng)過過去十幾年的努力，RDBMS在與時間有關(guān)的處理效率及功能方面已經(jīng)擺脫了嚴(yán)重缺陷的尷尬境地、取得了令人矚目的進(jìn)步。然而如果大家把時間類任務(wù)作為主要處理對象，那么像Cassandra這樣能夠與MapReduce列簇產(chǎn)品家族良好對接的方案無疑更為理想。Datastax公司已經(jīng)明顯指出，其Cassandra發(fā)行版將支持時間排序數(shù)據(jù);其它一些供應(yīng)商也紛紛在產(chǎn)品中推出類似功能。

除了前面所提到的內(nèi)容，大家還在哪些領(lǐng)域使用RDBMS?我和大家一樣，每天都離不開RDBMS;但它真的是最好的解決方案嗎?不一定。也許某些老頑固會努力為RDBMS開脫，但我們得承認(rèn)，單單是使用習(xí)慣遠(yuǎn)不足以支持關(guān)系數(shù)據(jù)庫一路走下去——在恰當(dāng)?shù)那闆r下使用恰當(dāng)?shù)墓ぞ叻綖槊髦侵e。

更多信息請查看IT技術(shù)專欄