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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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