隨著數據存儲技術的迅猛發展，隨著各種 NoSQL 技術的產生，無論是我們同事之間還是整個互聯網行業，都出現關于“分布式 數據 存儲/處理 解決方案”方面的選擇分歧。就我目前所了解到的主流意見主要有以下三種：

• 去關系型，NoSQL是王道
• NoSQL靠邊站，關系型才是王道
• 以關系型為核心，NoSQL為補充

三種意見中前面兩種觀點較為極端，都是“非對即錯”的選擇，當然也有更為理性的第三種方案。

如果作為開發人員，從我目前所了解的信息來看，主要還是傾向于第一種思路。因為在他們看來，分布式的 NoSQL 系統是一個非常美的架構，不僅僅解決了擴展性的問題，同時也解決了可靠性問題，同時還可以讓程序開發免去關系型模型的約束，不選擇他才是傻子呢！

從我個人的角度來看，我目前更傾向于第三種思路，至少在現階段是如此。

Why？

但是如果是從運維的角度出發，所考慮的風險點可能完全不一樣。作為一個存儲數據的核心組件，在需要對其數據進行人工訂正維護的時候是否方便操作？在需要抽取其中某部分數據到線下給開發/測試部門使用的時候是否方便？最重要的是，當他整個 Crash 之后我們可以怎么恢復？當我們面對這些問題的時候，我們是否有合適便利的手段來避免或者解決？

確實，理念很完美，架構很完美，但目前的NoSQL產品的實現是不是真的也如此完美呢？我想沒有哪個產品敢拍著自己的胸脯說他們的產品不會Crash，就像沒有廠商向我們保證他們的硬件在達到標稱的使用壽命之前不會損壞一樣。既然存在整個 Crash 的可能，那就必須考慮如何應對。我們不能只是考慮這個聽上去完美的分布式系統在某個節點 Crash 之后可以很好的”自愈”，不能只考慮當目前整個集群資源達到瓶頸之后僅僅只需要在線增加一個節點就可以”自我完成負載/數據重分布”。我們還需要考慮他的整體可靠性，還需要考慮更為惡劣的環境更為殘酷的場景下，他是否還能生存。

關系型數據庫在剛開始產生的時候，同樣面臨了各種各樣的問題，同樣受到過大量的質疑。但是，當他在風風雨雨中走過了這么多年之后，通過不斷的完善和適應，不論在災難恢復方面還是在可操作性和可維護性方面都做了大量的工作。當然，在這么多年的市場需求下，也培養出了大量的專業技術人員。但 NoSQL 發展到現在，才經歷了很短的時間，缺少在惡劣環境下的磨煉，缺少復雜環境下的檢驗，更缺少有豐富經驗的專業技術人員。在這種情況下，你還敢輕易決定將一個公司最為核心的資本（數據）輕易從關系型數據庫中遷移出來嗎？

當然，我們并不一定要一個完美的產品，就像我們無法讓我們自己成為一個完美的人一樣。但我們必須清楚一個產品的可能存在的風險和缺陷，并且清楚如何做能避免這些風險和缺陷，同時還要讓我們自己有能力避免這些風險和缺陷。只有在這樣的前提下，我們才會在比較重要的場景下使用。但要積累這些經驗，積累這些信任，培養專業技術人員，都需要一定的時間。

所以在我個人看來，在近幾年，NoSQL 暫時還不可能成為數據管理軟件領域的主角，仍然只能作為特定場景下的數據存/取解決方案的補充，即使在互聯網行業也是如此。至于在未來，比如五年十年以后會是什么樣子，我就無法預測了。

注：文中觀點僅代表個人，基于個人目前的認知，歡迎大家拍磚！