免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

參考資料:
http://www.mysqlops.com/2011/09/06/redis-kv-design.html
http://blog.nosqlfan.com/html/3379.html

通過對文章《節(jié)約內(nèi)存：Instagram的Redis實踐》的閱讀之后，感覺受益不少。
在文章中，Instagram 通過對數(shù)據(jù)結(jié)構(gòu)的設(shè)計優(yōu)化，使內(nèi)存從之前的21GB逐步降低到15GB，5GB最后到達了3GB，效果非常顯著。

因此自己打算在測試環(huán)境中模擬其思路，通過實踐加深理解并得出一些真實的數(shù)據(jù)。

首先，需要生成一些數(shù)據(jù)，為了方便理解，我從本地CloudStack中的vm_instance表中取了一些數(shù)據(jù)。
下面我們來看一個關(guān)系型數(shù)據(jù)庫的設(shè)計：

下面我們采用Redis作為數(shù)據(jù)庫，首先需要將關(guān)系型數(shù)據(jù)轉(zhuǎn)化為Key/Value數(shù)據(jù)。
可采用如下的方式來實現(xiàn)：
Key --> 表名:主鍵值:列名
Value --> 列值

使用冒號作為分隔符，目前算是一個不成文的規(guī)矩。例如工具php-admin for redis就是默認以冒號分割的。
下面我以前五行數(shù)據(jù)為例，數(shù)據(jù)轉(zhuǎn)化的命令如下：

后面在大數(shù)據(jù)量生成時我將通過腳本來實現(xiàn)。
這樣在已知主鍵的情況下，通過GET，SET就可以獲得或修改instance_name,private_ip_address等屬性了。

一般的用戶是無法知道自己的id的，只知道自己的instance_name，所以增加一個從instance_name到id的映射是個不錯的注意。

這樣，就可以通過instance_name來方便的查找所需的值了，如下所示：

瀏覽一下當(dāng)前所有的KEY數(shù)據(jù)：

下面，我將通過腳本來生成大量的數(shù)據(jù)（100萬條）。
首先，清除所有的數(shù)據(jù)：

查看當(dāng)前的內(nèi)存耗用：

內(nèi)存的耗用非常少，僅為718.62K (735864)。

下面的Shell腳本將生成100萬條數(shù)據(jù)（20萬*5）：
dongguo@redis:~/shell$ vim redis-cli-generate.sh

創(chuàng)建一個screen終端，將腳本放到終端中后臺執(zhí)行是個不錯的注意。
dongguo@redis:~/shell$ screen -dmS redis
dongguo@redis:~/shell$ screen -r redis
dongguo@redis:~/shell$ ./redis-cli-generate.sh
同時按下Ctrl+AD三個按鈕退出終端。

等待大約2個小時以后，數(shù)據(jù)終于寫入完成（因為是虛擬機環(huán)境，所以才等這么久）。

查看一下當(dāng)前的內(nèi)存開銷：

目前的內(nèi)存耗用為124.50M (130548280)。

在數(shù)據(jù)生成之后，接下來才是本文的重點，即參考Instagram的例子做一些優(yōu)化的實踐。

首先，讓我們確認現(xiàn)在的內(nèi)存開銷：
124.50M (130548280)

第一個優(yōu)化點很明顯也很簡單，可以把所有key值前面相同的vm_instance:去掉，也就是之前定義的表名，將其放置在一個獨立的數(shù)據(jù)庫（這里選擇2號）中，避免其他的數(shù)據(jù)混進來就可以了。
這里就立刻節(jié)省了12個字節(jié)的開銷，然后剩下的繼續(xù)設(shè)法減少開銷，可以將instance_name優(yōu)化為name，private_ip_address優(yōu)化為ip，這樣就累積節(jié)省了12+9+16=37個字節(jié)的開銷。

初步優(yōu)化過后的數(shù)據(jù)如下：

通過腳本導(dǎo)入優(yōu)化過后的數(shù)據(jù)，并做內(nèi)存開銷上的對比。
dongguo@redis:~/shell$ cat redis-cli-generate_2.sh

清除數(shù)據(jù)，用腳本導(dǎo)入新的數(shù)據(jù)。

dongguo@redis:~/shell$ screen -r redis
dongguo@redis:~/shell$ ./redis-cli-generate_2.sh
同時按下Ctrl+AD三個按鈕退出終端。

等待大約2個小時以后，數(shù)據(jù)再次寫入完成。

查看內(nèi)存開銷：

所占內(nèi)存大小為112.15M (117601616)。

結(jié)論：
通過對字節(jié)數(shù)的優(yōu)化，內(nèi)存從124.50M (130548280) 減少到了 112.15M (117601616)。
比例為 1 - (117601616/130548280) = 1 - 0.9008285363851596 = 0.0991714636148404，即節(jié)省了9%的內(nèi)存，感覺效果并不是很明顯。

這個結(jié)果倒也不出乎以外，因為Instagram將內(nèi)存得到了顯著提升，是在使用了Hash結(jié)構(gòu)對數(shù)據(jù)進行存儲之后。

具體的做法呢就是將數(shù)據(jù)分段，每一段使用一個Hash結(jié)構(gòu)來存儲，這一點在String結(jié)構(gòu)里是不存在的。
據(jù)稱經(jīng)過一些開發(fā)者們的實驗，將hash-zipmap-max-entries設(shè)置為1000時，性能比較好，超過1000后HSET命令就會導(dǎo)致CPU消耗變得非常大。

于是我們可以考慮將數(shù)據(jù)做成如下結(jié)構(gòu)：

將4位數(shù)以上的ID值轉(zhuǎn)換為Hash結(jié)構(gòu)的Key值，保證每個Hash內(nèi)部只包含3位的Key，也就是1000個。
對4位數(shù)以下的處理呢就很簡單了，全部把他們放到ID為0的key值中。

對應(yīng)的腳本如下，重新設(shè)計數(shù)據(jù)，采用Hash結(jié)構(gòu)來存儲：
dongguo@redis:~/shell$ cat redis-cli-generate_3.sh

清除數(shù)據(jù):

停止Redis服務(wù)器，以便修改配置文件參數(shù)：
dongguo@redis:~/shell$ sudo /etc/init.d/redis stop
Stopping ...
Redis stopped.

修改配置文件參數(shù)：
dongguo@redis:~/shell$ sudo vim /opt/redis/etc/redis_6379.conf

用腳本導(dǎo)入新的數(shù)據(jù)
dongguo@redis:~/shell$ screen -r redis
dongguo@redis:~/shell$ ./redis-cli-generate_2.sh
同時按下Ctrl+AD三個按鈕退出終端。

等待大約2個小時以后，數(shù)據(jù)再次寫入完成。

激動人心的時刻就要到來了。
查看內(nèi)存開銷：

所占內(nèi)存大小為25.77M (27022992)。

結(jié)論：
使用HASH結(jié)構(gòu)的25.77M (27022992)和使用String結(jié)構(gòu)的112.15M (117601616) 相比，節(jié)省內(nèi)存為 1 - (27022992/117601616) = 1 - 0.229784189360119 = 0.770215810639881 。
即節(jié)省了 77% 的內(nèi)存。

優(yōu)化結(jié)果果然十分顯著，由此看來，我們在Redis中，通過采用HASH結(jié)構(gòu)來存儲數(shù)據(jù)，和直接使用String結(jié)構(gòu)相比，可以十分有效的優(yōu)化內(nèi)存的占用。

目前公司的線上數(shù)據(jù)大部分都采用了String結(jié)構(gòu)，且String中的內(nèi)容是經(jīng)過加密過后的JSON數(shù)據(jù)。

我的想法是，可以嘗試通過對現(xiàn)有的key進行修改或再次設(shè)計，將數(shù)據(jù)存儲到HASH結(jié)構(gòu)中，來實現(xiàn)對內(nèi)存占用的優(yōu)化。