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