FAQ
Have Questions about the Fastest Way to Migrate to DynamoDB Single-Table Design?
Review our frequently asked questions and contact us if you have additional questions.
Let’s clarify what is being asked here. There are three major milestones to our migration process. The amount of time for each milestone will vary based upon size and complexity of the migration. To better understand a high level project plan, review our project steps.
By providing software and services, we offer an incredible value to our clients. We have a fixed hourly bill rate for staffing which includes the software. We hit the ground running with a goal to quickly and accurately complete your migration in the shortest amount of time possible.
Yes. The technology handles the PK and SK as well as GSIs extremely well. It is purposely built to transform the data based upon your specifications.
It even handles complex situations. A GSI typically consists of both a PK and a SK. In the event that one or both of these data elements are missing, then it can be configured to not write the attributes.
In addition, we have the ability to combine data from multiple sources in order to generate the needed key data (e.g., USER#<username>#EMAIL#<email>
We support all data types offered by DynamoDB. Maps and List provide JSON-like capability, while the Set types are a comma delimited list of values. Shown below is a list of data types offered from AWS: S
– StringN
– NumberB
– BinaryBOOL
– BooleanNULL
– NullM
– MapL
– ListSS
– String SetNS
– Number SetBS
– Binary Set
We support ISO Date Time Format and epoch date time. If other formats are needed, they can be added.
We support the ability to convert from one time zone to another. It is a common practice to switch to GMT or UTC at time of conversion. We account for daylight savings time when making these updates to the date time.
We handle encrypted data based upon your needs. As mentioned earlier, the data never leaves your account and remains secure throughout the migration.
DynamoDB encrypts data at rest. Often companies decide to decrypt their sensitive data before writing to DynamoDB and use IAM security to limit who can see this data.
For additional security, companies may decided to encrypt the data prior to adding it to the DynamoDB table. This means that if someone obtains unauthorized access, they still need additional security to decrypt the data.
The technology is designed to avoid custom coding. However, there are scenarios where customizations are required. For example, there are a tremendous variety of algorithms for encrypting data. At the time of migration, this is the ideal time to change to a modern encryption technique and this must be customized. Rest assured, data will remain secure throughout the lifecycle of the migration.
Absolutely, we love this powerful feature. Time-to-Live provides the ability to expire and purge data (for free) when it is not longer needed. Clients can specify the column to use and we can dynamically load the time for this field.
Yes, we have the ability to generate static text or dynamic values, like UUIDs and KSUIDs. UUIDs and KSUIDs are essential items for a large scale system and are best practice in DynamoDB.
“Hot Keys” occur when the same or similar value is used for the PK. During periods of high volume, such as data migration, this will exceed capacity and cause transactions to be rejected.
First, it is important to review the design to ensure that is the best way to handle the situation. If the business decides to not change the value, then we must carefully load these values using a variety of techniques.
Reports, specific to your database, are available as soon as we begin configuring the migration. This allows project managers, directors, and executive officers to fully understand the progress of the development.
During the actual migration, dashboards are available which provide a summary view of the migration.
We offer comprehensive reporting on each row of data migrated. You will have access to the full details of any data that was migrated and understand the status. Once the migration is complete, you will receive an email with the details of the migration.
We don’t advise waiting. Involving us early in the process is the best way to uncover issues in the end state system. Let me explain using an example.
Assume a team of developers is coding against only data generated from the newly built application. Of course, this data works perfect. It is consumed by the same process that created it. Now, the migration process loads the historical data which isn’t in the format that is expected. There was either a misunderstanding in mapping requirements or a lack of understanding of historical data. This will cause issues in the new system and it is best to find this as early as possible.
Find early…Find often…Fix immediately
Simple. Contact us to start your successful migration. We will gladly discuss your obstacles and how we can help overcome them