資訊專欄INFORMATION COLUMN
摘要：如今數據量越來越大，傳統的關系型數據庫已經無法應付如此大數據的需求了。由此可見，在數據量日漸增長的今天，為了解決大數據量與高并發的難題，應運而生。的消息存儲采用的就是數據庫，支持大數據進行隨機實時訪問。
引言
打開Microsoft To-Do，發現Redis的學習計劃還躺在那里。
其實我對Redis的理解，僅僅停留在我認識這個單詞的層面上。
學習 簡介本來對這個Redis沒什么興趣的，不就是一個緩存的數據庫而已嗎？直到上次配置spring-redis的時候，發現這個東西沒有用戶名。
spring:
redis:
host: 127.0.0.1
port: 6379
password:
配置如上所示，只有主機、端口和密碼，和普通的MySQL或其他數據庫不同。
Redis是一個使用ANSI C編寫的開源、支持網絡、基于內存、可選持久性的鍵值對存儲數據庫。
我們熟知的就是Redis的緩存，Redis采用C編寫，運行異常的快。是有磁盤存儲支持的內存數據庫！
適用于數據變化快且數據庫大小可遇見（適合內存容量）的應用程序。
使用場景：股票價格、數據分析、實時數據搜集、實時通訊。
NoSQLRedis屬于NoSQL，NoSQL = Not Only SQL。
如今數據量越來越大，傳統的關系型數據庫已經無法應付如此大數據的需求了。
舉個例子：假設我們使用關系型數據庫存儲朋友圈，那一天會產生多少數據？再查詢的時候數據庫不就死了嗎？
這讓我想起了我之前關注的一個帖子：騰訊微信的后臺數據庫到底是怎么設計的？無知的人相談甚歡，最后好像是官方的哥們是在看不下去了，回復：誰告訴你們微信用的是關系型數據庫？
普通關系型數據庫，如果只查詢的話效率很高？如果算上讀寫的話？那可能傳統的數據庫都承受不住高并發。
重要的是關系型數據庫沒法擴展，大家想一想，因為數據之間是有關系的，所以數據庫擴展絕對不像擴展后臺服務規模一樣再拎個服務器出來那么簡單。
由此可見，在數據量日漸增長的今天，為了解決大數據量與高并發的難題，NoSQL應運而生。
NoSQL產品主要有四類：
| 類型 | 特點 | 代表 | 適用場景 |
|---|---|---|---|
| 鍵值對存儲 | 能實現快速查詢，但存儲的數據缺少結構化 | Redis | 內容緩存，主要用于處理大數據的高訪問負載 |
| 列存儲數據庫 | 查找速度快，可擴展性強，更容易進行分布式擴展，但功能相對局限 | HBase | 分布式的文件系統 |
| 文檔數據庫 | 數據結構要求不嚴格，查詢性能不高，而且缺乏統一的查詢語法 | MongoDB | Web應用(相較于普通的Key-Value，其Value是結構化的) |
| 圖形數據庫 | 利用圖結構相關算法，但需要對整個圖做計算才能得出結果，不容易分布式 | Neo4j | 社交網絡，推薦系統，專注于構建關系圖譜 |
這些數據庫的名稱大家或多或少應該聽說過吧？今天才真正知道它們的作用，各有其特長，我們需根據業務場景動態選擇。Facebook的消息存儲采用的就是HBase數據庫，支持大數據進行隨機、實時訪問。
NoSQL因為數據之間都是沒有關系的，所以易擴展，同時具有很高的讀寫性能，很適合高并發場景。
歷史2008年，意大利的一家創業公司Merzia推出了一款基于MySQL的網站實時統計系統LLOOGG。
沒過多久，創始人Salvatore Sanfilippo對MySQL的性能大失所望，于是他決定自己寫一個數據庫。牛人就是牛人，我們就算質疑MySQL的性能，想寫也寫不出來啊？！
2009年，Salvatore Sanfilippo完成了數據庫的編寫，這就是Redis。
Salvatore Sanfilippo將Redis開源，并一直進行著Redis的開發，直到今天。我們熟知的Github、StackOverflow、新浪微博等公司都是Redis的用戶。
緩存傳統的緩存代碼需要這樣寫，很冗長，都是重復的代碼。
