Abstract:
Developing applications in Redis can be a fun process, but as with any technology, there are a few things to keep in mind about Redis application design. By now, you probably know the whole formula of relational database development by heart, and redis-based application development has many similarities, but it’s important to keep in mind that Redis is an in-memory database and it’s 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 common for developers to ignore some data stored in a database because of changes in application requirements or data usage, and this is also true in Redis. You might ignore expiration keys, or you might forget the data because a module in your application is deprecated.
In either case, Redis stores data that is no longer used, taking up space for no good reason. Redis’s weak-structured data model makes it hard to figure out what’s stored centrally, unless you use a very sophisticated naming convention for keys. Using proper naming methods will simplify your database management, and when you use your application or service to create a namespace for keys (usually using colons to separate key names), you can easily identify data when it is migrated, transformed, or deleted.
Another common use case for Redis is a secondary datastore for hot data items, most of which are 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 Redis. Cascading deletions across data stores are often required. In this case, this can be done by saving all identifiers for a particular data item in the Redis configuration to ensure that after the data has been deleted from the primary database, a cleanup program is called to remove all relevant copies and information.
2. Control the length of all key names
We talked about using proper naming conventions and adding prefixes to identify where the data is going, so this one seems to contradict that. However, remember that Redis is an in-memory database, and the shorter the key, the less space you need. Of course, when you have millions or billions of keys in a database, the length of the key name matters.
Here’s an example: On a 32-bit Redis server, if you store a million keys each 32-character long, using a 6-character key name will consume approximately 96MB of space, but using a 12-character key name will consume approximately 96MB of space. The space consumption rises to around 111MB. As you increase the number of keys, 15% extra overhead can make a big difference.
3. Use appropriate data structures
Whether it’s memory usage or performance, there are times when data structures can make a big difference. Here are some best practices to consider:
Instead of storing data as thousands (or millions) of separate strings, consider using hash data structures to group related data. Hash tables are very efficient and can reduce your memory usage; At the same time, hashing is more conducive to detail abstraction and code readability.
Use list instead of set when appropriate. If you don’t need to use the set feature, lists can provide faster speeds than sets with less memory.
Sorted sets are the most expensive data structures, both in terms of memory consumption and complexity of basic operations. If you just need a way to query records and don’t care about sorting properties, hash tables are recommended.
One oft-overlooked feature in Redis is Bitmaps or Bitsets (since V2.2). Bitsets allow you to perform multiple bit-level operations on Redis values, such as some lightweight analysis.
4. Do not use keys when using SCAN
As of Redis V2.8, the SCAN command is available, which allows keys to be retrieved from keyspace using cursors. Compared to the KEYS command, SCAN cannot return all matches at once, but it avoids the high risk of blocking the system and allows some operations to be performed on the primary node.
It is important to note that the SCAN command is a vernior-based iterator. Each time the SCAN command is invoked, a new cursor is returned to the user. The user needs to use this new cursor as the cursor parameter of the SCAN command in the next iteration to continue the previous iteration. Also, with SCAN, the user can adjust the command using keyName mode and count options.
SCAN commands also include the SSCAN command, HSCAN command, and ZSCAN command, which are used for collection, hash key, and sequels respectively.
5. Use the Lua script on the server
In the process of using Redis, Lua script support will undoubtedly provide a very friendly development environment for developers, thus greatly liberating user creativity. When used properly, Lua scripts can make a big difference in performance and resource consumption. Instead of passing data to the CPU, scripting allows you to execute logic closest to the data, reducing network latency and redundant data transfer.
A classic use case for Lua in Redis is data filtering or aggregating data into applications. By encapsulating the processing workflow into a script, you only need to invoke it to get a smaller answer in a shorter amount of time with fewer resources.
Lua is great, but it also has some problems, such as difficult error reporting and handling. A sensible approach is to use Redis’ Pub/Sub feature and have scripts push log messages over dedicated channels. A subscriber process is then set up and processed accordingly.
5 Key Takeaways for Developing with Redis
Free subscription to “CSDN Cloud Computing (left) and CSDN Big Data (right)” wechat official account, real-time grasp the first-hand cloud news, understand the latest big data progress!
