The 5 Biggest Mistakes When Choosing a NoSQL Database
Otavio Santana
Software Engineer | Software Architect | Speaker | Writer| Book Author | Consultant | Staff Engineer | Mentor | Open Source Committer| Java Champion ?? ??
NoSQL databases are becoming more and more frequent in various solutions, including in highly conservative areas such as finance. However, common mistakes have not changed over time, even with their popularity.
This post briefly discusses five mistakes you should avoid in your next application.
1 Scalability, scalability, scalability
?"Scalability" has unfortunately become much more of a sales pitch than a technical definition. It is widespread in whitepapers, talks, and publicity materials. And that has made it lose its value or invalidate its meaning in the technical sense.
It is essential to understand what scalability is:?
Is it scalable in writing, reading, horizontally, or vertically? And what is the impact of this choice? Another note is that the scalability of an application goes beyond the persistence layer. Is it important? If so, what's it worth if the application can't handle the same number of requests?
2. I will use NoSQL because SQL does not scale
Large companies and marketing campaigns probably generated this error. Relational databases are very mature on the market and have been used in several solutions, including startups.
The vast majority of SQL databases are scalable - vertically. And that doesn't make it unfeasible. Remember that most of your team already knows, which decreases the learning curve.
NoSQL databases tend to have a tremendous advantage when scalability is horizontal. However, it is not the only motivation for their use. For example, graph-type NoSQL databases have widely successful cases working with the recommendation engine.
Overall, SQL databases continue to be valid and very popular in applications.
3 Modeling
We learned at college how to model relational databases with normalizations. However, NoSQL databases tend to go for another approach. The best way to think about it is a new paradigm in persistence.
Modeling these databases tends to modify according to their type, but overall they are Query-driven modeling and embrace denormalization as their best friend.
领英推荐
It happens since writing tends to be computationally cheaper than reading, and some databases do not support features such as joins.
4 The solution to all my problems
Let's face it - there is no perfect solution, only tradeoffs. It is critical to take this into account for any choice. I know that we often fall into the temptation of a good presentation or good marketing publicity. Nevertheless, the real world is not magic.
In fact, in the world of persistence, there is the CAP theorem which, in short, makes it clear that there are three characteristics in a database.
As engineers and architects, we know that there is no silver bullet for any solution, even if we sometimes forget that. The tradeoff lies in this type of choice, as with any architectural choice.
Of the most common tradeoffs, we have the CAP theorem, which clarifies that the world is not perfect! Given the three characteristics of a distributed database, it is impossible to have them all simultaneously.
5 Maintenance?
Making a technological decision based solely on the herd effect is one of the most dangerous things for your team and organization. It is always important to point out that technology's "Hello world" is always the first step.
Factors like backup, maintenance, upgrade, and all support are critical. After all, we have Murphy's Law in IT - anything that can go wrong will! However, only in production at peak hours.
If the NoSQL database is the same solution anyway, one option is to use a service that manages the database for you, like DBaaS. Overall they will take care of all maintenance, backup, and upgrade complexity while you focus on your business.
Conclusion
NoSQL databases are an excellent tool and well worth adding to any engineer/architect's arsenal. However, it is always important to point out that they cannot be used in every possible scenario like any tool. It is worth studying and knowing them to be ready to use them, avoiding these most common mistakes. As always, common sense is the best and most fantastic tool in the hands of an engineer who needs to make this decision.
Engenheiro de Software | Golang | .NET
1 年Useful Content ??
Tech Lead at CWI | Software Engineer | Java Developer | Spring | Quarkus | SQL | Linux
2 年Thank you! Very good content
Senior Java Software Engineer | Software Architect | Spring Boot | Quarkus | Cloud Computing | AWS | GCP
2 年Great content