there is no support for auto-incremented bin’s for now. The main reason for this seems to be the coordination work required to synchronize counters across all AS instances (its relatively slow). There are basically two ways to overcome this:
- Create your own counter (e.g. User_AI_Key) with a single bin that you can atomically count up with a record udf, using the result of such a “getId”-query in your app server’s logic to create a new User. OR:
- Abandon the concept of auto-incremented IDs and e.g. use the user’s email (something that stays persistent and is unique) or a hash of it as your records primary Key. E.g. User_JohnDoe@example.org
When designing your NoSQL data model (“schema”), you have to design from the perspective of later usage. Your data model has to support by itself what you want to query later on. If you need to be able to get the last registered users, think about creating a record containing a Large Ordered List with all users (consider it as an ‘index’, just that you got to create/update/manage it). Lists can return first N or last N elements, if needed. In your case, if you use an incremented numeric id, you might even query the counter document and lookup the heighest user id in the system. You could then try to query that user, dealing with potential data races like a user registering up just in the same moment you get the id (id incremented, user object not there yet).
Alternatively, you could also use Aerospikes secondary indices instead of a large ordered list. My personal choice would always favor disk-persisted indices due to cheaper scaling compared to RAM (secondary indices are stored in-memory).
I hope you got a good a glimpse of how to model in the era of NoSQL-databases. One has to think about all queries that should be supported and then design a proper data schema that can be updated with reasonable effort. Your tool set for this includes de-normalization, updates in multiple places as well as super-size document-like records containing data queried together*).
- = Example: store a list of all sessions a user started inside the same user object also containing login name/password. This doesn’t sound much but if you start to also store lists of purchases, emails and so on, you’re user record suddenly get’s a lot bigger (AS got a limit of 1mb for each record). When you query, you simply specify the bin’s you are interested in for now and you save a lot of IOPS compared to the “one table per logical object”-philosophy used in traditional databases.