Use Redis in practice

NoSQL Banks , it means "Not only SQL":

  These have emerged from the need to scale relational databases with ACID properties in large-scale high availability web projects. Its key features are high performance, scalability, easy replication and structured data support.

This break with SQL standards always causes a lot of repercussions and many discussions full of feelings and emotions, but the truth is that relational databases still serve to solve many problems that do not always , not always ) can be resolved with NoSQL banks, such as:

  

    

• Need for strong data consistency, well-defined typing, etc.
    
• Complex queries that require a relational model of data for statement realizations and join operations, for example;
    
• Data that exceeds the server's memory availability, however much we can use swap, nobody wants to spoil the performance in this case.
    

NoSQL Redis:

Storing User Sessions

  

This is a very simple template on how to use Redis to save a user's session information.

     

For each session, a key is generated that is written to the browser cookie . With this key, the system has access to a hash with information from this session: login status, clicked ads and products, language preferences, and other time settings that lose valid after a few hours.

The benefit of not keeping such session information directly in the cookie is obvious: we have gained data integrity , not running the risk of any malicious user modifying it, the With Redis, we use simple get / set operations to access this data directly from server memory (or servers, if there is more than one), without wasting resources thanks to the efficient expiration system promoted by this NoSQL.

The expiration algorithm does not monitor 100% of the keys that may expire. Just like most caching systems, the keys expire when a client tries to access it. If the key is expired the value is not returned and the record is removed from the database.

In banks that write a lot of data that loses validity over time, as in this example, some keys would never be accessed again so they would never be removed. These keys need to be removed in some way, so every second Redis tests a random set of keys that may be expired. The algorithm is simple, with every execution:

  

    

• Tests 100 keys with expiration set.
    
• Delete all expired keys.
    
• If more than 25 keys are invalid, the algorithm resumes from 1.
    

This probabilistic logic continues to expire until our valid set of keys is close to 75% of the records.

Search source: Link NoSQL Redis

Friend, I use Redis in an ecommerce and I think I can give you a very simple and practical idea of its use. Before using Redis I used memcached so let's try to understand at what point it helped me.

1st My store had a lot of access and I could not whenever the user was in the catalog or the detail page load the product through the database so I created a very simple and common "cache" implementation that is: / p>

The user asks for the product page of id 14325 2º My data adapter of my application sees if there is a key in the redis called product_id_14325 (the name I am defining), if there is I return the contents of the redis, that is, I do not consult the bank. 3º If the key does not exist in the redis then I search in my database and the return I pass to the user, serialize it and persist in the redis. Soon any user who accesses this detail page will be cached.

There are other approaches such as creating a process to write all your products in the cache and leave with expiration for 1 day, and minor updates to modified products, but this depends on your cache strategy, what matters is that the redis has a series of utilities.