Comparison of Redis and MongoDB databases

Redis is a key-value database in which information is stored in memory in relation to key value, which is more important than memcache in the diversity of its data structure.

Say it's not really a database in the sense that because Redis is the main storage of data in memory (of course, it can be stored on the hard disk, which is also one of the necessary requirements to write the shell), the nature of its "cache" is much larger than its "data storage" nature, where the data is just as simple as the variable operation. And MongoDB is a "storage data" system, delete and change the data when there is "and or not" conditions, the way to query data can be as flexible as SQL database, this is Redis do not have.

So in my project, Redis as session, task queue memory, and MongoDB as data (including user information, etc.) of the memory.

To get to the point, yesterday to see the FREEBUF has said that the Redis may cause security problems, mentioned the writing file, then I am here to explain the method.

Redis installation is complete with its own command line, that is, REDIS-CLI, which contains commands that can be consulted in: Http://redis.io/commands. Each client basically is in accordance with this order to delete and change check.

Previously said the Redis data is mainly stored in memory, when the difference with memcache is that we can execute the "save" command at any time to save the current Redis data to the hard disk, and Redis will automatically store data to the hard disk according to the configuration.

This has to be said of Redis's lasting operation Http://redis.io/topics/persistence, which speaks of a rdb, a aof. RDB is more like a database backup file, and aof is a log log file. We can set Redis to specify the time, specify the number of changes to backup, generate RDB files, and set AOF, you can in the operation or time after the "log" to the end of a file, when the operation more and more, then the aof file is getting larger.

The two are complementary, and through the combination of the two we can stably and persistently store the data on the server.

Use Redis to write Webshell

And we are using these data to store the operation of any file write.

There are several key items in the Redis configuration:

Dir, which specifies the "work path" of Redis, and the resulting RDB and aof files will be stored here.
Dbfilename,rdb filename, default to "Dump.rdb"
AppendOnly, whether to open aof
appendfilename,aof filename, default to "Appendonly.aof"
Appendfsync,aof Backup mode: Always, everysec, no

After my research found that we could set Dir to a directory A, and dbfilename to file name B, then save or bgsave, we could write to an arbitrary file with a path of A/b:

When we get a redis console, we can call Config Set/get and other commands to modify the Redis configuration.

And it happens that we can change dir and dbfilename through config set. That is, we can write to any file without having to modify the redis.conf or restart the Redis service:

Config set dir/home/wwwroot/default/
Config set Dbfilename redis.php
Set Webshell "<?php phpinfo ();?>"
Save

When we randomly set a variable Webshell value of "<?php phpinfo ();?>", the server can be Getshell. Visible has been written to:

The exported rdb is actually a binary file, but because it contains <?php phpinfo (), it is parsed:

In the previous illustration, we can see that a appendonly.aof is actually generated, can this file name be customized? Unfortunately, the Appendfilename value cannot be defined using the Config SET command:

But the only one dbfilename is enough.

Therefore, if you sweep to Redis unauthorized access, do not rush to submit the dark clouds. See if the server has Web services, and if so, try to win Webshell.

Comparison of application indices between MongoDB and Redis

MongoDB and Redis are both NoSQL, using structured data storage. There is a certain difference between the two in the use of the scene, which is mainly due to
In the process of memory mapping, the methods of persistence are different. MongoDB recommends cluster deployments, taking more account of cluster scenarios, Redis
More focused on process-sequential writes, although cluster support is also limited to master-from mode.

indicator	MongoDB (v2.4.9)	Redis (v2.4.17)	Comparison notes
Implementing language	C++	C + +	-
Agreement	Bson, Custom Binary	Class Telnet	-
Performance	dependent on memory, higher TPS	dependent on memory, TPS is very high	Redis is superior to MongoDB
operability	Rich data expression, index, most similar to relational database, support rich query language	Data rich, less IO	MongoDB is superior to Redis
Memory and Storage	Suitable for large amount of data storage, rely on the system virtual memory management, using mirrored file storage, memory share is relatively high, the official proposal to deploy independently in 64-bit systems (32-bit with the maximum 2.5G file limit, 64-bit without changing the limit)	Redis2.0 after adding virtual memory characteristics, breaking the physical memory limit; The data can be set to be time-sensitive, similar to the Memcache	Different application angle, each has the advantage
Availability of	Support Master-slave,replicaset (internal use of Paxos election algorithm, automatic fault recovery), auto sharding mechanism, shielding the client from the fault transfer and segmentation mechanism	Rely on the client to achieve distributed read-write, master-slave replication, every time from the node to reconnect the main node to rely on the entire snapshot, no incremental replication, no support for automatic sharding, need to rely on the program to set consistent hash mechanism	MongoDB is superior to Redis, the MongoDB application is simple, the relative user is transparent, the redis is more complicated, and it needs the client to solve the problem proactively. (MongoDB typically uses replica sets and sharding functionality, replica sets focus on high availability and reliability, while Sharding focuses on performance, scalability)
Reliability	Since version 1.8, the binlog approach (which MySQL uses in the same way) supports persistence and increases reliability	Rely on snapshots for persistence, aof enhance reliability, and increase reliability while impacting access performance	MongoDB is superior to Redis
Consistency	Do not support things, rely on the client itself to ensure	Support things, weaker, only to ensure that the operation of things in order to execute	Redis is superior to MongoDB
Data analysis	Built-in data analysis function (MapReduce)	does not support	MongoDB is superior to Redis
Application Scenarios	Improved access efficiency of massive data	Performance and operation of smaller data volumes	MongoDB is superior to Redis

The difference between Redis, memcached and MongoDB

If you simply compare the differences between Redis and memcached, most will get the following view:

1 Redis not only supports simple k/v types of data, but also provides storage of data structures such as List,set,hash.

2 Redis supports backup of data, that is, data backup in Master-slave mode.

3 Redis Support Data persistence, you can keep the data in memory on disk, restart can be loaded again to use.


In Redis, not all data is stored in memory. This is the biggest difference compared to memcached (I personally think so).


Redis only caches all key information, and if Redis finds that memory usage exceeds a certain threshold, the operation of swap will be triggered, Redis according to "swappability = Age*log (size_in_memory)" calculates which key corresponding value needs to be swap to disk. The value corresponding to these keys is then persisted to disk and purged in memory. This feature allows Redis to maintain data that exceeds the memory size of its machine itself. Of course, the memory of the machine itself must be able to maintain all key, after all, the data is not swap operation.


At the same time, because Redis will swap the data in memory to disk, the main thread of the service and the child thread that carries out the swap share this part of the memory, so if you update the data that requires swap, REDIS will block the operation until the child thread completes the swap operation before it can be modified.


You can refer to the comparison of scenarios before and after using the Redis-specific memory model:


VM off:300k keys, 4096 bytes values:1.3g used

VM on:300k keys, 4096 bytes values:73m used

VM off:1 million keys, 256 bytes values:430.12m used

VM on:1 million keys, 256 bytes values:160.09m used

VM on:1 million keys, values as large as you want, still:160.09m used


When reading data from Redis, if the value of the read key is not in memory, then Redis will need to load the corresponding data from the swap file and return it to the requester. There is a problem with the I/O thread pool. By default, Redis will be blocked, that is, all the swap files will be loaded before the corresponding. This strategy is relatively small in number of clients and is appropriate for bulk operations. But if you apply Redis to a large web site application, this is obviously not a big concurrency scenario. So Redis run we set the size of the I/O thread pool to perform concurrent operations on the read requests that need to load the corresponding data from the swap file, reducing the blocking time.


Redis, Memcache, mongoDB contrast

From the following several dimensions, to Redis, Memcache, MongoDB made a comparison, welcome to Pat Bricks


1, Performance

are relatively high, performance for us should not be a bottleneck

On the whole, TPS is similar to Redis and Memcache, more than MongoDB


2, the convenience of Operation

Memcache Data Structure Single

Redis rich, data manipulation aspects, Redis better, fewer network IO times

MongoDB support rich data expression, index, most similar relational database, supported query language is very rich


3, the size of memory space and the size of the volume of data

Redis adds its own VM features after version 2.0, breaking the physical memory limit; You can set an expiration time on key value (similar to memcache)

Memcache can modify the maximum available memory, using the LRU algorithm

MongoDB suitable for large data storage, rely on operating system VM to do memory management, eat memory is also more powerful, service and other services not together


4, availability (single point of issue)

For a single point of issue,

Redis, rely on the client to achieve distributed read-write, master-slave replication, each time from the node to reconnect the primary node to rely on the entire snapshot, no incremental replication, due to performance and efficiency issues,

Therefore, the problem of single point is more complicated, and it is necessary to set the consistent hash mechanism for the dependent program without support for automatic sharding.

An alternative is to use your own proactive replication (multiple storage) or incremental replication (which requires your own implementation) without redis the replication mechanism of itself, consistency issues and performance tradeoffs

Memcache itself has no data redundancy mechanism, nor is it necessary for fault prevention, using a mature hash or loop algorithm to solve the problem of jitter caused by single point of failure.

MongoDB Support Master-slave,replicaset (internal use of Paxos election algorithm, automatic fault recovery), auto sharding mechanism, shielding the client from the fault transfer and segmentation mechanism.


5. Reliability (Durability)

For data persistence and data recovery,

Redis support (snapshots, AOF): Rely on snapshots for persistence, aof enhance reliability while impacting performance

Memcache is not supported, usually used in doing caching, improve performance;

MongoDB from version 1.8 to support persistent reliability with binlog approach


6. Data Consistency (transactional support)

Memcache in concurrent scenarios, with CAS to ensure consistency

Redis transaction support is weaker, only ensuring that each operation in a transaction is executed continuously

MongoDB does not support transactions


7. Data Analysis

MongoDB Built-in data analysis features (MapReduce), others do not support


8, the application scene

Redis: More performance operations and operations with smaller data volumes

Memcache: Used in dynamic system to reduce database load, improve performance, do caching, improve performance (suitable for read and write less, for large amount of data, you can use sharding)

MongoDB: Mainly solve the problem of access efficiency of massive data