Reputation: 155
I am beginning a project which will use DynamoDB as a data store, and the very well designed Vogels library to abstract away some of the rough edges of the Amazon SDK.
As an app evolves, there can be expected changes to the attributes that make up the data model. Often new attributes are added, or simple attributes become nested (map) or aggregated (list), and sometimes attribute types will change or an attribute is removed entirely. Some projects such as Vers provide a framework for the on-demand updating of data models.
I know the DynamoDB presents different challenges and flexibilities for evolving existing data models than typical relational systems, so I am wondering if there are any best practices that people use to support data model versioning especially while using Vogels?
Upvotes: 3
Views: 2248
Reputation: 829
The biggest challenge with DynamoDB and a data model that changes so drastically is if you have any existing indexes on an attribute that is now changing to a different data type.
Say you have an existing table with hash key - userid (Number)
Then you want to switch userid from a number to a string, DynamoDB will reject writes to the table because of a datatype mismatch. It will also reject writes if the changed attribute is part of a secondary index.
Vogels validation is fairly flexible and you can configure it to support multiple datatypes for an attribute:
var Account = vogels.define('Account', {
hashKey : 'email',
schema : {
email : Joi.string().email(),
phoneNumber : Joi.alternatives().try(Joi.string(), Joi.number())
}
});
Here phoneNumber could either be a string or a number. However if you had an index on phoneNumber DynamoDB itself will reject the item if the datatype does not match the index configuration.
A best practice to follow for evolving data is never attempt to rename or change data types of existing attributes. Instead write data to new attributes. In your application when reading data check to see if the new attribute exists, if it doesn't then read from the old attribute and convert & write to the new attribute. Regardless of whatever data store you use, this will allow you to do zero downtime deployments and allow you to easily rollback.
Upvotes: 4