How to create a serial numbers autogenerated in dynamoDb using annotations

Question

I have created a pojo class in my java spring boot app and with respective annotations for doing create/update it's working fine but when i use the autogenerated key annotation it is creating some random id but i want those id column as serial numbers. Below i have given the annotations of my pojo class

@DynamoDBHashKey(attributeName = "id")
@DynamoDBAutoGeneratedKey
public String getId() {
    return id;
}

public void setId(String id) {
    this.id = id;
}

Generated random Id example

5d2af735-62ce-47d4-85bf-8beece056eb

How to generate the autogenerated column with serial numbers like we do in SQL autoincrement identity column?

Answer 1

No you cannot use DynamoDBAutoGeneratedKey to generate a incremented sequence,it is used to generate a random UUID.

The key generated in your case "5d2af735-62ce-47d4-85bf-8beece056eb" is standard UUID format which will help to scale and spread the data across the key space.

https://docs.oracle.com/javase/8/docs/api/java/util/UUID.html

If you want to generate a incremental sequence what you can do is create a SQL table "sequence_table", which will have only 1 column as "sequence_id" which is set to auto increment. Whenever you want to insert data to Dynamo you can first insert in the SQL sequence table and get the latest id.Using this id you can create a new Dynamodb entry. If the annotation DynamoDBAutoGeneratedKey is not used , you can use your own custom key value.Whenever multiple process try to add a new sequence to the sequence_table, each process will first take a lock on the table and then it will insert a new id. So this solution will work in case of distributed system as well.

However on a side note if your business logic does not care about the sequence of id, you should go with UUID only as it is highly scalable , as it is not recommended to have an integer which increments by 1 to generate a hash key of the table. In order for the table to scale according to the provisioned capacity, requests should spread evenly across the shards.

As keys adjacent in a sequence will be stored in the same partition space. Also as one might expect new users to be more active than very old users, and so we would be gearing load towards whichever partition serves the newest user rows.