名稱長度是否影響Redis的性能？

Question

我喜歡在Redis中使用詳細名稱，例如set-allBooksBelongToUser:$userId。

這是好的還是會影響性能？

Answer 1

你談論的關鍵並不是真的那麼長。

您給出的示例鍵是一個集合，集合的查找方法是O（1）。一組（SDIFF，SUNION，SINTER）上更復雜的操作是O（N）。與使用更長的密鑰相比，填充$userId的可能性更大。

Redis的附帶了一個名爲redis-benchmark，如果修改了「GET」測試中的src/redis的基準測試基準工具。ç讓他們關鍵的就是「富」，你可以在make install後運行短期關鍵測試：

diff --git a/src/redis-benchmark.c b/src/redis-benchmark.c 
--- a/src/redis-benchmark.c 
+++ b/src/redis-benchmark.c 
@@ -475,11 +475,11 @@ 
     benchmark("MSET (10 keys)",cmd,len); 
     free(cmd); 

-  len = redisFormatCommand(&cmd,"SET foo:rand:000000000000 %s",data); 
+  len = redisFormatCommand(&cmd,"SET foo %s",data); 
     benchmark("SET",cmd,len); 
     free(cmd); 

-  len = redisFormatCommand(&cmd,"GET foo:rand:000000000000"); 
+  len = redisFormatCommand(&cmd,"GET foo"); 
     benchmark("GET",cmd,len); 
     free(cmd); 

下面是3個後面的快捷鍵爲「foo」的運行的GET測試速度：

59880.24 requests per second 
58139.53 requests per second 
58479.53 requests per second 

這裏的GET測試速度再次修改源和改變的關鍵在於後「設置allBooksBelongToUser：1234567890」：

60240.96 requests per second 
60606.06 requests per second 
58479.53 requests per second 

再次更改密鑰爲「ipsumloreipsumloreip sumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem：1234567890" 給出了這樣的：

58479.53 requests per second 
58139.53 requests per second 
56179.77 requests per second 

所以，即使真的很長的密鑰不會對Redis的速度有很大的影響。這是在GET，一個O（1）操作。更復雜的操作對此會更加不敏感。

我認爲使用明確標識它們所保存的值的鍵遠遠超過了使用縮寫鍵所能達到的極小速度性能。

如果您想進一步瞭解，redis-benchmark實用程序中還有一個-r [keyspacelen]參數，它可以創建隨機密鑰（只要它們中包含'：rand：'），您只需增加尺寸測試代碼中的前綴長度與您想要的長度無關。

Answer 2

我不認爲變量名稱的長度會影響性能，只要您不超過最大名稱長度，變量將採用與任何變量對該數據類型所採用的相同位置。

Answer 3

我無法肯定地回答這個問題。但是，我可以提出一些關於它的問題並提供一些觀察。

我認爲很明顯，極長的鍵（名稱）和/或值會對整體性能產生性能影響，如果它們完全可以使用的話。這些影響可能在客戶端，網絡或服務器上。所以第一個拖出你的問題是：

Redis和你的客戶之間的密鑰和值可以多長時間？

搜索上Redis的，密鑰長度和限制網我的Redis vs. memcached一個有趣的博客條目可以開始回答你的問題。對該博客文章的第一反應似乎是由Redis的創建者Salvatore Sanfilipo撰寫的（去年秋季：09/2010），表明更新的版本會顯示更好的結果。兩條評論從我們聯繫到薩爾瓦多的Redis/memcached Benchmark，在他迴應了原來的「blagger」（他似乎是匿名的）幾天後發佈的。

這並不回答問題（鑰匙可以使用多久，以及在哪些位置可以檢測到對性能的影響）。但是，它給我們提供瞭解決這個問題的線索。

這兩篇文章的作者寫了代碼並對其進行了測試......並繪製了結果圖。

我們可以做出各種猜測。我們可以查看代碼並嘗試將其推斷出來。

然而，以接近這種問題的最有意義的方式是寫一些代碼以測量一個建議的使用模式......以及一些更多測試另一個（例如一系列的密鑰長度的範圍爲8個字符...你想要多久...... 8千字節？）......以及它的措施。

Answer 4

Redis喜歡在內存中保存所有密鑰。平均密鑰長度越長，內存越少。所以是的，密鑰長度會對性能產生很大的影響，但可能不會顯着影響您的工作。也就是說，在一個很小的密鑰空間（例如一個容易在內存中安裝的密鑰空間）中，一個128字節密鑰和一個16字節密鑰的表現不會有很大差別。