Native library performance, such as ListOperation’s “edit-in-place-in-RAM” (as opposed to edit-via-UDF), is very performant. Will there be similar support for maps?
Yes, it is in the plans.
@ronny1204 do you have special use cases for the maps and how to access it? Thanks.
- Each user maintains a mid-sized set of unique values (a few hundred to over a thousand)
- User activity mostly involves adding new values to his/her own set
- During a user’s activity session, he/she may send tens of “add” requests to the server
Currently, I’m using UDFs to implement “add” functionality. Each UDF-based add operation requires (1) loading the entire existing set (could be large-ish) in Lua code, (2) adding one element, and (3) saving the entire set back to database. Not very efficient (but still quicker than LDTs).
It appears that ListOperation avoids loading the entire list for every incremental operation by placing recently-used lists in RAM, so operations on it are directly made in RAM, which is faster than the UDF method. If the same in-RAM functionality is available for maps, then my described use case will be a perfect fit for it because active users will have their sets loaded in RAM for fast adds.
Is your namespace in memory or disk only?
If in-memory (with or without disk backing), loading is not required.
Even if NOT in memory our measurements show ListOperation to be faster than Lua because the disk load is a lot faster than de-serialization to a Lua object (and the serialization after you’re done).
Thanks for the use case, it will help us plan which operations to optimize. Your use case may also be a good candidate for SortedSets which will be likely the next thing rolled out before we work on Maps.
My namespace is on SSD. In-memory-only would be too costly for my scenario.
My tests show ListOperation to be faster than Lua as well. That is why I’m eager to try out SetOperation or similar
Officially supported since Java Client 3.2.3.