非關係型資料（NoSQL = Not Only SQL）Redis和MongoDB


redis快取技術
shell指令碼程式設計
MongoDB 是一個基於分散式檔案儲存的資料庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴充套件的高效能資料儲存解決方案。
MongoDB 是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。
MongoDB中有三元素：資料庫，集合，文件，其中“集合”就是對應關係資料庫中的“表”，“文件”對應“行”。
MongoDB的視覺化工具robomongo
在插入資料時候即使沒當前列屬性，能橫向插入資料並且儲存
$lt/$lte/$gt/$gte/$ne，依次等價於</<=/>/>=/!=
優點:
- 高可擴充套件性
- 分散式計算
- 低成本
- 架構的靈活性，半結構化資料
- 沒有複雜的關係
缺點:
- 沒有標準化
- 有限的查詢功能（到目前為止）
- 最終一致是不直觀的程式


與關係型資料庫相比，MongoDB的缺點：
一.mongodb不支援事務操作。
 所以事務要求嚴格的系統（如果銀行系統）肯定不能用它。(這點和優點①是對應的)
二.mongodb佔用空間過大。
  關於其原因，在官方的FAQ中，提到有如下幾個方面：
1、空間的預分配：為避免形成過多的硬碟碎片，mongodb每次空間不足時都會申請生成一大塊的硬碟空間，而且申請的量從64M、128M、256M那 樣的指數遞增，直到2G為單個檔案的最大體積。隨著資料量的增加，你可以在其資料目錄裡看到這些整塊生成容量不斷遞增的檔案。

2、欄位名所佔用的空間：為了保持每個記錄內的結構資訊用於查詢，mongodb需要把每個欄位的key-value都以BSON的形式儲存，如果 value域相對於key域並不大，比如存放數值型的資料，則資料的overhead是最大的。一種減少空間佔用的方法是把欄位名儘量取短一些，這樣佔用 空間就小了，但這就要求在易讀性與空間佔用上作為權衡了。我曾建議作者把欄位名作個index，每個欄位名用一個位元組表示，這樣就不用擔心欄位名取多長 了。但作者的擔憂也不無道理，這種索引方式需要每次查詢得到結果後把索引值跟原值作一個替換，再發送到客戶端，這個替換也是挺耗費時間的。現在的實現算是 拿空間來換取時間吧。
3、刪除記錄不釋放空間：這很容易理解，為避免記錄刪除後的資料的大規模挪動，原記錄空間不刪除，只標記“已刪除”即可，以後還可以重複利用。
4、可以定期執行db.repairDatabase()來整理記錄，但這個過程會比較緩慢

三.MongoDB沒有如MySQL那樣成熟的維護工具，這對於開發和IT運營都是個值得注意的地方。




BSON:類json的一種二進位制形式
舉例子：{


title:"MongoDB",


last_editor:"192.168.1.122",


last_modified:new Date("27/06/2011"),


body:"MongoDB introduction",


categories:["Database","NoSQL","BSON"],


revieved:false


}
這是一個簡單的BSON結構體，其中每一個element都是由key/value對組成的







Redis的優點


效能極高 – Redis能支援超過 100K+ 每秒的讀寫頻率。


豐富的資料型別 – Redis支援二進位制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 資料型別操作。


原子 – Redis的所有操作都是原子性的，同時Redis還支援對幾個操作全並後的原子性執行。


豐富的特性 – Redis還支援 publish/subscribe, 通知, key 過期等等特性。


Redis的缺點


是資料庫容量受到實體記憶體的限制,不能用作海量資料的高效能讀寫,因此Redis適合的場景主要侷限在較小資料量的高效能操作和運算上。


總結： Redis受限於特定的場景，專注於特定的領域之下，速度相當之快，目前還未找到能替代使用產品。