5 things to know before using Redis _redis

Using Redis to develop applications is a pleasant process, but as with other technologies, you need to remember a few things as well, based on Redis application design. Before, you might have a chest of the whole pattern of relational database development, and REDIS application development has many similarities, 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 pay attention to the following points:

1. Control all keys stored in Redis

The primary function of a database is to store data, but it is perfectly normal for developers to ignore some of the data stored in the database because of application requirements or changes in the way the data is used, as in Redis. You may ignore the expiration of certain keys, or you may forget the data because one of the modules in the application is discarded.

In either case, the Redis stores some data that is no longer in use, taking up some space for no reason. Redis's weakly structured data model makes it hard to figure out what's stored centrally, unless you use a very mature nomenclature for keys. Using the appropriate naming method simplifies your database management, and when you make a key namespace through your application or service (usually by using a colon to divide the key), you can easily identify the data as it migrates, transforms, or deletes.

Redis Another common use case is the second data store as a hot data item, and most of the data is stored in other databases, such as PostgreSQL or MongoDB. In these use cases, when data is removed from primary storage, developers often forget to delete the corresponding data in the Redis. This exists across the data store, typically requiring cascading deletions, which can be achieved by saving all the identifiers of specific data items in the Redis configuration, ensuring that after the primary database is deleted, the system invokes a cleanup program to remove all relevant replicas and information.

2. Control the length of all key names

In the above we said that to use the appropriate naming rules, and add a prefix to identify the data direction, so this article seems to violate. But, remember, Redis is a memory database, the shorter the key the less space you need. Of course, when a database has millions of or billions of keys, the length of the key name will be significantly affected.

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

3. Using the appropriate data structure

Whether it's memory usage or performance, there are times when data structures have a big impact, and here are some of the best practices you can refer to:

Instead of storing data as a thousands of (or millions of) independent string, consider using a hash data structure to group related data. A hash table is very efficient and can reduce your memory usage, while hashing is more useful for detail abstraction and code readability.

When appropriate, use list instead of set. If you do not need to use the Set feature, the list can provide 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 lightweight suggests using a hash table.

One often overlooked feature in Redis is bitmaps or bitsets (after V2.2). Bitsets allows you to perform multiple bit-level operations on a Redis value, such as some lightweight analysis.

4. Do not use the key when using scan

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

It should be noted that the SCAN command is a cursor based iterator. Each time the SCAN command is invoked, a new cursor is returned to the user, and the user will need to use the new cursor as a cursor parameter for the SCAN command at the next iteration to continue the previous iteration process. At the same time, using scan, users can also adjust commands using the KeyName mode and the Count option.

Scan related commands also include Sscan commands, Hscan commands, and Zscan commands, respectively, for collections, hashing, and sequels.

5. Use server-side LUA scripts

During Redis use, the support of the Lua script is no doubt a very friendly development environment for developers, thus liberating the user's creativity dramatically. If used properly, LUA scripts can make a significant improvement in performance and resource consumption. Instead of transferring data to the CPU, the script allows you to perform logic where the data is closest, reducing network latency and redundant data transmission.

In Redis, a very classic use case of LUA is data filtering or aggregating data into an application. By encapsulating a processing workflow into a script, you simply call it to use a small amount of resources to get a smaller answer in a shorter time.

Expert tip: Lua is really great, but there are also problems, such as the difficulty of error reporting and handling. A sensible way is to use the Redis pub/sub feature and have the script push the log message through a dedicated channel. The subscriber process is then established and processed accordingly.