Влияет ли длина имени на производительность в Redis?

Question

Мне нравится использовать подробные имена в Redis, например set-allBooksBelongToUser:$userId.

Это нормально или это влияет на производительность?

Answer 1

Ключ, о котором вы говорите, не такой уж и длинный.

Пример ключа, который вы даете, предназначен для набора, методы поиска набора - 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 после повторного изменения источника и изменения ключа к "-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

Так что даже очень длинные ключи не оказывают большого влияния на скорость.д редис.И это на GET, O (1) операция.Более сложные операции были бы еще менее чувствительны к этому.

Я думаю, что наличие ключей, которые четко определяют, какие значения они содержат, значительно перевешивает любую незначительную скорость, которую вы получили бы из сокращенных ключей.

Если вы хотите пойти дальше, в утилите redis-benchmark есть параметр -r [keyspacelen], который позволяет создавать случайные ключи (при условии, что в них есть ': rand:'), вы можете просто увеличить размерпрефикс в тестовом коде любой длины, которую вы хотите.

Answer 2

Redis любит хранить все ключи в памяти. Чем длиннее ваша средняя длина ключа, тем меньше можно хранить в памяти. Так что да, длина ключа может сильно повлиять на производительность, но, вероятно, не так сильно, как вы обеспокоены. То есть с небольшим пространством клавиш (например, легко помещающимся в памяти), 128-байтовая клавиша и 16-байтовая клавиша не будут работать по-разному.

Answer 3

Я не могу ответить на этот вопрос с уверенностью. Однако я могу задать несколько вопросов об этом и предложить некоторые замечания.

Я думаю, что очевидно, что очень длинные ключи (имена) и / или значения будут влиять на производительность, если их вообще можно будет использовать. Эти воздействия могут быть на клиенте, по сети или на сервере. Таким образом, первый вопрос, который нужно вытащить из вашего вопроса:

Как долго могут быть ключи и значения между Redis и вашими клиентами?

Поиск по Redis , длина ключа и ограничения дает мне интересную запись в блоге по Redis против memcached , которая может начинаться с ответь на свой вопрос Первый ответ на эту запись в блоге, по-видимому, был написан Сальваторе Санфилипо, создателем Redis (в начале прошлой осени: 09/2010), предполагая, что более поздняя версия покажет значительно лучшие результаты. Два комментария вниз от этой ссылки связывают нас с Redis / memcached Benchmark Сальваторе , который был опубликован через несколько дней после того, как он отреагировал на первоначального «блейгера» (который, кажется, анонимный).

Это не отвечает на вопросы (как долго могут быть ключи и в какие моменты можно обнаружить влияние на производительность). Тем не менее, это дает нам ключ к пониманию вопроса.

Авторы обеих этих статей написали код и проверили его ... и получили результаты.

Мы могли бы сделать самые разные предположения. Мы могли бы взглянуть на код и попытаться объяснить его.

Тем не менее, наиболее значимым способом решения такого вопроса является написание некоторого кода для измерения одного предложенного шаблона использования ... и еще большего для тестирования другого (например, диапазона длин клавиш от 8 символов до. ... как долго вы хотели бы ... 8 килобайт?) ... и измерить его.

Answer 4

Я не думаю, что длина имени переменной повлияет на производительность, переменная займет то же место, что и любая переменная для этого типа данных, если вы не превышаете максимальную длину имени.