關系數據庫和十樣事物不能混為一談

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　除了前面所提到的內容，大家還在哪些領域使用RDBMS?我和大家一樣，每天都離不開RDBMS;但它真的是最好的解決方案嗎?不一定。也許某些老頑固會努力為RDBMS開脫，但我們得承認，單單是使用習慣遠不足以支持關系數據庫一路走下去——在恰當的情況下使用恰當的工具方為明智之舉。