A Gentle Intro for Redis

The Redis website defines its product to be an in-memory data structure store which support strings, hashes, sets and so on.

For the in-memory part, it means that -When the server is started- the processing of the database is done in RAM not in the hard-disk which of-course is much faster as the time for accessing the desk is no longer needed.

Now if the file is loaded in RAM, how does Redis stay persistent?

The persistence is handled in Redis by 2 methods:

• Redis database files (RDB) (activated by default)

• Append-only file (AOF)

First, RDB:

It takes snapshots of the data creating point-in-time copies of the data. It is like make a backups after every specific time or changes in the database. Generally it is perfect for backups.

I find it easy to visualize it as a GitHub Repo that keeps track of your changes but it self-commits after a certain number of changes or some specific time.

Second, AOF:

It depends on logs to reconstruct the database when the server is restarted. When you start your Redis server, AOF keeps track of the changes you make to the database and keeps logs describing it. When the server is restarted, Redis makes sure to reconstruct the original database using these log files.

This way the data is always persistent.

This file is named “Appendonly.aof” and kept in the same folder where you installed Redis.

A last note about data persistence, The 2 methods don’t actually oppose each other and can be used together.

#redis #rdb #aof

What is GEEK

Buddha Community

Redis Transactions & Long-Running Lua Scripts

Redis offers two mechanisms for handling transactions – MULTI/EXEC based transactions and Lua scripts evaluation. Redis Lua scripting is the recommended approach and is fairly popular in usage.

Our Redis™ customers who have Lua scripts deployed often report this error – “BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE”. In this post, we will explain the Redis transactional property of scripts, what this error is about, and why we must be extra careful about it on Sentinel-managed systems that can failover.

Transactional Nature of Redis Lua Scripts

Redis “transactions” aren’t really transactions as understood conventionally – in case of errors, there is no rollback of writes made by the script.

“Atomicity” of Redis scripts is guaranteed in the following manner:

• Once a script begins executing, all other commands/scripts are blocked until the script completes. So, other clients either see the changes made by the script or they don’t. This is because they can only execute either before the script or after the script.
• However, Redis doesn’t do rollbacks, so on an error within a script, any changes already made by the script will be retained and future commands/scripts will see those partial changes.
• Since all other clients are blocked while the script executes, it is critical that the script is well-behaved and finishes in time.

The ‘lua-time-limit’ Value

It is highly recommended that the script complete within a time limit. Redis enforces this in a weak manner with the ‘lua-time-limit’ value. This is the maximum allowed time (in ms) that the script is allowed to run. The default value is 5 seconds. This is a really long time for CPU-bound activity (scripts have limited access and can’t run commands that access the disk).

However, the script is not killed when it executes beyond this time. Redis starts accepting client commands again, but responds to them with a BUSY error.

If you must kill the script at this point, there are two options available:

• SCRIPT KILL command can be used to stop a script that hasn’t yet done any writes.
• If the script has already performed writes to the server and must still be killed, use the SHUTDOWN NOSAVE to shutdown the server completely.

It is usually better to just wait for the script to complete its operation. The complete information on methods to kill the script execution and related behavior are available in the documentation.

#cloud #database #developer #high availability #howto #redis #scalegrid #lua-time-limit #redis diagram #redis master #redis scripts #redis sentinel #redis servers #redis transactions #sentinel-managed #server failures

Redis vs. Memcached: 2021 Comparison

Redis stands for REmote DIctionary Server, created in 2009 by Salvatore Sanfilippo. Memcached, on the other hand, was created in 2003 by Brad Fitzpatrick. Both Redis and Memcached are:

• NoSQL in-memory data structures
• Written in C
• Open source
• Used to speed up applications
• Support sub-millisecond latency

In 2014, Salvatore wrote an excellent StackOverflow post on when it makes more sense to use Memcached than Redis. In this post, we provide a current and detailed comparison between Redis and Memcached so that you can make an informed choice about their use in your application.

#redis #dba #database administration #memcached #database administrator #redis alternative #database comparison #redis news

A Gentle Intro for Redis

The Redis website defines its product to be an in-memory data structure store which support strings, hashes, sets and so on.

For the in-memory part, it means that -When the server is started- the processing of the database is done in RAM not in the hard-disk which of-course is much faster as the time for accessing the desk is no longer needed.

Now if the file is loaded in RAM, how does Redis stay persistent?

The persistence is handled in Redis by 2 methods:

• Redis database files (RDB) (activated by default)

• Append-only file (AOF)

First, RDB:

It takes snapshots of the data creating point-in-time copies of the data. It is like make a backups after every specific time or changes in the database. Generally it is perfect for backups.

I find it easy to visualize it as a GitHub Repo that keeps track of your changes but it self-commits after a certain number of changes or some specific time.

Second, AOF:

It depends on logs to reconstruct the database when the server is restarted. When you start your Redis server, AOF keeps track of the changes you make to the database and keeps logs describing it. When the server is restarted, Redis makes sure to reconstruct the original database using these log files.

This way the data is always persistent.

This file is named “Appendonly.aof” and kept in the same folder where you installed Redis.

A last note about data persistence, The 2 methods don’t actually oppose each other and can be used together.

#redis #rdb #aof

Redis Master Slave Configuration and Tested in Spring Boot

This article talks about master-slave configuration set up in local docker setup and we will verify read replica of slave nodes when master is unavailable or down. We can read data of not when the master node is down. This sample is explained with Spring Boot.

In realtime, the application has to process and fetch from multiple tables through joining to get complex data every time. To improve performance, if we could cache the response which does not change frequently, so that performance will be faster.

When cache is implemented there will be a 100% probability that a single instance can be hit with maximum load on a single instance. For Ex: an app service or back-end system continuously sends requests to a single instance then there might be chances where the connections in Redis instance may be exhausted.

To solve this, We can run multiple instances of Redis with master-slave architecture, where the master would be the write node and slaves would act as read-only nodes like scaling horizontally. Any updates to the master would be automatically synced with slave nodes asynchronously. Any write attempt to the slave nodes would be rejected.

#architecure #master-slave #redis #spring-boot-2 #redis master slave configuration and tested in spring boot #redis master slave configuration

Redis on Azure Performance Benchmark – ScaleGrid for Redis™ Vs. Azure Cache

Redis is an advanced key-value store. In fact, it is the number one key value store and eighth most popular database in the world. It has high throughput and runs from memory, but also has the ability to persist data on disk. Redis is a great caching solution for highly demanding applications, and there are many solutions available to help you deploy and manage Redis in the cloud. In this post, we are going to compare ScaleGrid for Redis™ vs. Azure Cache for Redis performance and management features to help you pick the best managed solution for your Redis deployment.

ScaleGrid is a DBaaS provider that provides fully managed hosting not only for Redis™, but also for MongoDB® database, MySQL, and PostgreSQL. The Bring Your Own Cloud (BYOC) plan hosts the database server in your own AWS, Azure or GCP account.

Azure provides a hosted service for Redis called Azure Cache for Redis.

#performance #redis #azure #benchmark #latency #redis