Aerospike java client stores data even when the "set" name is null

I was debugging my code, and I found that this Aerospike java client code with the set name as "null" works and inserts data in aerospike:

AerospikeClient client = new AerospikeClient("localhost", 3000);
Key key = new Key("test", null, inputPayload.getUuid());//Note that the set name is given as "null"

Bin bin1 = new Bin("segments", inputPayload.getSegments());

client.put(null, key, bin1);

I was able to insert and retrieve the data, but show sets didn't reveal any set name. After some debugging I found the data using select * from <namespace>

My question is

1. If the data is not stored in a set, then where is it stored?
2. We know that aerospike compares to relational database as: namespace == database and set == table. But in relational databases, we are not allowed to insert the data directly in a db, we need to create a table first. And that makes sense. So, why does aerospike allow us to do that with null sets?

In Aerospike, you can define a max of 1024 sets, (0 thru 1023) ... default set #0 being the "null" set. Set name is just a metadata on the record - a data modeling convenience and helps with certain commands - especially the newest feature released in version 5.6, set indexing - that greatly speeds up scanning a small number of records (say 1,000) belonging to say, "setA", in an otherwise huge namespace (say, 1 billion records). There are other operational advantages of always attaching a set metadata to your records i.e. specifying a set name with each record, such as using persistent truncate in Enterprise Edition. If you have a mix of records in null set and named sets, you cannot truncate the records in the null set only. If you have a dedicated namespace for like records that you don't want to assign a set name, it saves you storage - the set name is stored with each and every record on device storage. So, there is an incentive in certain data models to not use a set name. A set name can be max 63 characters, each character costing you a byte of storage on device, with each record.