Redis сохраняет данные эффективно (хеши)

Question

Мне нужен совет. Я пытаюсь сохранить некоторые данные в очень эффективном режиме памяти с помощью redis и хэшей (тип redis). Есть несколько списков случайных строк (средний размер - 40 символов, но max - 255 символов в rfc) - это идентификатор файла, например, у нас есть список 100kk file_id. Также мы должны отслеживать 2 Params для каждого идентификатора: DOWNLOAD_COUNT (INT, увеличивается на единицу) и server_id - крошечное ИНТ Redis CONFIG добавляют:

hash-max-ziplist-entries 1024 

Во-первых, мы отвергаем хранить данные как есть (палин текст), огромные накладные расходы :

file_id(40 byte) + download_count + server_id) * 100kk + redis pointers --no need to calculate at all. 

во-вторых, использовать некоторые 128bit хэш-функцию и сохранить как с Redis хэш: но есть некоторые накладные расходы тоже, но меньше, чем в 1 один.

И, наконец, мы получаем что-то вроде этого, с Redis хэша:

hmset(bucket, server_id_field, value1, download_count_filed, value2), 
server_id_field = crc32(file_id) 
download_count_filed = crc32(file_id) + 1, 
bucket = murmur2(file_id) div 10^5 

Так есть 100k ведра вообще, поэтому на данный момент мы можем получить столкновение, например: (катаракта сталкивается с perit) благодаря link, и данные попадают в одни и те же ведра, но есть хеш crc32 для полей, и теоретически мы не можем получить столкновение в этой точке (меньше вероятности), может ли эта схема теоретически быть сопротивлением столкновению, равным, например, 64-битовому хешу?

Но это не очень эффективная схема памяти, так что мы могли бы получить что-то вроде этого (с одной поданной):

hmset(bucket, crc32(file_id as server_id_and_download_count_field), value1+’--’+value2) 

Таким образом, мы не можем использовать приращение функции, но мы уменьшаем поля и использование памяти, и нужен некоторый процессор для анализа результата и обновления его с новыми значениями (incremented download_count), может быть, мы могли бы использовать lua, чтобы сделать некоторые встроенные манипуляции с этим?

Так что мой вопрос: Является ли это сильное сопротивление столкновений (для 100kk данных) или, возможно, мы должны использовать некоторую 64 битную хэш-функцию в полях (не CRC32), но то, что о том, когда мы будем иметь 1 миллиард строк будут достаточно сильны для этих данных?

Возможно, есть более эффективная схема?

Спасибо!

Answer 1

Редис Redis очень хорош для этого. Глядя на Redis doc for HSET мы видим

HSET myhash field1 "Hello" 

Мы также должны помнить, что Redis все о строках. Я стараюсь, чтобы вы разделили file_id после символов X (скажем, 10) и использовали первую часть как myhash, а остальное как field1. Таким образом, вы уничтожаете все файлы, начиная с тех же символов X, в один хэш и платите только за один раз. Поэтому проверьте свою разницу на myhash и посмотрите, какое значение вам подходит.

Второе, что нужно сделать, это создать "Hello", ваше значение. Поскольку Redis любит строки, вы должны кодировать все свои данные в один. Начните с server_id, так как вы знаете его размер в байтах, а затем добавьте download_count. Если вы находитесь на Python, вы можете легко использовать struct.pack(), чтобы получить это в строке.

Вы также можете увидеть, присутствуют ли все символы в файле file_ids.Если это только подмножество, вы можете кодировать их также в гораздо более плотную форму и, возможно, сохранить несколько символов.

Удачи вам!