无论你是使用关系型数据库系统、哈希表，还是其它结构来维护数据，你肯定对NoSQL和大数据有所耳闻。 目前，谷歌、雅虎和亚马逊等公司都已经在开发或者使用大数据/NoSQL的解决方案。但除了一些非常具体的案例外，这些大数据的实现方案真的那么有用吗？在近期的一篇文章中，凯捷咨询公司的史蒂夫·琼斯甚至指出有时候大数据可能就是一大骗局，或者至少还不能完全成为一种万能药，可以解决原有关系型数据库管理系统实现方案中的各种问题，这些你可能都已经注意到了：
我注意到市场上对大数据的宣传已成泛滥之势。有些公司将这种容量的爆炸式增长看作是历史、新技术、新方法延续的一部分，只是发展 而不是变革。诚然，Map Reduce技术很酷，但它的技术难度也远胜于SQL和数据库设计，因此这也意味着该技术远不能成为一种商业上的万能药。
史蒂夫接着指出，可用于存储极为重要且有一定规模数据集的内存数据库技术（基于关系型数据库管理系统）不久将成为现实。他通过引用一篇文章来阐述自己的观点，该文章讨论了数年前，雅虎是如何使用一种经过重大修改的Postgres实现来存储2PB数据的：
下面是大数据的要点：它95%以上都只是以指数级持续增长的数据，这是与增强的处理能力和存储容量相匹配的，或者至少是随之增长 的。（……）当然，对索引的优化可能更难，并且你可能要将数据来回移动到固态硬盘上，但严格来说，这样数据量就变得“更大”了，而不是一次简单的数据移 动。
我们过去也从Mike Stonebraker这些人那里听说过类似的事情，他表示许多用户都将受益于诸如重新构建的关系型数据库管理系统和列存储等方法，从而尽可能多地利用主存和固态硬盘，同时仍能保持传统较强的一致性、ACID语义，并在某些情况下可以使用SQL。但史蒂夫接着重新强调了Map Reduce技术，并且认为这一实现方案背后的模型需要你就如何存储、查询和操作数据有一种不同的思维方式，在某种程度上，用户要将这种解决方案集成到他们现有的投资环境中就变得更加困难了。
就像不会有那么多人能够准确地用多线程的方式思考一样，也不会有那么多人能够用Map Reduce的方式思考。
当我们经常听到新的实现方案，或者厂商指望着能鼓动我们采用他们的解决方案时，这又把大数据置于何地呢？根据史蒂夫的观点：
我们发现人们使用大数据的方式和使用SOA一样，贴个标签，然后就宣称 “集成了Hadoop”或“集成了社交媒体（social media）”，或者换个说法，“我们已经建立了一个连接器”。看看刚刚那个让你大跌眼镜的说法吧。它只是一种老式的学校企业应用集成（EAI）连接器， 不过连接到新数据源或新ETL连接器而已。
这可能算是一种笼统的说法，但也说明了一些事实。因为现在有过多的炒作，并且太多的厂商都在自己的实现方案上贴上了NoSQL/大数据的标签，但其 实这些实现方案对于手头上的任务并不适合，那么在这种“新的数据解决方案”的背后是否有丢失核心信息的风险呢？正如史蒂夫所指出的，这种状况可能跟SOA 的早期应用状况相似，那时各厂商都在自己的解决方案上贴上SOA的标签，但实际上大多数方案都根本不是SOA。那么你如何准确衡量你需要的是大数据的解决 方案，还是提供给你的是场大骗局（正如史蒂夫所言）呢？史蒂夫提出了一些建议，至少可以在评估厂商的解决方案时使用。其中包括：
- 你可以用“大数据库（Big Database）”来代替“大数据”吗？如果可以，那它就只是一次更新。
- “高级”可以简化成“我们刚刚获得一个企业应用集成连接器”吗？
- 是否与2009年的产品基本相同，只不过在新产品上贴上了大数据/NoSQL的标签？
- 有什么方法可以将处理流程移动到数据上进行，而不是到处移动数据吗？这是过去包括Jim Grey在内的很多人都建议的做法。
不幸的是这些“规则”都不具有科学性，并且都需要某种程度的主观判断。那么还有其它规则可用吗？如果你已经从传统的关系型数据库管理系统迁移到别的 平台上，那么你是使用什么来决定迁移的必要性，以及如何选择要迁移到的具体实现方案呢？这种迁移工作是否成功？如果不成功，又是为什么呢？
查看英文原文：Big Data: Evolution or Revolution?