Задача: есть кешированный результат запроса (тяжёлый результат), есть метка времени его актуальности. Redis работает на одной машине вместе с приложением, соотв. «сетевые задержки» очень условны.
Нужно сначала вытащить метку времени, а потом по этой метке времени понять, требуется мне вытаскивать сами кешированные данные или нет.
Вопрос в том, как хранить метку времени и данные: хешем с полями ts и payload, двумя ключами вида object_id:ts и object_id:payload или вообще - метки времени в одной базе Redis, а кешированные данные в другой.
Мне было бы удобнее хранить как хеш, но поклонники Redis, насколько я знаю, хеши не любят и практически не используют. Поэтому я и думаю: раз не любят - есть за что? Например, не приведёт ли чтение только поля ts из хеша к тому, что в действительности «внутри себя» Redis считает всё значение целиком, потом десериализует из какого-нибудь MessagePack'а, после чего отдаст мне ts, параллельно закачав в ОЗУ ещё и весь payload?
Подход с замусориванием Redis составными ключами мне тоже кажется кривым: понятно, что это как минимум влияет на скорость работы поиска по заданному ключу: даже если там скорость поиска прямо равна O(N), всё равно в 2 раза больше ключей - пусть не в 2 раза, но всё-таки замедлит поиск.
Вопрос в том, есть ли какой-то «закешированный» best practice на этот совершенно типичный, на мой взгляд, случай? Безусловно, я могу полезть прямо в код Redis'а, почитать, как оно там устроено, но во-первых я не силён в сях, а во-вторых - если есть уже некий готовый, обоснованный подход, почему бы его не использовать (форумы для того и нужны, чтобы можно было делиться «пережёванными» результатами получения знаний).
В общем, «как лучше»?
Спасибо!
