Elasticseach, Redis, Relational Database or all? [closed]

The three are different things that can be understood as a pool of solutions that used together can solve architecture problems and scalability for applications that need a great performance (when they have many concurrent accesses, search constants, realtime, etc.) .

Redis you can use for various purposes such as interprocess communication (imagine that you have a system that is part of Node.js, Java and PHP, and you need to communicate all this, redis would help with the Pub / Sub link ), leave the data in RAM for faster access, and it replicates on disk for persistence in case of restarting the server for example, key value and lists (including with range option). No doubt Redis is a very complete solution that we can use to solve many architectural problems.

In the case of Elasticsearch, the idea is not to save data, but to search for data. Elasticsearch and Solr have been developed above Lucene , where the idea is to organize files. Imagine that in this context, you can only save properties and indexes that you would like to use for searches.

Now let's go to a real-world application where you need performance using Redis, Elasticsearch, and a relational database.

You load the rows of a given table from your RDB that has a large search volume in Redis using key value (id = > data line in JSON), you load the Elasticsearch with the inclusive properties for geolocation lookup . When the user accesses your site / webservice, you do the search using Elasticsearch and return the indexes, which will use to get the data in the redis, which is loaded into RAM. Try to imagine this working in an environment that actually has many concurrent accesses.

When you update some information, it replicates this in Elasticsearch and Redis.

Remembering that this is just one example of the thousands of things that can be done.

I hope I have helped in understanding.