|
Developing applications with Redis is a pleasant process, but like any technology, there are a few things you need to keep in mind when designing Redis-based applications. You may have been familiar with the whole routine of relational database development before, and Redis based application development has many similarities, but you have to keep in mind the following two things - Redis is an in-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 main function of a database is to store data, but it is normal for developers to ignore some data stored in the database due to changes in application requirements or data usage methods, and the same is true in Redis. You may overlook certain keys that expire, or you may forget the data because a module of your application is deprecated. In either case, Redis stores some data that is no longer in use, taking up some space for no reason. Redis' weakly structured data pattern makes it difficult to figure out what is stored centrally unless you use a very mature nomenclature for keys. Using the right naming method will simplify your database management, and when you create a namespace for keys through your application or service (usually using colons to divide key names), you can easily identify data when migrating, converting, or deleting it. Another common use case for Redis is as a second data store for hot data items, where 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 data is removed from primary storage. In this case, cascade deletion is usually required, in which case it can be achieved by saving all identifiers for a specific data item in the Redis configuration, so as to ensure that after the data is deleted in the primary database, a cleaner is called to delete all relevant copies and information. 2. Control the length of all key names As we said above, we used appropriate naming conventions and added prefixes to identify where the data is going, so this seems to go against that. However, don't forget that Redis is an in-memory database, and the shorter the keys, the less space you need. Naturally, when there are millions or billions of keys in a database, the length of the key name will have a big impact. For example, on a 32-bit Redis server, if you store one million keys with a length of 32-character, it will consume about 96MB of space when using a 6-character keyname, but if you use a 12-character keyname, the space consumption will increase to about 111MB. With more keys, the additional 15% overhead will have a significant impact. 3. Use the right data structure Whether it's memory usage or performance, sometimes data structures can have a big impact, here are some best practices to refer to: Instead of storing data as thousands (or millions) of separate strings, consider using hashed data structures to group related data. Hash tables are very efficient and can reduce your memory usage; At the same time, hashing is also more beneficial for detail abstraction and code readability. When appropriate, use list instead of set. If you don't need to use the set feature, List can provide faster speeds than set while using less memory. Sorted sets are the most expensive data structures, both in terms of memory consumption and the complexity of basic operations. If you just need a way to query records and don't care about sorting such properties, then it is highly recommended to use hash tables. An often overlooked feature in Redis is bitmaps or bitsets (after V2.2). Bitsets allow you to perform multiple bit-level operations on Redis values, such as some lightweight analysis. 4. Do not use the key when using SCAN As of Redis v2.8, the SCAN command is already available, which allows keys to be retrieved from the keyspace using the cursor. Compared with the KEYS command, although SCAN cannot return all matching results at once, it avoids the high risk of blocking the system, so that some operations can be executed on the master node. It's important to note that the SCAN command is a cursor-based iterator. Each time the SCAN command is called, a new cursor will be returned to the user, and the user will need to use this new cursor as the cursor parameter of the SCAN command in the next iteration, so as to continue the previous iteration process. At the same time, with SCAN, users can also adjust commands using keyname mode and count options. SCAN-related commands also include SSCAN commands, HSCAN commands, and ZSCAN commands, which are used for collections, hash keys, and sequels, respectively. 5. Use server-side Lua scripts In the process of using Redis, the support of Lua scripts undoubtedly provides developers with a very friendly development environment, thus greatly liberating users' creativity. When used correctly, Lua scripts can bring significant improvements in performance and resource consumption. Instead of passing data to the CPU, scripts allow you to execute logic closest to the data, reducing network latency and redundant data transfer. In Redis, a very classic use case for Lua is data filtering or aggregating data into an application. By encapsulating the processing workflow into a script, you can simply call it to get a smaller answer using few resources in less time. Pro tip:Lua is great, but it also has some problems, such as difficulty reporting and handling bugs. A smart approach is to use Redis' Pub/Sub feature and let the script push log messages over a dedicated channel. Then create a subscriber process and process it accordingly.
| 
Posted on 12/29/2015 12:22:28 PM
|
|
|
