Redis VS MongoDB VS Cassandra
Redis VS MongoDB VS Cassandra
By Massimiliano Scifo
6 min read
Are the NoSQL databases all the same? If not, what are the differences (and why should you care)? A quick comparison chat between Redis, MongoDB and Cassandra
- Authors
- Name
- Massimiliano Scifo
- linkedinMassimiliano Scifo
- twitter@max_scifo
Having to choose a database is a task that any developer, at some point, must face. Whether its for a new assignment at your job with a pre-set tech stack or just for a personal project when you have the need of store some data. The options available are many and diverse that is very easily leaving you confused while having to choose which one suits best for your situation. The very basic choose to make if using a relational database or a NoSQL one. The first one is usually considered very reliable (since relational database have been around for 50 years) but is most likely to be expensive (most of the relational dbs are not open source and behind some fees) and you are forced on defining tables (either by adding those manually or via some automation). NoSQL databases, on the other hand, are able to be document based, graph based, key-value pairs or wide-column stores and most of the time they are open source. In this article we are going to have a very high-level look at 3 of the most used NOSQL databases out there that have quite different use cases: Redis, MongoDB and Cassandra.
Redis
Written in C, Redis is defined as an in-memory key-value store. This database is the fastest when it comes to query execution of all of those considered in this article. The data is stored by default in the RAM and thus data is accessible super-fast. This inner working of RAM works is also the quickest to reach saturation point if not dealt with properly. Usually when you restart the machine you are going to lose all the data in Redis, but there are some configurations that can tell Redis to dump the collections in the hard drive and reload those at start. Redis is optimized for non-permanent data and real-time response but poorly optimized for scaling, since allow only vertical scaling (and some sort of horizontal scaling by using cluster). Redis Cluster also works only by replicating the master node to a slave node and should have a minimum of 3 masters for “guarantee” reliability and 3 slaves. Redis also does not handle too well extremely complex objects since is designed to offer fast iterations with only primary index access key One of the most common use cases for Redis is while implementing any functionalities that requires a real-time response like:
- a chat between users
- a search engine optimized for heavy queries
- real-time updating graphs
MongoDB
A key-value document-oriented database, very quick to setup and run (different cloud solutions, with Atlas being the most famous/used), optimal for quick prototyping and written in C++. The main difference between a document-oriented database and a relational database is how the data is stored: in a relational database an object data might be spread over different tables that you will need to join, while in a document database, the whole object is stored as instance in the collection. Being a document-oriented database does not mean that it does not support relations in a very efficient way. In fact, it can be much quicker than a non-optimized relational DB query. MongoDB also supports secondary index on objects, for better handling queries using nested objects without the usual joins and subqueries pain.
As any document-oriented DB, MongoDB suffers of data redundancy that might end in creating huge collections and very slow queries, but this can be in part prevented by using relations instead of storing the whole object in the collection. MongoDB allows better horizontal scaling than Redis but still has a bottleneck since it is using one or more “proxies” to send the query to the correct DB replica. Most common use case scenario are:
- Generic permanent data storage for APIs
- Prototyping
- Product catalog
- Customer analytics
Cassandra
Quite slow and more time-consuming setup compared to the others and written in Java, Cassandra is a distributed database system by design. Cassandra is the most SQL-like of the 3 databases, at least syntax-wise. It differs from relational databases in several ways, the most important of them being that a row in SQL tables can contain only datatypes while Cassandra stores objects and can return those directly. Works properly only in a clustered setup. This cluster is not in the master-slave way, since all the nodes are equal and contain the same replica and you don’t have a guaranteed node to answer you, but the first that gets updated and is free will serve the request. and is the one that outperform the other in availability and guarantees the correct replica with no point of failure of the data, partially thanks to the “tombstones” (a marking system that runs query in the various nodes) system. Basically, each node that you add to the system will give more availability and reliability to your system, since each node is guaranteed to have the exact data as the others and this nodes can also be set on a different zones As you can imagine, this allows very easy horizontal scaling and is ideal for extensive usage or huge dataset but is totally a waste for smaller projects, both cost wise and time wise, since the minimum viable setup of 3 nodes for making it working.
It does not support a lot of programming languages compared to the others and most likely the one that have the steeper learning curve, since a lot of optimizations are possible with the queries as with most relational database. Most common use case scenario for Cassandra are systems that heavily rely on being 100% available, like:
- Generic permanent data storage focused on availability
- Financial services / payments
- Transactions Logging
Conclusions
As general suggestion you should not try to force a database to do something that was not designed for, if not totally sure of the capabilities of the storage and the drawback of your actions. Redis is very fast and is the one that requires less resource from the machine but is not meant to be used for storing user sensitive or permanent data, is meant to serve quickly and intensive requests better than the others and is good in doing this. MongoDB is more “generic” as use case, since is easy to setup and is widely used for different solutions allowing a decent horizontal scaling which you’ll end up needing in the long run. Cassandra is the most Enterprise-wise DB, since the cost will be higher than the others and the focus on the availability is something that comes really handy but only when you have to handle several hundreds of query per minute, looking to have no downtime no matter what and letting you rely on it about data consistency (between the nodes) which is guaranteed to be optimal.
Upcoming events
Coven of Wisdom - Herentals - Winter `24 edition
Worstelen jij en je team met automated testing en performance? Kom naar onze meetup waar ervaren sprekers hun inzichten en ervaringen delen over het bouwen van robuuste en efficiënte applicaties. Schrijf je in voor een avond vol kennis, heerlijk eten en een mix van creativiteit en technologie! 🚀 18:00 – 🚪 Deuren open 18:15 – 🍕 Food & drinks 19:00 – 📢 Talk 1 20:00 – 🍹 Kleine pauze 20:15 – 📢 Talk 2 21:00 – 🙋♀️ Drinks 22:00 – 🍻 Tot de volgende keer? Tijdens deze meetup gaan we dieper in op automated testing en performance. Onze sprekers delen heel wat praktische inzichten en ervaringen. Ze vertellen je hoe je effectieve geautomatiseerde tests kunt schrijven en onderhouden, en hoe je de prestaties van je applicatie kunt optimaliseren. Houd onze updates in de gaten voor meer informatie over de sprekers en hun specifieke onderwerpen. Over iO Wij zijn iO: een groeiend team van experts die end-to-end-diensten aanbieden voor communicatie en digitale transformatie. We denken groot en werken lokaal. Aan strategie, creatie, content, marketing en technologie. In nauwe samenwerking met onze klanten om hun merken te versterken, hun digitale systemen te verbeteren en hun toekomstbestendige groei veilig te stellen. We helpen klanten niet alleen hun zakelijke doelen te bereiken. Samen verkennen en benutten we de eindeloze mogelijkheden die markten in constante verandering bieden. De springplank voor die visie is talent. Onze campus is onze broedplaats voor innovatie, die een omgeving creëert die talent de ruimte en stimulans geeft die het nodig heeft om te ontkiemen, te ontwikkelen en te floreren. Want werken aan de infinite opportunities van morgen, dat doen we vandaag.
| Coven of Wisdom Herentals
Go to page for Coven of Wisdom - Herentals - Winter `24 editionMastering Event-Driven Design
PLEASE RSVP SO THAT WE KNOW HOW MUCH FOOD WE WILL NEED Are you and your team struggling with event-driven microservices? Join us for a meetup with Mehmet Akif Tütüncü, a senior software engineer, who has given multiple great talks so far and Allard Buijze founder of CTO and founder of AxonIQ, who built the fundaments of the Axon Framework. RSVP for an evening of learning, delicious food, and the fusion of creativity and tech! 🚀 18:00 – 🚪 Doors open to the public 18:15 – 🍕 Let’s eat 19:00 – 📢 Getting Your Axe On Event Sourcing with Axon Framework 20:00 – 🍹 Small break 20:15 – 📢 Event-Driven Microservices - Beyond the Fairy Tale 21:00 – 🙋♀️ drinks 22:00 – 🍻 See you next time? Details: Getting Your Axe On - Event Sourcing with Axon Framework In this presentation, we will explore the basics of event-driven architecture using Axon Framework. We'll start by explaining key concepts such as Event Sourcing and Command Query Responsibility Segregation (CQRS), and how they can improve the scalability and maintainability of modern applications. You will learn what Axon Framework is, how it simplifies implementing these patterns, and see hands-on examples of setting up a project with Axon Framework and Spring Boot. Whether you are new to these concepts or looking to understand them more, this session will provide practical insights and tools to help you build resilient and efficient applications. Event-Driven Microservices - Beyond the Fairy Tale Our applications need to be faster, better, bigger, smarter, and more enjoyable to meet our demanding end-users needs. In recent years, the way we build, run, and operate our software has changed significantly. We use scalable platforms to deploy and manage our applications. Instead of big monolithic deployment applications, we now deploy small, functionally consistent components as microservices. Problem. Solved. Right? Unfortunately, for most of us, microservices, and especially their event-driven variants, do not deliver on the beautiful, fairy-tale-like promises that surround them.In this session, Allard will share a different take on microservices. We will see that not much has changed in how we build software, which is why so many “microservices projects” fail nowadays. What lessons can we learn from concepts like DDD, CQRS, and Event Sourcing to help manage the complexity of our systems? He will also show how message-driven communication allows us to focus on finding the boundaries of functionally cohesive components, which we can evolve into microservices should the need arise.
| Coven of Wisdom - Utrecht
Go to page for Mastering Event-Driven DesignThe Leadership Meetup
PLEASE RSVP SO THAT WE KNOW HOW MUCH FOOD WE WILL NEED What distinguishes a software developer from a software team lead? As a team leader, you are responsible for people, their performance, and motivation. Your output is the output of your team. Whether you are a front-end or back-end developer, or any other discipline that wants to grow into the role of a tech lead, RSVP for an evening of learning, delicious food, and the fusion of leadership and tech! 🚀 18:00 – 🚪 Doors open to the public 18:15 – 🍕 Let’s eat 19:00 – 📢 First round of Talks 19:45 – 🍹 Small break 20:00 – 📢 Second round of Talks 20:45 – 🙋♀️ drinks 21:00 – 🍻 See you next time? First Round of Talks: Pixel Perfect and Perfectly Insane: About That Time My Brain Just Switched Off Remy Parzinski, Design System Lead at Logius Learn from Remy how you can care for yourself because we all need to. Second Round of Talks: Becoming a LeadDev at your client; How to Fail at Large (or How to Do Slightly Better) Arno Koehler Engineering Manager @ iO What are the things that will help you become a lead engineer? Building Team Culture (Tales of trust and positivity) Michel Blankenstein Engineering Manager @ iO & Head of Technology @ Zorggenoot How do you create a culture at your company or team? RSVP now to secure your spot, and let's explore the fascinating world of design systems together!
| Coven of Wisdom - Amsterdam
Go to page for The Leadership Meetup