我是一個NoSQLer，一個搞大數據的家伙。這是一個很好的巧合，因為你可能已經聽說，數據增長在失控。

　　舊習難改。關系型數據庫管理系統(RDBMS)仍然居于主導地位。但是，即使你是一個Oracle的鐵桿愛好者，RAC與PL/SQL的忠實信徒，執行以下任務，使用你心愛的技術之前，需要三思而后行：

　　1、搜索：即使是最敬業的Oracle店鋪也不傾向于使用Oracle Text的，甲骨文為其數據庫收購這個擴展，但似乎并沒有非常積極的發展。相反，你會看到很多人使用復雜的查詢，沉重得像運營商。這些結果是粗糙的，能力是薄弱的 - 獲取這些數據，Oracle的方式需要的過程是艱難的。除了甲骨文，許多其他的RDBMS產品并沒有真正的搜索擴展。

　　使用像Hibernate Search，Apache Solr，甚至Autonomy。這樣做可以有更好的擬合指數的性能，以及全文搜索的能力。

　　2、推薦：這是我曾經使用過的ATG Comerce及其他商業產品最糟糕的一部分。它們捕獲大量的用戶數據，從它們試圖提出建議的用戶中。在我曾經的工作，推薦的功能幾乎總是關閉的，因為可擴展性的原因。

　　考慮到社交網絡。如果我想推薦給你襪子，因為你的朋友或朋友的朋友買了襪子，RDBMS變得很糟糕。我們談論的自連接的表和多層次的查詢。這簡直是圖形數據庫像Neo4j的兩行代碼。圍繞RDBMS您可以通過平坦的社交網絡和打零工操作的數據來解決，但你將會失去它的實時性。

　　3、高頻交易(HFT，High-frequency trading)：你可能會認為，交易系統會喜歡RDBMS，因為數據至少是部分事務性的，對不對？這是錯誤的。在某些情況下，高頻交易商是采用和創建NoSQL方法中的第一人。在HFT以低時延為王。當然，如果你陷入了嚴重的泥濘，你可以在你的RDBMS實現低延遲，但它確實沒有為HFT而設計。

　　甲骨文試圖通過收購TimesTen回答這個問題，后者試圖將一個內存數據庫和一個RDBMS相結合，但如果你為卡車配上一只鵝，你沒有可能得到一架飛機。相反，我們看到HFT人群使用key-value存儲如Riak，或更復雜的解決方案如GemFire等。

　　4、產品編目：這不是你聽說過的令人興奮的東西，SQL查詢的最大噩夢之一，是我為映射產品數據而寫過的。當時我與一家移動電話制造商合作，這是為呼叫手機(Callphone) - 除了“標準XYZ”可能意味著幾個不同的實際電話，其中任意一個在不同的市場有不同的名稱。同樣的模式可能有完全不同的組件。管理這些“類”的設備沒有扁平化得非常好。這種場景下，可以使用一個圖形數據庫正是非常之需，如Neo4j。

　　我曾在一家化工企業遇到一個非常類似的問題。我們做了一些非常愚蠢的字符串映射，這是很費力的。如果我們保持這些產品信息在圖形數據庫中，那將是非常容易映射的。即使像CouchBase 2.0或MongoDB這樣的文檔數據庫也可以做得更好。

　　5、用戶/用戶組和ACL：在一定程度上，LDAP是NoSQL數據庫的前身。 LDAP被設計于用戶、組和ACL，它可以像手套一樣適合這類問題。可悲的是，很多人都以LDAP為廢棄品，當技術更新，并且有公司以它做了一些可怕的荒誕的事情。一些企業也建立這樣一個官僚機構，許多開發人員只好欺騙性地創建數據庫表。這違背了集中的用戶訪問控制的目的。 “用戶”和“角色”表應該從任何企業環境走開。