What will change with the server to support this consolidation?
Will the LLIST API be extended to handle some the features of the other current LDT types like unique inserts and exists for LSET and pop for LSTACK? Or will we need to build all this logic ourselves using the client drivers and UDFs?
How will performance be affected? Will all use cases perform as they do now?
Will LLIST stay as infinite storage in all use cases?
All the LDTs are built over similar basic primitives. Nothing changes on the server binary as such. Only change would be the System lua file which support these type would be slowly phased out.
LLIST API can already be used for LMAP/LSET. LSTACK is a special case of ordered list (data always comes in order) will need extra information to be maintained. This may be added as and when deemed necessary.
LMAP / LSET performance may see some change (both positive and negative) based on use case when implemented using LLIST. But the benefit would be stability and predictability in terms of performance and from sizing aspect.
Yes !!! Llist stays as infinite storage.
Developers using any of these three types are urged to use LLIST instead.
Does this mean that I have to change my LSTACK to LLIST in aerospike database? And LSTACK client apis are no long supported?
The functionality for both server and client will not be removed immediately. However, we will not actively be making bug fixes/enhancements for lstack. At some future time, we will likely remove API access (in a few months time-frame).
LSTACK is faster to insert and also very easy to get n most recent records. If LSTACK is removed, are you going to provide similar functions in LLIST.
Currently, if I want to find n most recent records in LLIST, I don’t have an easy way to do that. Is that right?
- currently, no.
- If the data is keyed on timestamp, there are takeN() function to return the top values.
Excuse me. Can you give a link to the document about takeN function? I did a little google and I cannot find the takeN() function.
Thank you very much
What about support for values in a LLIST? Can the objects in the subrecords still be either lists or maps (in addition to strings/integers/blobs)? How big can those objects get?
Objects in LLIST can be list / map / integer / string. Maximum size will be equal to configured write-block-size for the namespace
The above characteristic and takeN() function should show in next LDT release. Along with some more performance enhancements…
Releases >=3.5.9 has following new llist function
find_first(count) find_last(count) returns result in reverse order find_from(key, count)
take_first(count) take_last(count) take_from(key, count)
Note that all the clients may not have native API for these … you can use UDF call to use these functions …
Thank you for posting about LDTs in our forum. Please see the LDT Feature Guide for current LDT recommendations and best practices.
Effective immediately, we will no longer actively support the LDT feature and will eventually remove the API. The exact deprecation and removal timeline will depend on customer and community requirements. Instead of LDTs, we advise that you use our newer List and SortedMap APIs, which are now available in all Aerospike-supported clients at the General Availability level. Read our blog post for details.