A real Case Comment on migrating from Redis to MongoDB: Simply put, because of Variety, Redis is more suitable for scenarios where a key corresponds to a single value. The JSON format of MongoDB is more suitable for scenarios with richer data. A customer approached us with the new NoSQL data requirements of an instrument system. We have helped them before. For some historical reasons,
A real Case Comment on migrating from Redis to MongoDB: Simply put, because of Variety, Redis is more suitable for scenarios where a key corresponds to a single value. The JSON format of MongoDB is more suitable for scenarios with richer data. A customer approached us with the new NoSQL data requirements of an instrument system. We have helped them before. For some historical reasons,
A real case of migrating from Redis to MongoDB
Comments:
Simply put, because of Variety, Redis is more suitable for scenarios where a key corresponds to a single value, and the JSON format of MongoDB is more suitable for scenarios with richer data.
A customer approached us with the new NoSQL data requirements of an instrument system. We have helped them before.
For some historical reasons, they have collected a large amount of important sensor data and stored it in a dedicated Redis database. Redis's "key-value structure works well and they only collect one value for each key. However, when a new error check rule asks them to add a timestamp for each data point, they feel clumsy, so each key has to store two values. To achieve this, Redis needs to use a manual Separator in the value field or use the same key for each of the two Redis databases to retrieve their respective values and associate them according to the key.
However, during our conversation, we found that they had a painful and complex statistical requirement. Exploring this demand actually promotes our recommendation-the final migration to MongoDB.
Here is the background: the universally recognized method for processing data sampling is easy to implement in Redis. Each data point is most common when separated by three times or when multiple independent sensors read data.
This looks like a data volume problem, but they also want to collect a lot of information about the sensor environment, sensor diagnostic information, sensor layout data, experiments are carried out with the sensor calibration and recording of the sensor test results.
Their data looks more complex and changes the format more frequently. They can bend Redis jobs and documents where the data is, and hope-in vain, maybe for future developers to read. Alternatively, they can use the NoSQL style flexibility of MongoDB, coupled with the free nature of the document mode of each MongoDB to create a flexible self-document data storage. Technically speaking, they now have complex and real-time flexibility requirements, and they are the expertise of NoSQL databases with no pattern design.
Although their sensor data remains unchanged, their metadata-timestamps, locations, and environmental factors-data points about each sensor are much more complex. And quick change. However, the speed at which MongoDB processes data writing and Data Reading, and the speed at which they change their data format!
Did they drop Redis? Far from that. They are using it more than they are. But they have changed how they use it. They also use it to keep the key-value data that they know will be simple to their future needs. They are using it as a simple cache to store session data
Refer:
Http://www.rackspace.com/blog/migrating-from-redis-to-mongodb-a-real-world-example/
Original article address: a real case of migrating data from Redis to MongoDB. Thank you for sharing it with the original author.