Using Redis in practice

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.

1º my store had a lot of access and I could not every time the user was in the catalog or on the detail page load the product through the database so I created a very simple and common" cache " implementation that is:

1st or user asks to Page product id 14325 2º my data adapter of my application ve if there is a key in Redis called product_id_14325 (the name I am defining), if there is I return the content of redis, ie, I do not consult in the bank. 3º if the key does not exist in redis then I search in my database and the return I pass to the user, serialize it and persist in redis. Ready all the user who access this page of detail it is cached.

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

NoSQL Banks , meaning "not only SQL":

These arose from the need to scale relational databases with ACID properties in high-availability web projects operating at scale. Its main features are high performance, scalability, easy replication and support for structured data.

This break with SQL standards always causes great repercussion and many discussions loaded with feelings and emotions, but the it is true that relational databases still serve to solve many problems that do not always (see, not always) they can be solved with NoSQL banks, such as:

• need for strong data consistency, well-defined typing, etc;
• complex searches that require a relational model of the data for statement implementations and join operations, for example;
• data exceeding availability as much as we can use swap, no one wants to harm performance in this case.

NoSQL Redis:

storing user sessions

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

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

The benefit of not storing such session information directly in the cookie is evident: we gain the data integrity security, not at the risk of some malicious user modifying them. With Redis, we use simple get/set operations to access this data directly from the server memory (or servers, if there is more than one), no waste of resources, thanks to the efficient expiration System promoted by this NoSQL.

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

In banks that write a lot of data that loses validity over time, as in this example, some keys would never be accessed again therefore 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, every run:

• Tests 100 keys with set expiration.
• deletes all keys expire.
• if more than 25 keys are invalid the algorithm resumes from 1.

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

Search source: NoSQL Redis link

I run a website development platform and on it we use Redis and MySQL.

MySQL obviously stores all the system data, including the data that renders the sites. But why then do I have a Redis bank along with this MySQL? Simple: speed.

For providing sites, I always want the site to open as quickly as possible, both to improve SEO and to improve the user experience, and to achieve this brand, I use a redis bank to store the data that render the sites (which in this case are all in JSON), since it is a bank that runs in memory, access is much faster than if the system had to, in some way, consult the file system in search of this data. This Redis database is updated whenever the customer makes an update on some content that is relevant to the rendering of the site or if our VPS is restarted.

In short, Redis is extremely useful, as was my case, to store data that needs to be delivered quickly.

Now imagine that same situation, for an e-commerce.

The customer goes and registers the goods, and this data is sent to a bank in memory to be consumed by your client. This, among many things, improved the experience of site visitors because it would greatly reduce the loading time of product data, since instead of having to consult the file system or a api, the data would already be available in server memory. This should be taken into account, as slower systems are more likely to lose access due to lengthy uploads, which can cause timeout errors, for example.