时间：2021-07-01 10:21:17 帮助过：5人阅读
与许多流行词一样，NoSQL在大肆宣传后，许多荒谬的观点产生，本篇文章将揭穿其中广被认同的5个。
从根本上说，NoSQL数据库系统的几大属性都不是出于关系模型，而关系模型首次揭露是在1970年 Codd发布的文章中。
那么，这是否就意味着在1970年之前不存在任何其它的数据库系统？不容争论的是，这些数据库却是真实存在，比如CODASYL系统，它显然不是关系型数据库；基于其主要属性，NoSQL的诞生其实明显早于传统关系型数据库。
从长远上看，这个流言的影响更为恶劣。虽然许多NoSQL解决方案都不会强迫你使用严格的数据结构模型，但是绝对不意味它可以忽视。而在实际操作中也是恰恰相反的，随着时间的流逝，你必须明白你为什么要使用这些属性。
有些情况可能会更加危险，举个MongoDB的例子：作为一个良好的实践，许多经验丰富的用户都会建议去建立文档的属性，在文档大小改变时，通过预分配大小去避免文档的完整拷贝。还有在查询优化时，你必须要清楚你的结构模型以便做索引。
高扩展性是NoSQL的主要卖点之一，但是仅仅选择一个NoSQL解决方案并不意味着扩展性问题的解决，真正解决问题的是优秀的架构。
不错，这里确实存在通过选择NoSQL让系统扩展性得到了大幅度的提升。然而胜利的背后依稀可见的是数据结构的变化，在特定场景下使用正确的结构替换错的。
这个流言中有趣的地方是忽略了同样提供优秀扩展性的关系型数据库，不错，使用NoSQL方案进行扩展确实非常容易，但是NoSQL的选择绝对不是问题解决的唯一功臣。
你如何才能公平的比较两个完全不同的持久化方案，比如：键值、关系、文档等等。而当下许多NoSQL与关系型数据库的对比也并不公平。
当你的查询只涉及一个键时，NoSQL数据库的性能明显要优于关系型数据库。公平的基准应该建立在同类型产品的比较之上，类似MySQL与MongoDB的对比根本无任何意义。即使系统性能取得了巨大提升，也只是开始时使用了错误的数据结构模型而已。
这一点只发生在梦中，或者是开始选择了错误的工具。在选择NoSQL之前，我们已经使用了多年的关系型数据库，这里只存在团队花大量精力去适应NoSQL的情况。
很少人谈及这一点， NoSQL采用最大的挑战是文化，而不是技术。新事物之所以难以接受，是因为“老伙计”用起来很舒服，即使新事物更加得优秀。生产力源于实践，而不是魔术。
对比近年来研发领域发生的事件，NoSQL绝对可以称得上最有意义之一；然而需要铭记的是，任何提升都需要付出同等的代价。
原文链接： Some myths about NoSQL