Хранение 13 миллионов поплавков и целых чисел в redis

Question

У меня есть файл с 13 миллионами операций с плавающей запятой, каждый из которых имеет связанный индекс в виде целого числа. Оригинальный размер файла составляет 80 МБ.

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

Хранит их как hashmap в redis, с индексом, являющимся полем, и с плавающей точкой, как значением. При проверке использования памяти было около 970 МБ.

Хранение 13 миллионов, поскольку список использует 280 МБ.

Могу ли я использовать какую-либо оптимизацию?

Заранее спасибо

работает на эластичном кеше

Answer 1

Вы можете сделать действительно хорошую оптимизацию, создавая группы значений индекса и значений с плавающей запятой. Хэши очень оптимизированы для внутренней памяти. Итак, предположим, что ваши данные в оригинальном файле выглядят так:

index, float_value

2,3.44
5,6.55
6,7.33
8,34.55

И вы в настоящее время сохранили их от одного индекса к одному значению с плавающей запятой в хэше или списке. Вы можете сделать эту оптимизацию для объединения значений:

Ключом хэша будет индекс% 1000, ключом будет индекс, а значением будет значение с плавающей запятой.

Подробнее здесь , а также:

Сначала мы решили использовать Redis самым простым способом: для каждый идентификатор, ключ будет идентификатором носителя, а значение будет ID пользователя:

SET media: 1155315 939 GET media: 1155315

939 При создании прототипа этого решения мы обнаружили, что Redis требуется около 70 МБ для хранения таким образом 1 000 000 ключей. Экстраполировать на 300 000 000, которые нам в конечном итоге понадобятся, 21 ГБ данных - уже больше, чем тип экземпляра 17 ГБ на Amazon EC2.

Мы спросили всегда полезного Питера Нордхёйса, одного из главных в Redis. разработчики, для ввода, и он предложил использовать хэши Redis. Хеши в Redis - это словари, которые могут быть закодированы в памяти очень эффективно; настройка Redis «hash-zipmap-max-records» настраивает максимальное количество записей, которое может иметь хеш закодировано эффективно. Мы обнаружили, что эта настройка лучше всего около 1000; любой выше и команды HSET вызовут заметную активность процессора. За Более подробную информацию вы можете получить в исходном файле zipmap.

Чтобы воспользоваться преимуществами типа хеша, мы объединяем все наши идентификаторы мультимедиа в ведра 1000 (мы просто берем ID, делим на 1000 и отбрасываем остаток). Это определяет, в какой ключ мы попадаем; затем, в пределах хэш, который живет по этому ключу, Media ID является ключом поиска в пределах хеш, а идентификатор пользователя является значением. Пример с указанным идентификатором медиа 1155315, что означает, что он попадает в ведро 1155 (1155315/1000 = 1155):

HSET "mediabucket: 1155" "1155315" "939" HGET "mediabucket: 1155" "1155315"

"939" Разница в размерах была довольно поразительной; с нашим 1000000 прототипом ключа (закодированным в 1000 хешей по 1000 подключей каждый), Redis требуется только 16 МБ для хранения информации. Расширение до 300 миллионов ключей, всего чуть менее 5 ГБ - что на самом деле даже подходит в гораздо более дешевом типе экземпляра m1.large на Amazon, около 1/3 стоимость более крупного экземпляра нам была бы нужна в противном случае. Лучшее из все, поиск в хешах по-прежнему O (1), что делает их очень быстрыми.

Если вы хотите попробовать эти комбинации, мы используется для запуска этих тестов доступен как Gist на GitHub (мы также включил Memcached в скрипт, для сравнения - заняло около 52Мб за миллион ключей)