The 5 Biggest Mistakes When Choosing a NoSQL Database
The 5 Biggest Mistakes When Choosing a NoSQL Database

The 5 Biggest Mistakes When Choosing a NoSQL Database

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.

Ortiz David

Engenheiro de Software | Golang | .NET

1 年

Useful Content ??

Silas Candiolli

Tech Lead at CWI | Software Engineer | Java Developer | Spring | Quarkus | SQL | Linux

2 年

Thank you! Very good content

回复
Robert Gherlan

Senior Java Software Engineer | Software Architect | Spring Boot | Quarkus | Cloud Computing | AWS | GCP

2 年

Great content

要查看或添加评论,请登录

Otavio Santana的更多文章

社区洞察

其他会员也浏览了