NoSQL

目前的許多的網站 越來越多開發者使用所謂的NoSQL的資料庫來取代原有的關聯性資料庫
我只是就我所瞭解的幾個點來分析一下 究竟在怎樣的情況使用傳統的關聯性資料庫 怎樣的情況 我會考慮選擇使用NoSQL類型的資料庫
1. data scale
NoSQL被重新拿出來實作 最主要的一個需求 應該是在像Google或是Facebook等網站 對於大量資料存取的需求. 他們的需求 並不是Mega或是Giga等級的資料數量 而是全世界的使用者 每天
都有數Tera byte的user gererate data需要被分析. 在這種數量級的資料傳統的SQL很快就會達到他的極限 一般來說MySQL在處理千萬筆資料的時候效能就開始變差 而Oracle比較好 在billion的資料數量級都還可以表現的不錯 不過通常NoSQL處理的資料數量等級是每天可能就會新增一billion的資料 在那種資料量需求之下 NoSQL相較之下 就會很突出
2. transaction require
在很多分析的文章中會提到ACID與BASE的比較 或是CAP的理論
我從實際maintain的角度來看 如果系統出現異常 某些資料庫當機了 這時候有兩種選擇

某些資料 壞掉或是不ㄧ致的狀況是可以被允許的 事後不需要修復相關的資料 (像facebook的訊息錯掉 大部份是沒關係的 使用者並不會來要求修復資料) 可是系統不能整個停掉也就是不能有single point failure. Service的品質重要性高於資料正確性 這種類型的應用就NoSQL可能會比較好
相反的有些類型的服務 系統ㄧ致性的重要性遠高於系統的穩定性 像是Billing或是Payment系統好了 如果系統有異常會導致資料錯誤 我們寧願讓系統下線也不願意錯誤的資料持續進來 這種類型的系統 可能傳統的資料庫會比較符合我們的需求

Facebook與VISA或是銀行帳務系統是兩種應用光譜的極端 一種是RDBM系列 一個是NoSQL系列的 可是在大部份著情況 可能不是那麼極端 或許就有一些其他的因素可以考慮在內
3 query and index
目前的NoSQL雖然有部份已經能支援簡單的query 可是跟RDBM比起來還是非常的原始 只支援key value pair的查詢 對於application的開發來說 其實是很大的一個限制. 更不用說需要作filter或是order by的查詢 如果那些功能對你來說很重要 那還是乖乖的用RDBM吧
但是如果你所開發的程式可以透過簡單的演算法避開所有的查詢 (或是直接請需求端把所有 不重要的query拿掉) 那或許NoSQL還有機會

4. failure tolerate.
在read only的系統 其實兩者的差別並沒有那麼多 因為RDBM可能透過multiple slave的方式自動的把資料replicate到許多node上即使ㄧ兩個node死了 也不會影響系統讀取的動作
差別主要在於write的動作 以設計面來說NoSQL的service quality絕對會比傳統的資料庫好 當然這個差別並不是沒有代價的 以資料來說一個資料commit 可能只是master成功了 可是slave都還沒有sync 也有可能是所有node全部都update完成才算是成功 或是有N個node只要有其中兩三個node成功就算是寫入成功 這三種策略對於系統的反應時間與系統寫入失敗的機會就有很大的差別
如果寫入一個master node就算成功 寫入的速度會比較好 因為不需要將後面數十個node都update好了才能回應給client端省下了不少反應時間 可是寫入的機器可能就是single point failure. 而且 NoSQL通常用的就不是single master而是multi master並且是自動fail over的機制 直覺上看來multi master應該是比較好 為什麼RDBM不這樣實作呢 這個就又回到兩種資料庫基本的設計理念的不同了 當資料的consistent很重要時 NoSQL這種方式有時候是會出問題的 因為他基本上就是用consistent 換取了 availability.
通常一個record如果資料replicate成N份的話 如果資料內容不ㄧ致 問題就在於我們要相信哪份資料 而且每次read可能並不能aware到有這樣的不一致 如果這個資料的內容是賬戶的餘額的話 問題就很大了 我究竟要相信那份資料 而有些transaction是跟command的前後order與內容強烈相關的 像兩筆交易如果會把餘額扣光 那兩筆成功的順序就變得非常的critical 如果這時候有幾個node之間資料不一致的狀況的話 那問題會變得非常複雜 所以才會說有transaction相關的資料 會建議保守的用RDBM就好了