Should You Be Using NoSQL?
@heroku Developers, teams, and businesses of all sizes use Heroku to deploy, manage, and scale apps. NoSQL got quite some hype a few years back. It was going to solve your scaling, uptime, and speed problems. There were trade-offs, of course, but, for a brief moment, seemingly everything we knew about storing and querying data was up for grabs. So, now the dust has settled, what’s the outcome? Should you be using NoSQL in your next project? Let’s answer that through the lens of three of NoSQL’s promises: scale, fault tolerance, and different data models. Scale NoSQL scale comes in three flavours: how many concurrent operations you need to handle how much data you’re storing the size of the individual assets you’re storing. In most cases, when people talk about scale and NoSQL databases they mean the ability to deal with unpredictable usage patterns. Some, but not all, NoSQL databases are good at dealing with peaks and troughs in demand because they run across multiple nodes. When things are busy, add more nodes. When they’re quieter, spin a few down. When it comes to planned scaling in order to handle a predictable increase in demand, then the same easy clustering comes into play. Add more nodes and you can both handle more demand and more data. Such scaling comes at a cost, though. Simple scaling models suit simple data models. One of the things that makes scaling relational databases harder, though not at all impossible, is the infrastructure that supports query. Databases such as Amazon’s DynamoDB or the open source Riak make it super-easy to scale by doing away with the kind of indexes you’d get in a relational database, normalization, and consistency. Couchbase, a document database, boasts SQL-like query while spreading the workload across multiple nodes. But it can’t easily solve the problem of denormalization, that is there’s a good chance you’ll have more than one copy of the same data in your database and they could get out of sync even if you are very diligent. When it comes to storing large assets, then you should probably have a conversation about why you’re not using cloud storage and only storing the file asset metadata in your database. Some NoSQL databases can help you scale easily but at the cost of queryability, data structure, and data integrity. In the early stages of a new project, speed of development and ease of maintenance are probably more valuable than being able to scale at a moment’s notice. And, besides, if you do hit the limits of a relational database then perhaps you should turn to NoSQL as an aid rather than a replacement. Use Redis to take care of ephemeral data, for example, while using a relational database as your main data store. Fault tolerance Uptime was the flipside of NoSQL’s scalability promise. Most NoSQL databases scale by distributing multiple copies of data across a cluster of nodes. If a single node fails, those remaining can step in. This can be a nightmare for consistency and there are computer scientists dedicating their academic lives to solving the problem through techniques such as conflict-free replicated data types (CRDTs). Essentially, the question comes down to this: if two copies of the same data item are updated at more or less the same time then which one is correct? » Read More
Like to keep reading?
This article first appeared on hackernoon.com. If you'd like to keep reading, follow the white rabbit.