답변:
당신이 사용하는 것에 대한 열쇠는 실제로 그렇게 오래되지 않습니다.
당신이 제공하는 예제 키는 세트에 대한 것이고, 세트 룩업 메소드는 O (1)입니다. 세트 (SDIFF, SUNION, SINTER)에서 더 복잡한 작업은 O (N)입니다. $userId더 긴 키를 사용하는 것보다 채우기가 더 비싼 작업 일 수 있습니다.
Redis에는이라는 벤치 마크 유틸리티가 제공됩니다. redis-benchmarksrc / redis-benchmark.c에서 "GET"테스트를 수정하여 키가 "foo"가되도록하면 다음과 같이 짧은 키 테스트를 실행할 수 있습니다 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);
다음은 짧은 키 "foo"의 3 번 연속 실행에 대한 GET 테스트 속도입니다.
59880.24 requests per second
58139.53 requests per second
58479.53 requests per second
소스를 다시 수정하고 키를 "set-allBooksBelongToUser : 1234567890"으로 변경 한 후의 GET 테스트 속도는 다음과 같습니다.
60240.96 requests per second
60606.06 requests per second
58479.53 requests per second
키를 다시 한 번 "ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumipipiploreipsumloreipsumipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipipip
58479.53 requests per second
58139.53 requests per second
56179.77 requests per second
따라서 실제로 실제로 긴 키조차도 redis 속도에 큰 영향을 미치지 않습니다. 그리고 이것은 O (1) 연산 인 GET에 있습니다. 더 복잡한 작업은 이에 덜 민감합니다.
나는 어떤 값을 가지고 있는지 명확하게 식별하는 키가 약식 키에서 얻을 수있는 작은 속도 성능보다 훨씬 크다고 생각합니다.
이 작업을 더 -r [keyspacelen]진행하려면 redis-benchmark 유틸리티에 임의의 키를 만들 수 있는 매개 변수가 있습니다 (키에 ': rand :'가있는 한), 접두어의 크기를 늘릴 수 있습니다 원하는 길이로 코드를 테스트하십시오.
Redis는 모든 키를 메모리에 보관하는 것을 좋아합니다. 평균 키 길이가 길수록 메모리에 더 적을 수 있습니다. 그렇습니다. 키 길이는 성능에 큰 영향을 줄 수 있지만 우려되는 방식에는 크게 영향을 미치지 않습니다. 즉, 작은 키 공간 (예 : 메모리에 쉽게 맞는 키 공간)을 사용하면 128 바이트 키와 16 바이트 키가 크게 다르게 수행되지 않습니다.
확실하게이 질문에 대답 할 수 없습니다. 그러나 그것에 대해 몇 가지 질문을하고 관찰 할 수 있습니다.
매우 긴 키 (이름) 및 / 또는 값이 전혀 사용될 수있는 경우 전체 성능에 성능에 영향을 줄 것임이 분명합니다. 이러한 영향은 클라이언트, 네트워크 또는 서버에 발생할 수 있습니다. 따라서 첫 번째 질문은 다음과 같습니다.
Redis와 고객간에 키와 값의 길이는 얼마입니까?
Redis , 키 길이 및 제한을 검색하면 Redis vs. memcached 의 흥미로운 블로그 항목으로 인해 질문에 대한 답변을 시작할 수 있습니다. 이 블로그 항목에 대한 첫 번째 응답은 Redis의 작성자 인 Salvatore Sanfilipo (2010 년 초 가을 : 09/2010)에 의해 작성된 것으로 보입니다. 그로부터 Salvatore의 Redis / memcached Benchmark에 대한 두 가지 의견 은 원래 "블래 거"(익명 인 것 같습니다)에 응답 한 후 며칠간 게시되었습니다.
이것은 질문에 대한 답변이 아닙니다 (키가 얼마나 오래 지속될 수 있으며 어떤 지점에서 성능에 영향을 미치는지 감지 할 수 있음). 그러나 그것은 우리에게 질문에 접근하는 것에 대한 단서를 제공합니다.
이 두 기사의 저자는 코드를 작성하고 테스트하여 결과를 그래프로 표시했습니다.
우리는 모든 종류의 추측을 할 수 있습니다. 코드를보고 추론하려고 할 수 있습니다.
그러나이 종류의 질문에 접근하는 가장 의미있는 방법은 제안 된 사용 패턴을 측정하는 코드를 작성하고 다른 패턴을 테스트하는 코드를 작성하는 것입니다 (예 : 8 자에서 ... ... 8 킬로바이트를 원하십니까?) ... 그리고 그것을 측정하십시오.
변수 이름의 길이가 성능에 영향을 줄 것이라고 생각하지 않습니다. 최대 이름 길이를 초과하지 않는 한 변수는 해당 데이터 유형에 대해 변수와 동일한 위치를 차지합니다.