上一篇打了資料庫最囉唆的關聯式資料庫，接下來說說noSql
這邊簡單介紹幾種蔽農用過的

相對關聯式資料庫，對於非關聯是資料庫主要就是處理特殊需求的吞吐速度

首先第一位選手Key-Value NoSql:Redis

號稱現有資料庫中戰鬥機

至於爲何稱之爲戰鬥機，就是速度極快(人家資料直接擺RAM，一跳電資料沒持久化可能就直接擊墜)
負載量小(因爲消耗的物理存儲空間是擺RAM，相比其他數據庫可以好幾GB的存，就相對較小)

現在開發上較爲主流的緩存key-value資料庫
使用場景與限制通常如下

1. 讀取次數遠高於寫入次數
2. 查詢方式單一而簡單，時間複雜度O(1)(再不用keys 指令情況下)
3. 雖然有多種數據結構，但終究 只能 由key查詢value
4. 沒有持久化的需求，可以容忍數據丟失，反正丟了再查詢寫入

緊接第二位選手raw data NoSql:Hbase

資料庫中的航空母艦

使用列式儲存，橫向擴展能力(擴增儲存空間)強大，基本如果沒有資料熱點，讀寫是隨便玩不會壞的
也不會有單點故障的問題，但叫航空母艦也直接說明了他非常重，需要依賴許多hadoop組件
雖然擴充容易(廉價機器擺了，拷貝設定就可以擴展)，但第一次環境部屬直接讓我們的白眼翻爆

同樣地來表列式一下使用場景與優缺點

1. 支持海量資料讀寫，且擴展方便
2. 經常將RDB(關聯式資料庫)的資料依據pk取出後存入列中方便查詢
3. 如果沒有明確要查詢key值，用scan查詢能力非常低下，幾乎查不出來那種
4. 沒有分頁功能，因爲根本統計不了有多少資料
5. 非常依賴Row key很吃使用經驗，一個不小心就殺雞用牛刀了

再來是第三位選手文檔型 NoSql:mongoDB

硬要說的話說他是資料庫中的高鐵可能比較合適

身邊很多寫ruby的朋友相當追捧的資料庫類型
支援關聯(但多表無法)，支持事務(但又有點像賣鍋子的廣告，限於單個副本，4.2之後又好像可以支援分片...)
然後裏面的資料如同火車一樣，有時候不取出來根本不知道塞了什麼東西...

同樣地來表列式一下使用場景與優缺點

1. 基本就是可以直接把字段或json整個塞進去
2. 創建索引後可以視爲爲車廂命名，查找速度會變得優異
3. 二級索引並不會輸關聯式資料庫
4. 多表之間join查詢相當麻煩
5. 空間佔用較大，有空間預分配機制，且刪除數據後還需要下指令釋放空間
6. 沒有好用的GUI方便維運

基於以上對於沒有join與強制性數據類型的資料存取相當方便，但因爲若類型，Java工程師就相對少用（本碼農)

再來是最後接下來27天主角Search NoSql:ElasticSearch

因爲是主角所以字打大點，免得評審以爲我文不符題

也不是說對這參加的主題拍馬屁，而是真的剛開始在用這資料庫時有點驚訝
一般關聯型資料庫用"like"字段真的是萬不得已，效能差到不行

elastic就是爲此而生的，工程師都知道分詞跟糢糊查詢等全文搜索很要命
但引入Elastic後所有問題幾乎變得腦殘解

這邊簡單條列下使用場景（因爲爆字了，而且接下來27天要寫這東西)

1. 支援中文分詞，Ex:今晚想來點星巴克->今晚，想來點，星巴克
2. 強大的全文索引，可以從海量資料中撈出晚上喝星巴克的日子
3. 變態級的聚合操作，類似一般關聯型使用group By但功能更加強大
4. 能夠自動發現新的或失敗節點，將資料重組與重新平衡權級，確保數據安全及可訪問

但缺點也是有的

1. 因爲是使用倒排索引然後定期使用Segment File，因此寫入並非實時(但大部分情況仍小於1sec)
2. 非常吃硬體資源數據量大的情況下64G+SSD算是標配
   (所以就知道爲何30天的試用是件就算不會用也要註冊來玩了)

天哪...這篇寫了快兩千字 （如果是別的主題都能拆成三篇了）

但也應該足夠說服碼農們知道自己要在什麼場景用什麼資料庫了
接下來終於要進入正文了