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

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

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

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

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

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

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

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

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

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

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

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

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

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

8. 電子郵件:我知道，這一點幾乎已經(jīng)成為共識。在項目完成、著手將電子郵件整理到RDBMS當中時，我發(fā)現(xiàn)很多人已經(jīng)明白：電子郵件實際是一種具備適度非結(jié)構(gòu)化特性的元數(shù)據(jù)，而關系數(shù)據(jù)庫并不擅長存儲這類資料。我們已經(jīng)盡可能對RDBMS進行了優(yōu)化，最大程度修整BLOB等相關組件。然而電子郵件管理工作涉及到元數(shù)據(jù)、搜索以及內(nèi)容，這些東西之間并沒有明顯的關聯(lián)代數(shù)可供參考，而且與交易扯不上關系。關系數(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. 時間排序/預報: 這一點在本文的十大排行中最具普遍性，但其具體表現(xiàn)形式卻多種多樣，從商品到數(shù)據(jù)分析再到太陽黑子預測都包含在內(nèi)。關系數(shù)據(jù)庫在時間排序問題方面的表現(xiàn)一直飽受爭議。當然，現(xiàn)在情況已經(jīng)大大改善;而且經(jīng)過過去十幾年的努力，RDBMS在與時間有關的處理效率及功能方面已經(jīng)擺脫了嚴重缺陷的尷尬境地、取得了令人矚目的進步。然而如果大家把時間類任務作為主要處理對象，那么像Cassandra這樣能夠與MapReduce列簇產(chǎn)品家族良好對接的方案無疑更為理想。Datastax公司已經(jīng)明顯指出，其Cassandra發(fā)行版將支持時間排序數(shù)據(jù);其它一些供應商也紛紛在產(chǎn)品中推出類似功能。

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

更多信息請查看IT技術專欄