DynamoDB - Genese Software Solution

Case Study

DynamoDB

Application Description:

This Attendance System Project is hosted as a serverless in the AWS platform. We have opted Dynamodb as the data storage because dynamodb is NoSQL database service provided by AWS, and it was quite efficient for the use-case of our client.

The tables we have created during the course of our project development are listed below:

  • Company_details
  • Employee
  • Employee_details
  • Employee_presignup
  • Events_records
  • Leave_requests

1. Description of Primary Key design for the Tables and Indexes:

Table 1: Comany_details

Main Table:

Hash Key: Username

This table stores the admin panel data details for the admin dashboard to the Attendance Web Application. Username has been used as a hash key which is efficient to perform query operation in the main table and also this table has a minimal number of data stored.

Table 2: Employee

Main Table:

Hash Key: Name

Sort Key: Date

This table stores a single information record of a particular user for a particular date. “Name” is used as ‘Hash Key’ and “Date” as ‘Sort Key’, thus, it is efficient to perform query operation in the main table using them.

Global Secondary Index:

Hash Key: Name

Sort Key: monthvalue

Dynamodb data items can be accessed in two ways like :

  • Scan Operation
  • Query Operation

The scan operation on a Dynamodb table with a large number of item count results in ineffective utilization of provisioned throughput where we seek the aid of Global Secondary index to define a new primary key combination of “Name” as Hash Key and “monthvalue” as sort Key. While doing so, the data retrieval of records of a user for a particular month from a query operation is easy and have been efficient;

Table 3: Employee_details

Main Table:

Hash Key: Username

This table stores the details of every user of the application. Each user is made identical with each other with the username attribute. Thus, the best option for a primary hash key is to user username itself.

Table 4: Employee_presignup

Main Table:

All the employee upon their account signup by the admin are primarily stored at this table until the users themselves go through the link and change their password. This table stores data temporarily, thus there is no need to use the hash or any sort key in particular.

Table 5: Event_records

Main table:

Hash Key: companyusername

Sort Key: date

Different Companies have their different Events that take place during their office duration. A particular item in the table includes event records for events of a company for a particular date. Hence, optimum efficiency is achieved by making the “companyusername” as the Hash Key and “date” as Sort Key.

Global Secondary Index:

Hash Key: monthvalue

An application requires frequent queries regarding the events for a particular month, While doing so, the implementation of the “monthvalue” attribute as the primary Hask Key is efficient and quick.

Table 6: leave_requests

Main table:

Hash Key: leaveid

For every leave request, we generate a 32 digit unique UUID to serve as the Primary Hash Key for the table.

Global Secondary Index:

Hash Key:

  • employeeusername (employeeusername-index) 
    The application queries every leave requests for a particular user. So for the smooth and effective query actions, we have set “employeeusername” as the Primary Key.

 

  • Managerusername (managerusername-index) 
    Every new request for leave will be notified to the manager. To query the leave requests from a manager’s perspective, this index takes “managerusername”as the Primary Hash Key.

2. Monitoring and alerting for read and write capacity:

Cloudwatch Alarms are created to notify the system (us) about:

Insufficiency caused in provisioned throughput capacity.

3. Enable Continuous Backup and Data Encryption

Continuous backup, which is enabled in our system, provides point-in-time recovery Backup for a continuous data backup until it is explicitly turned off. By default, dynamodb maintains the continuous backups of the table for the last 35 days. We have enabled the encryption in our database for the security purpose.

4. Workload

The workload for our current system in Dynamodb are as follows:

  1. Write Capacity Units: Range between 20,000 to 25,000 WCU-Hrs
  2. Read Capacity Units: Range between 20,000 to 25,000 RCU-Hrs
  3. Total data storage: less than 5 GB till now
  4. Global deployment: In only one region (ap-south-1)

5. Data Access patterns and Transaction Volumes:

Our application may require to scan or query the table item to get the stored data. Thus the data access patterns primarily depend upon the usage of the indexes upon which the database has been designed. Generally, we have used the Global secondary indexes on which hash keys and the sort keys have been defined.

6. Deployment Pattern:

Since the use of the database is new to any of the system we implement on. The applications use the dynamodb database as their new primary database which is easy to use and apply for its no SQL feature implementation.

7. Description of any challenge or customer objection overcome to drive a DynamoDB adoption:

As this service was quite suitable with the use case of our client project there were not many obstacles created by the client side. The problem only was if the service could work perfectly after the integration with their service.