Hi Team,
I want implement capping feature in AS, wherein I would like to create a record with a TTL value. At each incoming request I would increment the counter of the record but AFAIK this would also increment the TTL. In this case I do not want to increase TTL upon modification. Can it be done in AS?
It is an existing feature request, to add a write-policy that controls whether the TTL is modified on subsequent update.
For now you can first get the metadata of the record (which is a faster operation than getting the record itself). You then figure out the new TTL you’ll apply with the increment (or other update), as the delta between the void time and current time.
@rbotzer, we are using redis for this kind of operation that work fine, we are planning to use Aerospike we face same issue with each record update TTL also update. i am unable to use metadata because i’m serving millions of record for ADtech, this will increased latency.
any ther suggestion or way.
Thanks in advance.
Iaxman_Singh_Rathore , many people in adtech use us without the feature you request. They either set the TTL on every request - so every write causes the record to last longer, in effect - or they set it to a new value.
As you know, latency during writes is not so important, so if for some reason this is important to you, you can do the read as rbotzer suggests. As you can easily do millions of requests per server, and trivially scale horizontally, simply doing an extra read for every write is not as significant burden as you think. The writes are not in the ad serving loop ( only the actual reads ). Give it a try, you might be surprised.
@bbulkow, yeah we get that this can be programmatically. But in that case wouldn’t it be error prone, as it would be difficult to identify what amount of time should we reduce from existing TTL to get the new TTL. If this is handled at AS end it would be far more efficient and less error prone.
Agreed, and it’s on the list.
But let me point out that hundreds of companies have used Aerospike for exactly what you’re using it for, and no one has ever requested that feature. All of them prefer setting a specific TTL on each write, because they know when doing that write how long that information should be effective. That’s how everyone else does it. Your math and understanding of your data may be different, so that’s why the feature is now on the list, and you’ve got a work around.
If you’re super jazzed to do it yourself, you can submit a pull request. But you’ll probably have to upgrade the protocol because we’re low on bits, which means a fair amount of work.
You can do this without using the TTL feature. Are you checking the cap value? If so then you’re already doing a read so you can use another bin to hold the expiration. Check this bin on the read and reset to 0 if expired, using the write policy to prevent another increment from occurring at the same time. You can also write a UDF to combine this into a single server-side operation if you don’t want to do a read. You’ll also probably need to write a quick background query to periodically scan through records and delete expired ones that aren’t being used anymore.
We requested this feature last year: Maintain TTL value on record update or add fixed-timestamp expiration (3.10.0)
One of the issues is that the smallest TTL value is 1 second, which means a record with many increments per second will reset the expiration indefinitely. The read + write op was the only solution.