从Redis迁移到MongoDB的一个真实案例 点评： 简单说因为Variety,Redis更适合作为一个key对应单个value的场景，MongoDB的JSON格式更适合数据更丰富的场景。 一位顾客带着一个仪器系统新的NoSQL数据的要求走近我们，我们之前已经帮过他们。 由于一点历史原因，
从Redis迁移到MongoDB的一个真实案例
点评：
简单说因为variety,redis更适合作为一个key对应单个value的场景，mongodb的json格式更适合数据更丰富的场景。
一位顾客带着一个仪器系统新的NoSQL数据的要求走近我们，我们之前已经帮过他们。
由于一点历史原因，他们已经收集到了大量重要的传感器数据，并将其存储在一个专用的Redis数据库。 Redis的“键 - 值结构运作良好时，他们只为每个键收集一个值。 然而，当一个新的错误检查规定要求他们为每个数据点增加一个时间戳就感到笨拙了，因此每个键不得不存储两个值。 要做到这一点Redis需要在值字段使用人工分隔符或者两个Redis数据库每个使用相同的键来检索各自的值，根据键来关联。
然而，我们的谈话过程中发现他们有一个痛苦的复杂的统计需求。 探究这种需求，实际上推动了我们的推荐——最终迁移到MongoDB。
这里是背景：处理数据采样问题的普遍认可的方法是很容易在Redis的实现。 每个数据点使用3个时间分隔或多个独立的传感器读可能是最常见的。
这看起来像一个数据量的问题，但他们也希望收集有关各地各传感器的环境多得多的信息，以及传感器的诊断信息，传感器布局数据，并与传感器校准和记录传感器的测试结果进行实验。
他们的数据看起来更复杂，并会改变格式更加频繁。他们可以弯曲的Redis的任务和文档哪些数据是在哪里，希望 - 白费也许 未来的开发者阅读。或者，他们可以利用MongoDB的NoSQL的风格的灵活性，再加上每个MongoDB的文档的模式自由的性质来建立一个灵活的自文档化的数据存储。从技术上来说，他们现在有复杂的和即时灵活性的需求，正是无模式设计的NoSQL数据库的专长。
尽管它们的传感器数据保持不变的性质，它们的元数据 - 时间戳，位置，环境因素 - 关于每个传感器的数据点是要复杂得多。 和快速变化。 但是MongoDB的处理数据写入和数据读出的速度，以及与它们改变他们的数据格式的速度！
他们有没有下降Redis的？ 远非如此。 他们正在使用它超过他们。 但他们已经改变了他们如何使用它。 他们还用它来与他们知道会保持简单到未来需求的key-value数据。 他们正在使用它作为一个简单的缓存存储会话数据
参考：
http://www.rackspace.com/blog/migrating-from-redis-to-mongodb-a-real-world-example/
原文地址：从Redis迁移到MongoDB的一个真实案例, 感谢原作者分享。
