先說一下工作場景，要求做乙個服務，滿足：處理千萬級別資料，單個請求響應時間在20ms以下。由於是儲存的資料格式為key:list，所以很適合使用redis來存放資料，為了測試一下redis儲存的效率問題，才有了這篇文章。
第一步：造資料。思路如下：（1）先產生三千萬個key，為了解決隨機函式不能很好平均分布的問題，採用兩步走的方法來造3000w個key。首先，從key從1到3000萬依次產生，解決數量問題。然後，再使用隨機函式產生1000w資料，新增到這些key中。（2）為了提高效率，使用50個執行緒併發造資料，每個執行緒負責60萬資料的入庫工作。（3）對於其中的幾種長度的key，插入1萬條資料。【3000萬資料，大約使用3g左右的記憶體，實體機記憶體為8g，分配給redis 4g】
第二步：計算訪問速度。為了能比較準確地反映查詢速度，產生1萬個隨機的key並進行訪問，10000次get，大約用時15625ms，平均1.56ms一次。
查詢時，對於key長度為14，且存有10000個資料的list，執行lrange(key,0, -1)，時間為31ms,而key長度為10，且存有10000個相同資料的list，執行lrange(key,0, -1)，時間為16ms。
插入時，list的key長度為14時插入10000個資料，用時23015ms，而key為10時，用時19875ms。
可見key長度增加4，查詢時間由16ms上公升到31ms，而插入一條記錄的時間由1.9875ms上公升到2.3015ms。
三點結論：
一：控制key的長度，盡量使用有意義且簡短的詞。
二：控制list的長度，盡量不要超過一萬，如果可能超過一萬，需要考慮過期刪除機制。
三：redis占用的記憶體最好不要超過實際記憶體的50%，否則在插入時會有讀取超時的情況。
測試環境 作業系統：linux x86_64 記憶體8g，redis版本：2.4.18【最新為2.6.14
三千萬資料量下redis2 4的一統計情況
先說一下工作場景，要求做乙個服務，滿足 處理千萬級別資料，單個請求響應時間在20ms以下。由於是儲存的資料格式為key list，所以很適合使用redis來存放資料，為了測試一下redis儲存的效率問題，才有了這篇文章。第一步 造資料。思路如下 1 先產生三千萬個key，為了解決隨機函式不能很好平均...
三千萬資料量下redis2 4的一統計情況
先說一下工作場景，要求做乙個服務，滿足 處理千萬級別資料，單個請求響應時間在20ms以下。由於是儲存的資料格式為key list，所以很適合使用redis來存放資料，為了測試一下redis儲存的效率問題，才有了這篇文章。第一步 造資料。思路如下 1 先產生三千萬個key，為了解決隨機函式不能很好平均...
oracle千萬級資料量的表關聯更新
查詢資料庫中的鎖 select sess.sid,sess.serial lo.oracle username,lo.os user name,ao.object name,lo.locked mode from v locked object lo,dba objects ao,v session...