5 things to know before using Redis

Developing applications using Redis is a pleasant process, but like other technologies, Redis-based application design also requires a few points to keep in mind. Before, you might have been aware of the whole process of relational database development, and there are many similarities to Redis-based application development, but you have to keep in mind that the following two points--redis is a memory database, and it is single-threaded. Therefore, when using Redis, you need to be aware of the following points:

1. Control all keys stored in Redis

The primary function of a database is to store data, but it is normal for developers to ignore some of the data stored in the database because of changes in application requirements or data usage methods, as in Redis. You may ignore the expiration of certain keys, or you may forget the data because a module of the application is deprecated.

In either case, Redis stores some data that is no longer in use and takes up some space for no reason. Redis's weak-structured data model makes it difficult to understand what is centrally stored unless you use a very sophisticated set of nomenclature for keys. Using the appropriate naming method simplifies your database management, and when you make a key namespace from your application or service (usually using a colon to divide the key name), you can easily identify the data as it is migrated, transformed, or deleted.

Another common use case for Redis is as a second data store for hot data items, and most of the data is stored in other databases, such as PostgreSQL or MongoDB. In these use cases, developers often forget to delete the corresponding data in Redis when the data is removed from the primary storage. This existence, in the case of cross-data storage, usually requires cascading deletes, which can be achieved by saving all the identifiers of a particular data item in the Redis configuration, so that after the primary database is deleted, the system invokes a cleanup program to delete all relevant replicas and information.

2. Control the length of all key names

As we said above, we would like to use the appropriate naming conventions and add prefixes to identify data trends, so this article seems to contradict it. However, don't forget that Redis is a memory database, the shorter the key, the less space you need. As a matter of course, the length of the key name is significant when you have millions of or billions of keys in the database.

For example: On a 32-bit Redis server, if you store 1 million keys and each value is 32-character, you will consume approximately 96MB of space when using the 6-character length key. However, if you use the 12-character-length key name, the space consumption will increase to about 111MB. With the increase in the number of keys, 15% of the extra overhead will have a significant impact.

3. Use the appropriate data structure

Whether it is memory usage or performance, sometimes the data structure will have a big impact, here are some of the best practices to refer to:

Instead of storing the data as thousands of (or millions of) separate strings, consider using a hash data structure to group related data. Hash tables are very efficient and can reduce your memory usage, while hashing is also more useful for detail abstraction and code readability.

When appropriate, use list instead of set. If you do not need to use the Set attribute, the list can provide a faster speed than set with less memory.

Sorted sets is the most expensive data structure, whether it is memory consumption or the complexity of basic operations. If you just need a way to query records and don't care about sorting such attributes, then it's recommended to use a hash table.

One of the often overlooked features of Redis is bitmaps or bitsets (after V2.2). Bitsets allows you to perform multiple bit-level operations on Redis values, such as some lightweight analysis.

4. Do not use the key when using scan

Starting with Redis v2.8, the Scan command is available, which allows you to retrieve the key from the keyspace using a cursor. In contrast to the keys command, although scan cannot return all the matching results at once, it avoids the high risk of blocking the system and allows some operations to be performed on the master node.

It is important to note that the SCAN command is a cursor-based iterator. Each time the scan command is called, a new cursor is returned to the user, and the user needs to use the new cursor as the cursor parameter of the scan command at the next iteration to continue the previous iterative process. Also, with scan, the user can adjust the commands using the KeyName mode and the Count option.

The scan-related commands also include the Sscan command, the HSCAN command, and the Zscan command, respectively, for collections, hash keys, and sequels.

5. Using server-side LUA scripting

During Redis use, the support of Lua scripting has undoubtedly provided developers with a very friendly development environment, which greatly liberates the user's creativity. If used properly, LUA scripting can make a significant difference in performance and resource consumption. Instead of transmitting data to the CPU, the script allows you to execute logic where the data is closest to you, reducing network latency and redundant data transfer.

In Redis, a very classic use case for LUA is data filtering or aggregating data into applications. By encapsulating the processing workflow into a single script, you only need to invoke it to get a smaller answer in less time with a small amount of resources.

Expert tips: Lua is really great, but there are problems too, such as making it difficult to report and handle errors. A sensible approach is to use the pub/sub feature of Redis and have the script push log messages through a dedicated channel. A subscriber process is then established and processed accordingly.

5 things to know before using Redis