Наприклад, мені подобається використовувати багатослівні імена в Redis set-allBooksBelongToUser:$userId.
Це нормально чи це впливає на продуктивність?
Наприклад, мені подобається використовувати багатослівні імена в Redis set-allBooksBelongToUser:$userId.
Це нормально чи це впливає на продуктивність?
Відповіді:
Ключ, про який ви говорите, насправді не так довго.
Прикладовий ключ, який ви даєте, призначений для набору, заданими методами пошуку є 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
Тож навіть дійсно довгі клавіші не мають великого впливу на швидкість повторного використання. І це на GET, операцію O (1). Більш складні операції були б ще менш чутливими до цього.
Я думаю, що наявність ключів, які чітко визначають, які значення вони містять, значно переважає будь-яку мінімальну швидкість швидкості, яку ви отримаєте зі скорочених клавіш.
Якщо ви хочете скористатися цим -r [keyspacelen]додатком, на утиліті redis-бенчмарк також є параметр, який дозволяє йому створювати випадкові ключі (доки у них ': rand:'), ви можете просто збільшити розмір префікса в код тестування до потрібної довжини.
Redis любить зберігати всі клавіші в пам'яті. Чим довша ваша середня довжина ключа, тим менше може зберігатися в пам'яті. Так, так, довжина ключів може сильно вплинути на продуктивність, але, мабуть, не суттєво на те, що вас цікавить. Тобто, при невеликому просторі клавіш (наприклад, той, який легко вписується в пам'ять), клавіша на 128 байт та 16-байтну клавішу не відрізнятиметься різкістю.
Я не можу відповісти на це питання з певністю. Однак я можу задати деякі питання щодо цього і запропонувати деякі спостереження.
Я думаю, що очевидно, що надзвичайно довгі ключі (імена) та / або значення впливатимуть на ефективність роботи на загальну продуктивність, якщо вони взагалі можуть бути використані. Ці впливи можуть бути у клієнта, через мережу або на сервері. Тож першим питанням, яке потрібно витягнути із себе, було б:
Як довго можуть бути ключі та значення між Redis та вашими клієнтами?
Пошук по Redis , довжині та обмеженням ключів дає мені цікавий запис у блозі про Redis vs. memcached, який може почати відповідати на ваше запитання. Перша відповідь на цей запис у блозі, схоже, написана Сальваторе Санфіліпо, творцем Redis (на початку минулої осені: 09/2010), припускаючи, що новіша версія показала б значно кращі результати. Два коментарі вниз з цього посилання посилають нас на Redis / memcached Benchmark, який був розміщений через кілька днів після того, як він відповів на оригінальний "благер" (який, здається, анонімний).
Це не дає відповіді на запитання (як довго можуть бути ключі та в яких моментах можна помітити вплив на продуктивність). Однак це дає нам підказку щодо підходу до питання.
Автори обох цих статей написали код і перевірили його… та зрозуміли результати.
Ми могли робити всілякі здогадки. Ми могли подивитися на код і спробувати його пояснити.
Однак найбільш змістовний спосіб підійти до подібного питання - це написати якийсь код для вимірювання однієї запропонованої схеми використання ... і ще якийсь для тестування іншого (наприклад, діапазон довжин ключів від 8 символів до ... як довго ви хочете ... 8 кілобайт?) ... і виміряйте це.
Я не думаю, що довжина імені змінної буде впливати на продуктивність, змінна займе те саме місце, що і будь-яка змінна буде мати місце для цього типу даних, якщо ви не перевищуєте максимальну довжину імені.