How to get the primary key (PK) of a record in aerospike?

Question

I want to get a specific record from a set in aerospike.

But when i execute the following query, i got no result:

select * from ctl.prodCache where PK='111222';

But when i execute the following query:

select * from ctl.prodCache;

It gives me all the records, but does not shows the primary key at all.

{ "edigest": "BE6ZxLRMKwnbmUqPTvsmcIAgVv8=", "set": "prodCache", "ttl": 54, "gen": 1, "bins": { "C": "java.util.ArrayList", "V": "00 10 70 61 79 74 6D 6D 61 2E 64 6F 6D 61 69 6E 2E 43 " } }

Any suggestions? Please help.

Answer 1

First execute the following commands from AQL:

SET KEY_SEND TRUE

and then insert the data in specific sets.

After that, execute the select query.

The PK will be shown only for the inserts for which the insertions were done setting the KEY_SEND to true.

Answer 2

By default, Aerospike does not store your primary key. It stores a RIPEMD160 hash of your key+ 1 byte for key type + set name. This is what you are seeing in base64 in the digest output. In AQL, you can set SEND_KEY true, and then it will show in the metadata about the record. In AQL do SET RECORD_PRINT_METADATA true and SET OUTPUT JSON for better visibility. Now, your query with PK='111222' it should work if your key was a string '111222', if it was an integer, use PK=111222 and that should work.

Answer 3

That's because the default is not to store the primary key with the record. A record is identified by the tuple (namespace, set, PK), and is then hashed by the client through RIPEMD-160 into a 20 byte digest. That digest is the actual identifier of the record. It's how the client finds its partition ID, looks up which nodes has the master of that partition, and goes to that node with one hop.

On that node, the digest is what is being matched against the primary index to find this record's metadata. A scan will walk the primary index for a particular namespace, get the metadata of all the records, and stream them back to the client. If you chose to have the sendKey attribute of your write policy set to true, the key will be saved along with the record's data. Then you can get to it from the scan/query. By default this doesn't happen, because that could mean a lot of space