Например, мне нравится использовать подробные имена в Redis set-allBooksBelongToUser:$userId.
Это нормально или это влияет на производительность?
129
Ключ, о котором вы говорите, на самом деле не такой уж и длинный.
В качестве примера вы указываете ключ для набора, методы поиска набора - O (1). Более сложные операции над набором (SDIFF, SUNION, SINTER) - O (N). Скорее всего, заполнение $userIdбыло более затратной операцией, чем использование более длинного ключа.
Redis поставляется с утилитой тестирования производительности, которая называется redis-benchmark, если вы измените тест «GET» в src / redis-benchmark.c так, чтобы их ключ был просто «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);
Вот скорость теста GET для 3 последовательных запусков короткой клавиши "foo":
59880.24 requests per second
58139.53 requests per second
58479.53 requests per second
Вот скорость теста GET после повторного изменения источника и изменения ключа на "set-allBooksBelongToUser: 1234567890":
60240.96 requests per second
60606.06 requests per second
58479.53 requests per second
Изменение ключа еще раз к «ipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumloreipsumlorem: 1234567890» дает следующее:
58479.53 requests per second
58139.53 requests per second
56179.77 requests per second
Так что даже действительно очень длинные клавиши не имеют большого влияния на скорость Redis. И это в GET, операции O (1). Более сложные операции будут еще менее чувствительны к этому.
Я думаю, что наличие ключей, которые четко идентифицируют, какие значения они содержат, значительно перевешивает любую ничтожную скорость, которую можно получить от сокращенных ключей.
Если вы хотите пойти дальше, -r [keyspacelen]в утилите redis-benchmark есть параметр, позволяющий создавать случайные ключи (если в них есть ': rand:'), вы можете просто увеличить размер префикса в тестирование кода любой длины, которую вы хотите.
Redis любит держать все ключи в памяти. Чем больше средняя длина ключа, тем меньше он может храниться в памяти. Так что да, длина ключа может сильно повлиять на производительность, но, вероятно, не сильно для вас. То есть, при небольшом пространстве ключей (например, таком, которое легко помещается в памяти), 128-байтовый ключ и 16-байтовый ключ не будут работать по-разному.
источник
Я не могу ответить на этот вопрос с уверенностью. Однако я могу задать несколько вопросов по этому поводу и предложить некоторые наблюдения.
Я думаю, очевидно, что очень длинные ключи (имена) и / или значения могут повлиять на производительность в целом, если их вообще можно будет использовать. Эти воздействия могут быть на клиенте, по сети или на сервере. Итак, первый вопрос, который нужно вытянуть из вашего, будет:
Как долго ключи и значения могут находиться между Redis и вашими клиентами?
Поиск в Redis , длине ключа и ограничениях дает мне интересную запись в блоге о Redis и memcached, которая может начать отвечать на ваш вопрос. Первый ответ на эту запись в блоге, похоже, был написан Сальваторе Санфилипо, создателем Redis (начало прошлой осени: 09/2010), предполагающий, что более поздняя версия покажет значительно лучшие результаты. Два комментария вниз от этой ссылки на Redis / memcached Benchmark Сальваторе, который был опубликован через несколько дней после того, как он ответил на исходный «бэггер» (который, кажется, был анонимным).
Это не отвечает на вопросы (какова длина ключей и в каких точках наблюдается заметное влияние на производительность). Однако это дает нам представление о подходе к вопросу.
Авторы обеих этих статей написали код, протестировали его ... и отобразили результаты.
Мы могли делать всевозможные догадки. Мы могли бы взглянуть на код и попытаться понять его.
Однако наиболее значимый способ подойти к вопросу такого рода - написать код для измерения одного предложенного шаблона использования ... и еще немного для проверки другого (например, диапазон длин ключей от 8 символов до ... как долго хочешь ... 8 килобайт?) ... и меряй.
источник
Я не думаю, что длина имени переменной повлияет на производительность, переменная будет занимать то же место, что и любая переменная для этого типа данных, если вы не превышаете максимальную длину имени.
источник