Хранение 30M записей в Redis

Question

Меня интересует наиболее эффективный способ хранения этих данных.

Мне нужно отслеживать 30-50 миллионов точек данных в день.Он должен быть очень быстрым для чтения / записи, поэтому я использую redis.

Данные должны храниться только 24 часа, после чего они будут EXPIRE.

Данныевыглядит как ключ / значение hash

{
  "statistics:a5ded391ce974a1b9a86aa5322ea9e90": {
    xbi: 1,
    bid: 0.24024,
    xpl: 25.0,
    acc: 40,
    pid: 43,
    cos: 0.025,
    xmp: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
    clu: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  }
}

Я заменил фактическую строку большим количеством x, но это правильная длина строки.

Пока, по моим расчетам .... для этого понадобятся сотни ГБ памяти.Кажется ли это правильным?

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

Каков наилучший способ уменьшить объем памяти в этом сценарии?Есть ли лучший способ сделать это?Redis поддерживает 300 ГБ в одном экземпляре?

Answer 1

это будет использовать сотни ГБ памяти.Кажется ли это правильным?

ДА

Поддерживает ли Redis 300 ГБ для одного экземпляра?

ДА

Есть ли лучший способ, которым я могу сделать это?

Вы можете попробовать следующие методы:

Избегайте использования хэша

Поскольку вы всегда получаете все поляжурнал с HGETALL, нет необходимости сохранять журнал как HASH.HASH использует больше памяти, чем STRING.

Вы можете сериализовать все поля в строку и сохранить журнал как пару ключ-значение:

SET 'statistics:a5ded391ce974a1b9a86aa5322ea9e90' '{xbi: 1, bid: 0.24024, and other fields}'

@ Sripathi Krishnan's answerдает еще один способ избежать HASH, т.е. настроить Redis для кодирования HASH в ZIPLIST.Это хорошая идея, если вы не делитесь своим Redis с другими приложениями.В противном случае это изменение может вызвать проблемы у других.

Сжать данные

Чтобы уменьшить использование памяти, вы можете попробовать сжать ваши данные.Redis может хранить двоичные строки, так что вы можете использовать gzip, snappy или другой алгоритм сжатия, чтобы сжать текст журнала в двоичную строку и сохранить его в Redis.

Обычно, вы можете получить лучшее сжатие, когда ввод больше,Поэтому лучше сжать весь журнал, а не сжимать каждое поле одно за другим.

Побочным эффектом является то, что производителю и потребителю журнала необходимо затратить некоторый процессор для сжатия и распаковки данных.Тем не менее, обычно это НЕ проблема, а также это может снизить пропускную способность сети.

Пакетная запись и пакетное чтение

Как я уже говорил выше, если вы хотите получить лучшее сжатие, вы должны получитьбольший вклад.Поэтому, если вы можете написать несколько журналов в пакете, вы можете сжать пакет журналов, чтобы получить лучшее сжатие.

1. Сжать несколько журналов в пакет: compress(log1, log2, log3) -> batch1: batch-result
2. ПоместитеРезультат партии в Redis в виде пары ключ-значение: SET batch1 batch-result
3. Создание индекса для партии: MSET log1 batch1 log2 batch1 log3 batch1

Когда вам нужно получить журнал:

1. Поиск в индексе для получения ключа пакета: GET log1 -> batch1
2. Получение результата пакета: GET batch1 -> результат партии
3. Распаковка результата партиии найдите журнал по результатам

Последний метод является наиболее сложным, и дополнительный индекс будет стоить дополнительной памяти.Однако это может в значительной степени уменьшить размер ваших данных.

Кроме того, что эти методы могут достичь, в значительной степени зависит от вашего журнала.Вы должны сделать много тестов:)

Answer 2

В redis.conf - установите значение hash-max-ziplist-value на 1 больше, чем длина поля 'xmp'.Затем перезапустите Redis и наблюдайте, как ваша память значительно снижается.

Значение по умолчанию - 64. Увеличение его увеличивает использование процессора при изменении или добавлении новых полей в хэш.Но ваш вариант использования, похоже, предназначен только для создания, и в этом случае не должно быть никаких недостатков в увеличении настроек.