Увидев огромный экземпляр Redis
Обзор:
У нас есть служба, которая предоставляет данные о средней цене около 20 миллионов продуктов. Каждый товар имеет 4 "типа" цен и выполняет около 10 миллионов просмотров товаров в день. Каждый "тип" имеет свою собственную базу данных в нашем единственном экземпляре (я понимаю, что это устарело), и цены хранятся в хэше в формате {timestamp: price}, Когда приходит запрос на идентификатор продукта / тип, мы запускаем hgetall для продукта по его типу усредните цены / временные метки и верните значение. Уровень приложения - Rails, для чего он стоит.
Эта проблема:
Экземпляр Redis размещен на AWS ElasticCache и имеет размер около 500 МБ, но его объем превышает 75 ГБ, и он становится очень дорогим.
Я знаю, что должен быть способ либо:
1) Делайте более эффективные звонки на сам Redis, или
2) Запустите обычное задание cron, чтобы привести в порядок данные, чтобы не нужно было хранить каждую записанную точку данных для каждого элемента.
Я склоняюсь к последнему, потому что кажется достаточно простым просто отсканировать все, вычислить текущее среднее значение для данного идентификатора / типа для каждого месяца (было сказано, что мы собираемся подавать средние значения по месяцам в ближайшее время, поэтому один номер не будет) и поменять его - но моя голова вроде как начинает вращаться, когда я думаю о том, как это будет работать с данными, собранными после свершившегося факта (необходимость поддерживать набор по месяцам вместе с собранным в этом месяце и -не обработан-еще один).
Мой вопрос:
Имеет ли эта стратегия какой-то смысл? Если нет, то как я могу сократить эту вещь до разумного размера, сохраняя при этом возможность усреднять данные по месяцам / годам и хранить миллионы необработанных точек данных в день?