三千萬資料量下redis2 4的一統計情況

2021-06-19 19:51:38 字數 915 閱讀 8850



先說一下工作場景,要求做乙個服務,滿足:處理千萬級別資料,單個請求響應時間在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...