Включает ли размер ключа Redis размер данных для этого ключа или только сам ключ?

Я пытаюсь проанализировать размер db для redis db и настроить хранилище наших данных в нескольких статьях, таких как https://davidcel.is/posts/the-story-of-my-redis-database/ и https://engineering.instagram.com/storing-сотни-миллионов-простых-пар-ключ-значение-in-redis-1091ae80f74c

Я читал документацию о «размерах ключей» (например, https://redis.io/commands/object)

и пробовал запускать различные инструменты, например:

redis-cli --bigkeys

а также попытался прочитать вывод redis-cli:

INFO memory

Семантика размера мне непонятна.

Отражает ли указанный размер ТОЛЬКО размер самого ключа, т. Е. Если мой ключ - «abc», а значение - « value1 "указанный размер для части" abc "? Также тот же вопрос в отношении сложных структур данных для этого ключа, таких как хэш / массив или список.

Метод проб и ошибок не дает мне однозначного результата.


redis redis-cluster redis-cli
person Avner Barr    schedule 07.11.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Разные инструменты дают разные ответы.

Сначала прочтите о --bigkeys - он сообщает о больших размерах значений в пространстве ключей, без учета пробела, занимаемого именем ключа. Обратите внимание, что в этом случае размер значения означает что-то свое для каждого типа данных, то есть строки имеют размер STRLEN (байта), а все остальные - количество их вложенных элементов.

Таким образом, это в основном означает, что он дает мало информации о фактическом использовании, а скорее выполняет то, что задумано - находит большие ключи (не большие имена ключей, только предполагаемые большие значения).

INFO MEMORY - это отдельная история. used_memory указывается в байтах и ​​отражает полное потребление ОЗУ именами ключей, их значениями и всеми связанными накладными расходами внутренних структур данных.

Также существует DEBUG OBJECT, но обратите внимание, что его вывод не является надежным способом измерения потребления памяти key в Redis - поле serializedlength дается в байтах, необходимых для сохранения объекта, а не в фактическом объеме памяти, которое включает различные административные издержки поверх самих данных.

Наконец, начиная с версии 4 у нас есть команда MEMORY USAGE, которая работает намного лучше - см. https://github.com/antirez/redis-doc/pull/851, чтобы узнать подробности.

person Itamar Haber    schedule 07.11.2017
comment
когда вы говорите «большие ключи» или «имена ключей» и т. д., относится ли это к размеру пары «ключ-значение»? Что касается типов хэшей (т.е. значения hset outer_key inner_key), относится ли размер ключа ко всему shpeel? (полный размер ключа и хеш, на который он ссылается?). у нас есть случаи, когда ключ очень длинный (50 символов), но значение очень короткое (например, однозначное значение), и случаи, когда значение в 5-10 раз длиннее ключа. Спасибо за ваше разъяснение - person Avner Barr; 07.11.2017
comment
имя ключа - это единственное имя ключа без значения, а для больших ключей этот размер не включается. MEMORY USAGE дает хорошую оценку (в зависимости от выборки) связанных значений и соответствующих накладных расходов администратора, но также не включает стоимость имени ключа. Также, как правило, старайтесь избегать длинных имен клавиш. - person Itamar Haber; 08.11.2017
comment
Какую команду я бы использовал, чтобы получить память, используемую ключом, плюс его значение, включенное в удобочитаемые байты? (значение может быть простым, то есть строковым, числовым, двоичным и т. д. или сложным типом, таким как хэш, набор, список) - person Avner Barr; 08.11.2017
comment
Извините, моя ошибка - MEMORY USAGE это делает (имя и значение ключа). В нем есть небольшая ошибка - github.com/antirez/redis/issues/4430 - person Itamar Haber; 08.11.2017