我有一个运行在Java堆栈(Struts 2 + Spring + Hibernate)上并使用MySQL进行持久化的Web应用程序。我看过NoSQL数据库,它们比关系型数据库更容易理解和使用。这是一个音乐流媒体应用程序,用于存储艺术家信息并允许用户保存播放列表。
我想知道是否有任何优势(性能?硬件成本?简化代码?扩展性?)可以切换到NoSQL数据库(CouchDB?MongoDB?Cassandra?)。如果切换到NoSQL数据库,我会失去/获得什么?
请给予建议。
我有一个运行在Java堆栈(Struts 2 + Spring + Hibernate)上并使用MySQL进行持久化的Web应用程序。我看过NoSQL数据库,它们比关系型数据库更容易理解和使用。这是一个音乐流媒体应用程序,用于存储艺术家信息并允许用户保存播放列表。
我想知道是否有任何优势(性能?硬件成本?简化代码?扩展性?)可以切换到NoSQL数据库(CouchDB?MongoDB?Cassandra?)。如果切换到NoSQL数据库,我会失去/获得什么?
请给予建议。
键-值
当我的MySQL原型开始变得过于庞大时,我个人将尽可能多的数据移动到闪电般快速的Membase,它比Memcached表现更好,并且具有持久性。Membase是一个分布式键-值存储,通过将更多的商品服务器添加到集群中,可以实现更多或更少的线性扩展(例如,Zynga使用它处理每秒半百万次操作),因此非常适合Amazon EC2,Joyent等云时代。
众所周知,分布式键-值存储是获得巨大的线性规模的最佳方法。键-值的弱点是可查询性和索引。但即使在关系型世界中,可扩展性的最佳实践也是尽可能多地将工作转移到应用程序服务器上,在商品应用程序服务器上内存中执行连接,而不是请求中央RDB集群处理所有那些逻辑。由于简单选择
加上应用程序逻辑
确实是实现大规模扩展的最佳方法,甚至在MySQL上,转换到类似Membase(或其竞争对手,如Riak)并不是太难。
文档存储
有时候——虽然我认为这种情况比许多人想象的要少——应用程序的设计本质上需要二级索引、范围查询等功能。NoSQL 的解决方案是通过像 MongoDB 这样的文档存储来实现的。与 Membase 一样,Mongo 在关系数据库特别薄弱的一些领域表现得非常出色,例如 不受应用程序影响
的扩展、自动分片
和 即使数据集大小急剧增加也能保持平坦响应时间
。它比 Membase 慢得多,并且在纯水平扩展方面有点棘手,但好处是它高度可查询。您可以实时查询参数和范围,或使用 Map/Reduce 在极大的数据集上执行复杂的批量操作。
在我之前提到的同一个项目中,我们使用 Membase 来提供大量实时玩家数据,而使用 MongoDB 存储分析/指标数据,这正是 MongoDB 的优势所在。
为什么要将东西保存在SQL中
我简要提到了“真正关系型”的信息应该留在关系数据库中。正如评论者Dan K.指出的那样,我漏掉了讨论离开RDBMS或至少完全离开它的缺点的部分。
首先,这里有SQL本身。 SQL是众所周知的,并且已经成为行业标准很长时间了。一些“NoSQL”数据库(例如Google的App Engine Datastore(基于Big Table构建))实现了自己的类似SQL的语言(Google的被称为可爱的GQL,即Google查询语言
)。MongoDB通过其令人愉悦的JSON查询对象对查询问题采取了新的方法。尽管如此,SQL本身是从数据中获取信息的强大工具,这通常是数据库的整个目的。
原子性、一致性、隔离性、持久性
。我不会重新讲解Acid-NoSQL的状态,因为这在这篇帖子上已经很好地解决了。可以说,有一个理性的原因Oracle的RDBMS拥有如此巨大的市场,并且它不会消失:某些数据需要纯粹的ACID合规性。如果你的数据需要(如果需要,你可能已经非常清楚),那么你的数据库也需要。保持pH低!
编辑:请查看Aaronaught在这里的帖子。他更好地代表了商业对商业的观点,因为我整个职业生涯都在消费领域。
对于这个问题,只有一个正确的答案:仅在您遇到性能问题或者预计流量大幅增加并且通过压力测试测量出您的架构不适合时才更改当前解决方案。
否则 - 没有必要评估其他替代方案。
由于一些人喜欢Aaronaught的答案,但相应的问题已被删除,因此我从Stackoverflow archive中复制了他的答案:
在人们开始称之为“NoSQL”之前,这项技术的原始名称是分布式键/值存储。这是一个更具描述性的名称,我最初记得看到它时说,“嘿,很酷,我敢打赌这将对许多人非常有用。”此术语后来扩展到基本上包括“任何不是关系数据库”的内容,但通常,当大多数人谈论NoSQL时,他们正在谈论键/值存储。我发现 NoSQL 数据库不适合原型制作,因为你必须按照获取数据的方式来构建数据结构。使用 NoSQL 时,模式需要匹配查询需求。但在原型设计中,你还不知道如何提取数据,你会发现自己要么进行过多的查询,要么每次想添加新功能时都需要重新设计模式。
使用关系数据库,你只需要规范化数据,就可以随意提问。只有在模型与真实世界的实体没有正确匹配时,才需要重新设计模式。
我不得不多次重构我的 MongoDB 数据库,在 Web 应用程序中每次添加新数据查看方式时都要重构一次。毫不奇怪,我正在趋向于采用关系模式,以更好地利用文档数据库可能具有的嵌套数组和对象。
如果你四处寻找,会发现 NoSQL 最成功的用途是针对那些使用关系数据库开发应用程序的人。现在他们已经了解了它们的特性,并可以切换到 NoSQL,明确地知道如何满足自己的查询需求。如果你仍在探索应用程序及其所需数据库的问题类型,我建议坚持使用关系数据库。