Na przykład lubię używać pełnych nazw w Redis set-allBooksBelongToUser:$userId.
Czy to jest w porządku, czy ma to wpływ na wydajność?
130
Klucz, o którym mówisz, nie jest tak długi.
Przykładowy klucz, który podasz, dotyczy zestawu, metody wyszukiwania zestawów to O (1). Bardziej złożone operacje na zbiorze (SDIFF, SUNION, SINTER) to O (N). Są szanse, że zapełnienie $userIdbyło droższą operacją niż użycie dłuższego klucza.
Redis jest dostarczany z narzędziem testującym o nazwie redis-benchmark, jeśli zmodyfikujesz test „GET” w src / redis-benchmark.c, tak aby klucz był tylko „foo”, możesz uruchomić krótki test klawisza po 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);
Oto prędkość testowa GET dla 3 kolejnych uruchomień skrótu klawiszowego „foo”:
59880.24 requests per second
58139.53 requests per second
58479.53 requests per second
Oto szybkość testu GET po ponownej modyfikacji źródła i zmianie klucza na „set-allBooksBelongToUser: 1234567890”:
60240.96 requests per second
60606.06 requests per second
58479.53 requests per second
Zmiana klucza jeszcze raz do „ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem: 1234567890” daje to:
58479.53 requests per second
58139.53 requests per second
56179.77 requests per second
Więc nawet naprawdę długie klawisze nie mają dużego wpływu na szybkość redis. A to jest na GET, operacja O (1). Bardziej złożone operacje byłyby na to jeszcze mniej wrażliwe.
Myślę, że posiadanie kluczy, które jasno identyfikują, jakie wartości mają, znacznie przewyższa jakąkolwiek minimalną prędkość, jaką można uzyskać dzięki skrótom klawiszowym.
Jeśli chcesz -r [keyspacelen]pójść dalej, w narzędziu redis-benchmark istnieje również parametr, który pozwala tworzyć losowe klucze (o ile mają w sobie ': rand:'), możesz po prostu zwiększyć rozmiar przedrostka w testowanie kodu do dowolnej długości.
Redis lubi trzymać wszystkie klucze w pamięci. Im dłuższa jest średnia długość klucza, tym mniej może być przechowywanych w pamięci. Więc tak, długość klucza może znacznie wpłynąć na wydajność, ale prawdopodobnie nie znacząco w sposób, w jaki jesteś zaniepokojony. Oznacza to, że przy małej przestrzeni klawiszy (np. Takiej, która łatwo mieści się w pamięci), klucz 128-bajtowy i klucz 16-bajtowy nie będą działać dramatycznie inaczej.
źródło
Nie mogę odpowiedzieć na to pytanie z całą pewnością. Mogę jednak zadać kilka pytań na ten temat i przedstawić kilka uwag.
Myślę, że jest oczywiste, że ekstremalnie długie klucze (nazwy) i / lub wartości miałyby wpływ na ogólną wydajność, jeśli w ogóle można ich użyć. Wpływy te mogą mieć miejsce w kliencie, w sieci lub na serwerze. Więc pierwsze pytanie, które należy wyciągnąć z twojego, brzmiałoby:
Jak długo mogą znajdować się klucze i wartości między Redis a Twoimi klientami?
Wyszukiwanie w Redis , długość klucza i limity daje mi interesujący wpis na blogu na temat Redis vs. memcached, który może zacząć odpowiadać na twoje pytanie. Wydaje się, że pierwsza odpowiedź na ten wpis na blogu została napisana przez Salvatore Sanfilipo, twórcę Redis (początek jesieni ubiegłego roku: 09/2010), sugerując, że nowsza wersja przyniosłaby znacznie lepsze wyniki. Dwa komentarze w dół od tego łącza prowadzą do Benchmark Salvatore'a Redis / memcached, który został opublikowany kilka dni po tym, jak odpowiedział na oryginalnego „blagger” (który wydaje się być anonimowy).
To nie odpowiada na pytania (jak długie mogą być klucze i w których momentach można wykryć wpływ na wydajność). Daje nam jednak wskazówkę dotyczącą podejścia do pytania.
Autorzy obu artykułów napisali kod i przetestowali go ... i przedstawili na wykresie wyniki.
Moglibyśmy zgadywać na różne sposoby. Moglibyśmy spojrzeć na kod i spróbować to wyjaśnić.
Jednak najbardziej sensownym sposobem podejścia do tego rodzaju kwestii jest napisanie kodu, który mierzy jeden proponowany wzorzec użycia ... i kilka innych, aby przetestować inny (na przykład zakres długości kluczy od 8 znaków do ... jak długo chcesz ... 8 kilobajtów?) ... i zmierzyć to.
źródło
Nie sądzę, aby długość nazwy zmiennej wpłynęła na wydajność, zmienna zajmie to samo miejsce, co każda zmienna dla tego typu danych, o ile nie przekroczysz maksymalnej długości nazwy.
źródło