Хэш занимает больше памяти, чем список?

Question

Пожалуйста, помогите выбрать, как хранить сообщения:

1)

SET msg:1 sender 12 
SET msg:1 text "hello there" 
SET msg:1 date 6278127367 
SET msg:1 recpnt 88223 
SET msg:1 viewed false 
SET msg:2 sender 102 
SET msg:2 text "blablabla" 
SET msg:2 date 6278127643 
SET msg:2 recpnt 523 
SET msg:2 viewed false 
SET msg:3 sender 16 
SET msg:3 text "nice weather isntit" 
SET msg:3 date 6278127432 
SET msg:3 recpnt 48781 
SET msg:3 viewed true 

2)

LPUSH msg:1 12 "hello there" 6278127367 88234 false 
LPUSH msg:2 523 "blablabla" 6278127367 4323 false 
LPUSH msg:3 16 "nice weather isn't it" 6278127234 223 true 
LPUSH fields sender text date recpnt viewed 

SET кажется проще в использовании, чем LIST, но будет Redis имена магазин поля с каждым сообщением и, таким образом, около double использование памяти?

Answer 1

Во-первых, я считаю, что вы хотели сказать хеш и не установить; структура заданных данных не подходит для того, что вы описываете.

два варианта вы тогда являются:

1. Hash: отображение строки к строке данных. Если вы представить себе значение ключа данные JSON, ваше сообщение как хэш будет выглядеть примерно так:

   msg:1 = { 
       "sender": "12", 
       "text": "hello there", 
       "date": "6278127367", 
       "recpnt": "88223", 
       "viewed": "false" 
   } 
   

   Вы заметите, что вы можете ясно видеть, какие карты значения с каким ключом; данные имеют некоторую структуру. Hash look up также является постоянным временем.

2. Список: связанный список строк. Опять же, представляя данные в формате JSON:

   msg:1 = ["12", "hello there", "6278127367", "88223", "false"] 
   

   Теперь не ясно, какое значение карты на какое поле, это? Вам нужно будет отслеживать, какой индекс списка хранит информацию, которая добавляет сложности вашему приложению. Кроме того, accessing an individual field больше не является постоянным.

Из двух пунктов выше, хэш представляется более целесообразным.

Но каково влияние на пространство при выборе хеш-таблицы? Здесь размер как хэш и список (найдено с помощью DEBUG OBJECT <key>), используя приведенное выше сообщение:

• Список: 49 байт
• Hash: 86 байт (~ 1.75x)

В сообщении было всего 11 символов. А что насчет tweet-sized (116 characters)?

• Список: 143 байт
• Hash: 174 байт (~ 1.22X)

Да, хэш будет больше для хранения, но это, вероятно, не будет в два раза больше в ваш средний случай.

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