I have two conflicting requirements:
a) i have keys for which user cannot specify TTL I want to have them evicted based on LRU.
b) I have keys to store some metadata on redis. These should remain and so will not have TTL. These i donot want to get evicted.
To accomodate both,
i am planning to have large TTL ( 1 year or more) for keys under category-a.
and specify eviction policy as volatile-lru
Question: I would like to know the overhead of this choice - using large TTL , say 10 years. Storage, performance of get/put, background redis threads to do expiry etc.
Comment From: itamarhaber
Hello Pavan,
The usual approach for resolving different volatility/persistence requirements from Redis is setting up separate instances. That said, your approach wouldn't work as once the eviction policy is triggered TTL won't play a role - only last access time.
On Thu, Jul 9, 2020 at 3:55 PM PavanP notifications@github.com wrote:
I have two conflicting requirements:
a) i have keys for which user cannot specify TTL I want to have them evicted based on LRU.
b) I have keys to store some metadata on redis. These should remain and so will not have TTL. These i donot want to get evicted.
To accomodate both, i am planning to have large TTL ( 1 year or more) for keys under category-a.
I would like to know the overhead of this choice - using large TTL , say 10 years. Storage, performance of get/put, background redis threads to do expiry etc.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/redis/redis/issues/7496, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOHL7GL5MGS54SZZVO2YPDR2W43DANCNFSM4OVSJN2A .
--
Itamar Haber Technicalist Evangely
Phone: +972.54.567.9692
[image: Redis Labs] https://redislabs.com/
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
Comment From: ppavan108
Thanks for your response, its encouraging to hear from experienced, as we are getting started with redis
Then probably i should think to refresh ttl on access, i.e after every access i would increase it by few days. This will get rid of cold data and does not force you to depend on eviction
Here is what it looks for me, it has two operations
Get key1 -- Sent to replica
Expire key1 3600*24 -- sent to master, in background, grouping say 500of them in pipeline
Do you see any problems with this approach, how much does it cost to extend TTL opearation relative to a read or write operation?
On Fri 10 Jul, 2020, 9:35 PM Itamar Haber, notifications@github.com wrote:
Hello Pavan,
The usual approach for resolving different volatility/persistence requirements from Redis is setting up separate instances. That said, your approach wouldn't work as once the eviction policy is triggered TTL won't play a role - only last access time.
On Thu, Jul 9, 2020 at 3:55 PM PavanP notifications@github.com wrote:
I have two conflicting requirements:
a) i have keys for which user cannot specify TTL I want to have them evicted based on LRU.
b) I have keys to store some metadata on redis. These should remain and so will not have TTL. These i donot want to get evicted.
To accomodate both, i am planning to have large TTL ( 1 year or more) for keys under category-a.
I would like to know the overhead of this choice - using large TTL , say 10 years. Storage, performance of get/put, background redis threads to do expiry etc.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/redis/redis/issues/7496, or unsubscribe < https://github.com/notifications/unsubscribe-auth/ABOHL7GL5MGS54SZZVO2YPDR2W43DANCNFSM4OVSJN2A
.
--
Itamar Haber Technicalist Evangely
Phone: +972.54.567.9692
[image: Redis Labs] https://redislabs.com/
Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/redis/redis/issues/7496#issuecomment-656754689, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDMRCR3UPTRCWUXOWS5JQTR2434NANCNFSM4OVSJN2A .
Comment From: itamarhaber
Dear @ppavan108 - I recommend you close this issue as it is actually an operational question, and instead refer to the mailing list or other community channels: https://redis.io/community.