一位我们曾帮助过的用户，最近又联系了我们，提出对于他们仪表系统构建NOSQL数据库的需求。
在过去的时间里，他们收集了大量重要的传感器数据，并将其存储在一个专用的Redis数据库内。 当他们为每个键收集一个值时，Redis的键值结构运作良好。然而，当一个新的错误检查需求出现，要求它们为每个数据点添加一个时间戳时，每个键要存储两个值， Redis运作就有些笨拙。这样做需要应用值域的人工分隔符或者使用两个Reids数据库，每个数据库都使用相同的键来检索与每个键相关联的独立值。
两者都是低成本或是无成本实现， 他们选择了分隔符的方法，运用 ‘::’ 作为分隔符。当然，他们知道不能像这样持续扩展键值范式， 因为新的数据记录需求出现了，但是运作良好。它几乎不需要改变任何现有的生产代码，只用足够的内存来存储附加的数据点。
他们还使用Rackspace的Redis服务，以检测他们的服务代码，同时继续为现有的数据存储写入实时数据。
他们联系到我们，让我们对他们将传感器数从276升级到8000（增加29X数据量）进行风险评估， 那时似乎已经决定向更复杂的NoSQL数据转移。
他们担心Redis内存数据模型可能会限制他们可以迅速访问的数据量。 然而，当我们计算出他们Redis 数据存储使用的内存以及它的成长速度，很快我们就给他们展示，在接下来的一二十年里，完全不用担心。
然而，谈话过程中我们认识到， 复杂的数据转换对于他们是一种煎熬。基于这些体验，使我们的推荐变得更有力 — 走处他们的最后一步 — 向MongoDB转移。
他们的数据看起来更复杂，也会更频繁的改变形式。他们努力使redis能够满足自己的需求。 或者，他们可以利用MongoDB 的NoSQL风格的灵活性，再加上每个MongoDB文档自由形式的性质来创建一个灵活的自文档数据存储。严格来说，他们现在要求无模式数据库设计复杂性以及实时灵活性。
我们几乎没花费什么努力向他们展示mongodb的面向文档Document特性，就让他们相信MongoDB的JSON式文档布局能够使他们在研发产品时，达到实时的灵活性。
这种迁移的一个关键推动因素是，Rackspace公司同时提供Redis和MongoDB服务，但在为用户做迁移项目时我们几乎没有把老的硬件废弃或者重新配置，一切都来得很自然融洽。需要的仅仅是给出IP和端口号，然后客户自己来实现代码。
尽管它们的传感器数据在本质上是一样的，但是它们的元数据—时间戳，位置，环境因素 – 关于每个传感器的数据点是要复杂得多。而且变化速度很快。但MongoDB完全能够跟上处理数据写入的速度和数据读出的速度，以及它们改变其数据格式的进度！
他们已经放弃Redis了吗？远非如此。 事实是比以前使用的更多。但他们已经改变了使用的方式。 他们仍然在使用它的键值数据， 因为他们知道这不管是现在还是将来都会很简单。他们正在使用它作为一个简单的缓存存储会话数据 – 一种技术，在世界上不同的网络应用，使重度依赖会话的网络（session-heavy Web）应用程序扩大规模。也许最常见的情景是，顾客使用它的缓存来加速应用程序， 如Magento，Redis是Magento面对伸缩性方面挑战中深度防御缓存方式中的一级高速缓存层。
想知道更多关于Redis灵活性的极好论述， 可以访问Ken Seguin的博客文章“数据库存储中瑞士军刀”，网址：http://openmymind.net/Redis-Is-The-Most-Important-Tool-在-MY-Toolbelt /
他们也正在使用它，加速实施速度来创建运行代码的实时数据存储。这加快了研发速度，因为它创建了一个简单查询列队，可以轻松回顾数据，无论使用它的代码状态如何。 除了其语言为开发者所喜爱之外，它规范了不同数据的传输 — 有时是互相矛盾的 — 代码集, 这真的非常有助于开发。
Leave a Reply