NOSQL

基本上你對這個潮流有一些基本的了解，就會知道，所謂的“NOSQL”運動，大多數是指的非“關系數據庫（Relational Database）”。所以，它應該叫“NORDB”更準確一些。我們看看這幾年出現的，“NOSQL”的主要口號：

不使用外鍵關聯、
不使用固定字段格式
MapReduce
KV數據庫
犧牲一致性和完備性，提高性能
使用API接口，而非文本方式訪問
這里我只列舉了想到的一些，歡迎大家補充。我們可以看到，除了最后一條，其它其實與SQL無關。SQL全稱“結構化查詢語言”，是一門語言，它其實不拘于某一種數據庫模型，很多LDAP（層次型數據庫）實現都提供了SQL接口，包括著名的KV數據庫BDB，新版中也有SQL支持。而就算“非關系”這個主題，總的來說，數據庫領域非常的廣大，關系型數據庫雖為主流，但是其它模型的也很多，僅僅簡單的將KV等同于非關系數據庫（不是我亂講，確有一部分同行有此誤解），也不恰當。著名的MongoDB就不是KV模型，CouchDB也不是。NOSQL運動要解決的問題，并不完全由SQL語言引起，也不完全是因為關系模型。

不夸張的說，關系數據庫是近二十年來MIS和互聯網產業得以存在的基礎。沒有關系型數據庫，肯定還是會有C／S和B／S模式，會有動態更新的網站服務，但開發成本會比現在高出很多很多，至少多出兩個數量級毫不夸張。幾個主流的關系型數據庫產品，共同實現了一個不可能的任務：為IT業提供一個同時滿足各種性能和功能需求，使用起來又足夠簡單的，持久化信息存儲平臺。

曾幾何時，軟件／互聯網開發，就是寫一個客戶端或網頁，用來對數據庫的表進行增刪改查，甚至業務邏輯也寫進數據庫，前端只訪問存儲過程。

但是，從那時到現在，已經幾十年過去了，當年被強大好用的關系數據庫掩蓋的各種問題，隨著性能和存儲空間的壓力，逐漸暴露出來。首先單節點的服務器已經不能再滿足數據管理的需要，再強大的主機也存不下潮水般涌入的數據。大多企業是買不起更貴的服務器，買得起的金主，也要考慮世上有沒有容量無限增長的主機。好吧到此為止仍不是關系型數據庫的問題，我們還可以分庫——但是，分庫這個行為已經悄悄開始改變關系數據庫的使用行為。接下來，就是速度問題。

這里仍然回到我前兩篇博客的觀點：計算機不會魔法。很多關系數據庫的應用，其實抽象成鍵值關系，或層次等其它模型，會更貼切，更簡單，于是有更高的性能。