We are about to solve a customer’s need of a web based application that holds a big amount of products and their data – including prices, weights, physical volyme, and much more.
Everything but the prices are data that is data that will be stored once, and then probably not changed. The prices on the other hand will be updated at least once per day to suit the changing currency exchange rates. Therefore we have thought a bit about going for a noSQL-database, but I have yet not the experience to decide whether it is a good idea or just a fancy and modern solution to our problem?
Is it?
Thanks a lot!
As Michael explained, a relational database can be sufficient, depending on your exact requirements. However, a NoSQL database may be a better solution, depending on two aspects of your requirements: the amount and format of the data.
The amount of data
If the amount of data can easily be handled by a single relational database server, then use that relational database by all means. But if you’re dealing with amounts of data that cannot be handled by a single server efficiently, a NoSQL solution may be a better choice. NoSQL databases are better for distribution across servers, because they don’t have to deal with things like relational integrity and atomic transactions.
Data model
If all of your products roughly contain the same properties and all of these properties can easily be stored in a single table, then use a relational database. But if the data model can strongly differ per product type and/or the product data is normalized to multiple tables and cannot easily be denormalized, then a schema-less NoSQL solution, such as a document database, may be a better choice. Then you won’t have to deal with join operations on huge amounts of data.
In short, if you’re dealing with large amounts of data, or with data that is (partially) schema-less, a NoSQL is definitely a viable solution.
Optimize the relational database
Keep in mind that a relational database can also be optimized for large amounts of data by sharding. For example, you can split the products into separate tables based on the SKU. Then the database only has to deal with small tables, instead of a single large table. These tables could be stored on separate servers to spread the load.
Optimize your application architecture
Another option is to use a CQRS architecture on top of relational databases. All data modification queries are sent to a single master database. These modifications are then published to read-only databases or caches, which contain a denormalized representation of the data. Data retrieval queries are performed on the read-only databases for better performance. Although this is a nice architecture on paper, it does have quite an impact on the overall architecture of your application. So I wouldn’t recommend CQRS unless you have used it before.
There’s no easy answer to your question as it all depends on the exact requirements. My suggestion is to keep both relational and NoSQL solutions in mind during the design phase of the project. If you then realize that a relational database is sufficient, then use that. If you realize that it’s just as easy to use a NoSQL database, try that.
Not a yes/no answer, but hopefully some food for though 🙂