NoSQL概述

為什么用NoSQL

1、單機(jī)MySQL的美好年代

在90年代，一個(gè)網(wǎng)站的訪問(wèn)量一般不大，用單個(gè)數(shù)據(jù)庫(kù)完全可以輕松應(yīng)付！
在那個(gè)時(shí)候，更多的都是靜態(tài)網(wǎng)頁(yè)，動(dòng)態(tài)交互類型的網(wǎng)站不多。
上述架構(gòu)下，我們來(lái)看看數(shù)據(jù)存儲(chǔ)的瓶頸是什么？

1. 數(shù)據(jù)量的總大小，一個(gè)機(jī)器放不下時(shí)
2. 數(shù)據(jù)的索引（B+ Tree）一個(gè)機(jī)器的內(nèi)存放不下時(shí)
3. 訪問(wèn)量（讀寫混合）一個(gè)實(shí)例不能承受
   如果滿足了上述 1 or 3個(gè)，進(jìn)化…
   DAL：數(shù)據(jù)庫(kù)訪問(wèn)層
   

2、Memcached（緩存）+ MySQL + 垂直拆分

后來(lái)，隨著訪問(wèn)量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫(kù)上都開始出現(xiàn)了性能問(wèn)題，web程序不再僅僅專注在功能上，同時(shí)也在追求性能。程序猿們開始大量使用緩存技術(shù)來(lái)緩解數(shù)據(jù)庫(kù)的壓力，優(yōu)化數(shù)據(jù)庫(kù)的結(jié)構(gòu)和索引，開始比較流行的是通過(guò)文件緩存來(lái)緩解數(shù)據(jù)庫(kù)壓力，但是當(dāng)訪問(wèn)量繼續(xù)增大的時(shí)候，多臺(tái)web機(jī)器通過(guò)文件緩存不能共享，大量的小文件緩存也帶了比較高的IO壓力，在這個(gè)時(shí)候，Memcached就自然的成為一個(gè)非常時(shí)尚的技術(shù)產(chǎn)品。

3、MySQL主從讀寫分離

緩存主要解決讀的問(wèn)題

由于數(shù)據(jù)庫(kù)的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫(kù)的讀取壓力，讀寫集中在一個(gè)數(shù)據(jù)庫(kù)上讓數(shù)據(jù)庫(kù)不堪重負(fù)，大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來(lái)達(dá)到讀寫分離，以提高讀寫性能和讀庫(kù)的可擴(kuò)展性，MySQL的master-slave模式成為這個(gè)時(shí)候的網(wǎng)站標(biāo)配了

4、分表分庫(kù) + 水平拆分 + Mysql 集群

在Memcached的高速緩存，MySQL的主從復(fù)制，讀寫分離的基礎(chǔ)之上，這時(shí)MySQL主庫(kù)的寫壓力開始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會(huì)出現(xiàn)嚴(yán)重的鎖問(wèn)題，大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。同時(shí)，開始流行使用分表分庫(kù)來(lái)緩解寫壓力和數(shù)據(jù)增長(zhǎng)的擴(kuò)展問(wèn)題，這個(gè)時(shí)候，分表分庫(kù)成了一個(gè)熱門技術(shù)，是面試的熱門問(wèn)題，也是業(yè)界討論的熱門技術(shù)問(wèn)題。也就是在這個(gè)時(shí)候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術(shù)實(shí)力一般的公司帶來(lái)了希望。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足互聯(lián)網(wǎng)的需求，只是在高可靠性上提供了非常大的保證。

5、MySQL 的擴(kuò)展性瓶頸

MySQL數(shù)據(jù)庫(kù)也經(jīng)常存儲(chǔ)一些大文本的字段，導(dǎo)致數(shù)據(jù)庫(kù)表非常的大，在做數(shù)據(jù)庫(kù)恢復(fù)的時(shí)候就導(dǎo)致非常的慢，不容易快速恢復(fù)數(shù)據(jù)庫(kù)，比如1000萬(wàn)4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變的非常的小，關(guān)系數(shù)據(jù)庫(kù)很強(qiáng)大，但是它并不能很好的應(yīng)付所有的應(yīng)用場(chǎng)景，MySQL的擴(kuò)展性差（需要復(fù)雜的技術(shù)來(lái)實(shí)現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當(dāng)前使用MySQL的開發(fā)人員面臨的問(wèn)題

6、今天是什么樣子？？

7、為什么用NoSQL？

今天我們可以通過(guò)第三方平臺(tái)（如：Google，F(xiàn)aceBook等）可以很容易的訪問(wèn)和抓取數(shù)據(jù)。用戶的個(gè)人信息，社交網(wǎng)絡(luò)，地理位置，用戶生成的數(shù)據(jù)和用戶操作日志已經(jīng)成倍的增加、我們?nèi)绻獙?duì)這些用戶數(shù)據(jù)進(jìn)行挖掘，那SQL數(shù)據(jù)庫(kù)已經(jīng)不適合這些應(yīng)用了，而NoSQL數(shù)據(jù)庫(kù)的發(fā)展卻能很好的處理這些大的數(shù)據(jù)！

什么是NoSQL

NoSQL

NoSQL = Not Only SQL，意思：不僅僅是SQL；
泛指非關(guān)系型的數(shù)據(jù)庫(kù)，隨著互聯(lián)網(wǎng)Web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)在應(yīng)付web2.0網(wǎng)站，特別
是超大規(guī)模和高并發(fā)的社交網(wǎng)絡(luò)服務(wù)類型的Web2.0純動(dòng)態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服
的問(wèn)題，而非關(guān)系型的數(shù)據(jù)庫(kù)則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展，NoSQL數(shù)據(jù)庫(kù)的產(chǎn)生就是為
了解決大規(guī)模數(shù)據(jù)集合多種數(shù)據(jù)種類帶來(lái)的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題，包括超大規(guī)模數(shù)據(jù)的存儲(chǔ)。
（例如谷歌或Facebook每天為他們的用戶收集萬(wàn)億比特的數(shù)據(jù)）。這些類型的數(shù)據(jù)存儲(chǔ)不需要固定的模
式，無(wú)需多余操作就可以橫向擴(kuò)展。

NoSQL的特點(diǎn)

1、易擴(kuò)展

NoSQL 數(shù)據(jù)庫(kù)種類繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫(kù)的關(guān)系型特性。
數(shù)據(jù)之間無(wú)關(guān)系，這樣就非常容易擴(kuò)展，也無(wú)形之間，在架構(gòu)的層面上帶來(lái)了可擴(kuò)展的能力。

2、大數(shù)據(jù)量高性能

NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫性能，尤其是在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的非關(guān)系
性，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。
一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大力度的Cache，在針對(duì)Web2.0的
交互頻繁應(yīng)用，Cache性能不高，而NoSQL的Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL
在這個(gè)層面上來(lái)說(shuō)就要性能高很多了。
官方記錄：Redis 一秒可以寫8萬(wàn)次，讀11萬(wàn)次！

3、多樣靈活的數(shù)據(jù)模型

NoSQL無(wú)需事先為要存儲(chǔ)的數(shù)據(jù)建立字段，隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式，而在關(guān)系數(shù)據(jù)庫(kù)里，增刪
字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡(jiǎn)直就是噩夢(mèng)。

4、傳統(tǒng)的RDBMS VS NoSQL

傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù) RDBMS
- 高度組織化結(jié)構(gòu)化數(shù)據(jù)
- 結(jié)構(gòu)化查詢語(yǔ)言（SQL）
- 數(shù)據(jù)和關(guān)系都存儲(chǔ)在單獨(dú)的表中
- 數(shù)據(jù)操縱語(yǔ)言，數(shù)據(jù)定義語(yǔ)言
- 嚴(yán)格的一致性
- 基礎(chǔ)事務(wù)
NoSQL
- 代表著不僅僅是SQL
- 沒(méi)有聲明性查詢語(yǔ)言
- 沒(méi)有預(yù)定義的模式
- 鍵值對(duì)存儲(chǔ)，列存儲(chǔ)，文檔存儲(chǔ)，圖形數(shù)據(jù)庫(kù)
- 最終一致性，而非ACID屬性
- 非結(jié)構(gòu)化和不可預(yù)知的數(shù)據(jù)
- CAP定理
- 高性能，高可用性 和 可伸縮性

拓展：3V+3高

大數(shù)據(jù)時(shí)代的3V ： 主要是對(duì)問(wèn)題的描述
海量 Volume
多樣 Variety
實(shí)時(shí) Velocity
互聯(lián)網(wǎng)需求的3高 ： 主要是對(duì)程序的要求
高并發(fā)
高可用
高性能
當(dāng)下的應(yīng)用是 SQL 和 NoSQL 一起使用，技術(shù)沒(méi)有高低之分，就看你怎么用，對(duì)吧！

NoSQL四大分類

KV鍵值：

新浪：BerkeleyDB+redis
美團(tuán)：redis+tair
阿里、百度：memcache+redis

文檔型數(shù)據(jù)庫(kù)(bson格式比較多)：

CouchDB
MongoDB
MongoDB 是一個(gè)基于分布式文件存儲(chǔ)的數(shù)據(jù)庫(kù)。由 C++ 語(yǔ)言編寫。旨在為 WEB 應(yīng)用提供可
擴(kuò)展的高性能數(shù)據(jù)存儲(chǔ)解決方案。
MongoDB 是一個(gè)介于關(guān)系數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)庫(kù)之間的產(chǎn)品，是非關(guān)系數(shù)據(jù)庫(kù)當(dāng)中功能最豐
富，最像關(guān)系數(shù)據(jù)庫(kù)的。

列存儲(chǔ)數(shù)據(jù)庫(kù)：

Cassandra, HBase
分布式文件系統(tǒng)

圖關(guān)系數(shù)據(jù)庫(kù)

它不是放圖形的，放的是關(guān)系比如:朋友圈社交網(wǎng)絡(luò)、廣告推薦系統(tǒng)
社交網(wǎng)絡(luò)，推薦系統(tǒng)等。專注于構(gòu)建關(guān)系圖譜
Neo4J, InfoGrid

Redis入門

概述

Redis是什么

Redis：REmote DIctionary Server（遠(yuǎn)程字典服務(wù)器）
是完全開源免費(fèi)的，用C語(yǔ)言編寫的，遵守BSD協(xié)議，是一個(gè)高性能的（Key/Value）分布式內(nèi)存數(shù)據(jù)
庫(kù)，基于內(nèi)存運(yùn)行，并支持持久化的NoSQL數(shù)據(jù)庫(kù)，是當(dāng)前最熱門的NoSQL數(shù)據(jù)庫(kù)之一，也被人們稱為
數(shù)據(jù)結(jié)構(gòu)服務(wù)器
Redis與其他key-value緩存產(chǎn)品有以下三個(gè)特點(diǎn)

• Redis支持?jǐn)?shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保持在磁盤中，重啟的時(shí)候可以再次加載進(jìn)行使
  用。
• Redis不僅僅支持簡(jiǎn)單的 key-value 類型的數(shù)據(jù)，同時(shí)還提供list、set、zset、hash等數(shù)據(jù)結(jié)構(gòu)的存
  儲(chǔ)。
• Redis支持?jǐn)?shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

Redis能干嘛

內(nèi)存存儲(chǔ)和持久化：redis支持異步將內(nèi)存中的數(shù)據(jù)寫到硬盤上，同時(shí)不影響繼續(xù)服務(wù)
取最新N個(gè)數(shù)據(jù)的操作，如：可以將最新的10條評(píng)論的ID放在Redis的List集合里面
發(fā)布、訂閱消息系統(tǒng)
地圖信息分析
定時(shí)器、計(jì)數(shù)器
…

特性

數(shù)據(jù)類型、基本操作和配置
持久化和復(fù)制，RDB、AOF
事務(wù)的控制
…

windos安裝

linux安裝

cd /usr/local/bin
ls -l
在redis的解壓目錄下備份redis.conf
mkdir myredis
cp redis.conf myredis # 拷一個(gè)備份，養(yǎng)成良好的習(xí)慣，我們就修改這個(gè)文件
修改配置保證可以后臺(tái)應(yīng)用
vim redis.conf

• A、redis.conf配置文件中daemonize守護(hù)線程，默認(rèn)是NO。
• B、daemonize是用來(lái)指定redis是否要用守護(hù)線程的方式啟動(dòng)。
  daemonize 設(shè)置yes或者no區(qū)別
• daemonize:yes
  redis采用的是單進(jìn)程多線程的模式。當(dāng)redis.conf中選項(xiàng)daemonize設(shè)置成yes時(shí)，代表開啟守護(hù)進(jìn)程模式。在該模式下，redis會(huì)在后臺(tái)運(yùn)行，并將進(jìn)程pid號(hào)寫入至redis.conf選項(xiàng)
  pidfile設(shè)置的文件中，此時(shí)redis將一直運(yùn)行，除非手動(dòng)kill該進(jìn)程。
• daemonize:no
  當(dāng)daemonize選項(xiàng)設(shè)置成no時(shí)，當(dāng)前界面將進(jìn)入redis的命令行界面，exit強(qiáng)制退出或者關(guān)閉連接工具(putty,xshell等)都會(huì)導(dǎo)致redis進(jìn)程退出。

# 【shell】啟動(dòng)redis服務(wù) 這是當(dāng)前終端
[root@192 bin]# cd /usr/local/bin
[root@192 bin]# redis-server kconfig/redis.conf
# redis客戶端連接===> 觀察地址的變化，如果連接ok,是直接連上的，redis默認(rèn)端口號(hào) 6379
[root@192 bin]# redis-cli -p 6379 連接服務(wù)，保證服務(wù)已開啟
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> set k1 helloworld
OK
127.0.0.1:6379> get k1
"helloworld"
# 【shell】ps顯示系統(tǒng)當(dāng)前進(jìn)程信息 這是另外一個(gè)終端
[root@192 myredis]# ps -ef|grep redis
root 16005 1 0 04:45 ? 00:00:00 redis-server
127.0.0.1:6379
root 16031 15692 0 04:47 pts/0 00:00:00 redis-cli -p 6379
root 16107 16076 0 04:51 pts/2 00:00:00 grep --color=auto redis
# 【redis】關(guān)閉連接
127.0.0.1:6379> shutdown
not connected> exit

# 【shell】ps顯示系統(tǒng)當(dāng)前進(jìn)程信息
[root@192 myredis]# ps -ef|grep redis
root 16140 16076 0 04:53 pts/2 00:00:00 grep --color=auto redis

基礎(chǔ)知識(shí)說(shuō)明
準(zhǔn)備工作：開啟redis服務(wù)，客戶端連接

redis壓力測(cè)試工具-----Redis-benchmark

Redis-benchmark是官方自帶的Redis性能測(cè)試工具，可以有效的測(cè)試Redis服務(wù)的性能。

# 測(cè)試一：100個(gè)并發(fā)連接，100000個(gè)請(qǐng)求，檢測(cè)host為localhost 端口為6379的redis服務(wù)器性
能
redis-benchmark -h localhost -p 6379 -c 100 -n 100000
# 測(cè)試出來(lái)的所有命令只舉例一個(gè)！
====== SET ======
100000 requests completed in 1.88 seconds # 對(duì)集合寫入測(cè)試
100 parallel clients # 每次請(qǐng)求有100個(gè)并發(fā)客戶端
3 bytes payload # 每次寫入3個(gè)字節(jié)的數(shù)據(jù)，有效載荷
keep alive: 1 # 保持一個(gè)連接，一臺(tái)服務(wù)器來(lái)處理這些請(qǐng)求
17.05% <= 1 milliseconds
97.35% <= 2 milliseconds
99.97% <= 3 milliseconds
100.00% <= 3 milliseconds # 所有請(qǐng)求在 3 毫秒內(nèi)完成
53248.14 requests per second # 每秒處理 53248.14 次請(qǐng)求

基本數(shù)據(jù)庫(kù)常識(shí)

默認(rèn)16個(gè)數(shù)據(jù)庫(kù)，類似數(shù)組下標(biāo)從零開始，初始默認(rèn)使用零號(hào)庫(kù)

查看 redis.conf ，里面有默認(rèn)的配置
databases 16
# Set the number of databases. The default database is DB 0, you can select
# a different one on a per-connection basis using SELECT <dbid> where
# dbid is a number between 0 and 'databases'-1
databases 16

Select命令切換數(shù)據(jù)庫(kù)

127.0.0.1:6379> select 7
OK
127.0.0.1:6379[7]>
# 不同的庫(kù)可以存不同的數(shù)據(jù)

Dbsize查看當(dāng)前數(shù)據(jù)庫(kù)的key的數(shù)量

127.0.0.1:6379> select 7
OK
127.0.0.1:6379[7]> DBSIZE
(integer) 0
127.0.0.1:6379[7]> select 0
OK
127.0.0.1:6379> DBSIZE
(integer) 5
127.0.0.1:6379> keys * # 查看具體的key
1) "counter:__rand_int__"
2) "mylist"
3) "k1"
4) "myset:__rand_int__"
5) "key:__rand_int__"

Flushdb：清空當(dāng)前庫(kù)
Flushall：清空全部的庫(kù)

127.0.0.1:6379> DBSIZE
(integer) 5
127.0.0.1:6379> FLUSHDB
OK
127.0.0.1:6379> DBSIZE
(integer) 0

為什么默認(rèn)端口是6379？粉絲效應(yīng)！

為什么redis是單線程

我們首先要明白，Redis很快！官方表示，因?yàn)镽edis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機(jī)器內(nèi)存的大小或者網(wǎng)絡(luò)帶寬。既然單線程容易實(shí)現(xiàn)，而且CPU不會(huì)成為瓶頸，那就順理成章地采用單線程的方案了！
Redis采用的是基于內(nèi)存的采用的是單進(jìn)程單線程模型的 KV 數(shù)據(jù)庫(kù)，由C語(yǔ)言編寫，官方提供的數(shù)據(jù)是可以達(dá)100000+的QPS（每秒內(nèi)查詢次數(shù)）。這個(gè)數(shù)據(jù)不比采用單進(jìn)程多線程的同樣基于內(nèi)存的 KV數(shù)據(jù)庫(kù) Memcached 差！

Redis為什么這么快？

1）以前一直有個(gè)誤區(qū)，以為：高性能服務(wù)器 一定是多線程來(lái)實(shí)現(xiàn)的
原因很簡(jiǎn)單因?yàn)檎`區(qū)二導(dǎo)致的：多線程 一定比 單線程 效率高，其實(shí)不然！
在說(shuō)這個(gè)事前希望大家都能對(duì) CPU 、 內(nèi)存 、 硬盤的速度都有了解了！
2）redis 核心就是 如果我的數(shù)據(jù)全都在內(nèi)存里，我單線程的去操作 就是效率最高的，為什么呢，因?yàn)?br> 多線程的本質(zhì)就是 CPU 模擬出來(lái)多個(gè)線程的情況，這種模擬出來(lái)的情況就有一個(gè)代價(jià)，就是上下文的切換，對(duì)于一個(gè)內(nèi)存的系統(tǒng)來(lái)說(shuō)，它沒(méi)有上下文的切換就是效率最高的。redis 用 單個(gè)CPU 綁定一塊內(nèi)存的數(shù)據(jù)，然后針對(duì)這塊內(nèi)存的數(shù)據(jù)進(jìn)行多次讀寫的時(shí)候，都是在一個(gè)CPU上完成的，所以它是單線程處理這個(gè)事。在內(nèi)存的情況下，這個(gè)方案就是最佳方案。
因?yàn)橐淮蜟PU上下文的切換大概在 1500ns 左右。從內(nèi)存中讀取 1MB 的連續(xù)數(shù)據(jù)，耗時(shí)大約為 250us，
假設(shè)1MB的數(shù)據(jù)由多個(gè)線程讀取了1000次，那么就有1000次時(shí)間上下文的切換，那么就有1500ns *1000 = 1500us ，我單線程的讀完1MB數(shù)據(jù)才250us ,你光時(shí)間上下文的切換就用了1500us了，我還不算你每次讀一點(diǎn)數(shù)據(jù) 的時(shí)間。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-425395.html

到了這里，關(guān)于Redis入門到入土(day01)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！