開發者擁抱NoSQL的5個階段

相信很多開發者都有個疑問，如果以一種簡單、靈活的方法來存儲程序數據，應該選擇NoSQL還是SQL呢？

NoSQL數據庫提供了非常完美的體驗：一個安裝包，啟動數據庫，使用JSON API進行數據讀寫操作。此外，NoSQL支持快速迭代。

SQL方案需要更多的預先投資：配置服務器，插入數據，設定數據表，以對象關系映射系統來進行數據獲取。

兩者對比權衡，創業公司更青睞NoSQL。那么要擁抱NoSQL，需要經歷哪些階段呢？

階段一：排除

決定使用NoSQL便意味著你做出了兩個重要決定：無需ACID事務和無需一個架構。這看起來是無害的，但是其結果會對程序產生深遠影響。

排除的第一種形式是你不需要ACID事務。這在應用的早期階段常見，但是隨著用戶規模增長，事務處理的邏輯能力將會使你的程序更易于運作。所以完全放棄事務是不可取的。

排除的第二種形式是不需要架構。這意味著程序可以有效處理數據間的邏輯，而無需借助傳統關系型數據庫的關系處理能力。

階段二：憤怒

NoSQL數據庫的設計目的是在分布式機器集群中取得連續性和可用性的平衡。因此，你不得不使用復雜的分布式算法來進行協調，同步和錯誤處理。

某天當你發現數據丟失而憤怒不已時，將發現事務和架構是多么重要。

階段三：商討

當憤怒消退后，或許你會嘗試把事務和架構補充回NoSQL中。首先是為應用程序編寫事務管理器。但是交易系統通常很龐雜，模塊之間相互依賴，涉及到并發控制，錯誤恢復和權限訪問。你可能會成功，但最終的結果將很難進行擴展或維護。

第二個方法是使用復雜組織條件和處理來增強數據整合，確保數據完整性。這些規則嵌入在應用程序邏輯并需要傳達給每個使用該數據庫的開發團隊。

階段四：沮喪

當為你找出一個可行的事務處理方案和一個臨時的架構處理方案時，你可能發現你的NoSQL不能很好地處理其它需求。它不能聯接表，不能對記錄進行分組，更不必說復雜的查詢。這時你會變得沮喪，試圖尋求集群運維專家的幫忙。

階段五：接受

看來NoSQL也有其不足之處。最后接受這個事實，你批判性地評估自己的數據庫解決方案。你試圖區分數據中哪些屬于關系型哪些不屬于關系型。最終，找出一個使NoSQL和關系型數據庫友好共處的方案：擴展關系型滿足一部分需求，擴展NoSQL滿足另外一部分需求。

被媒體廣泛宣傳的新技術，必須經過個人實踐，找出適合自己的部分才是有價值的；否則，拔苗助長，生搬硬套只會徒增煩惱。

來自：http://geek.csdn.net/news/detail/105774