通过MySQL使用NoSQL数据库

Question

我有一个运行在Java stack (Struts2+ Spring + Hibernate)上的web应用程序，并持久化在MySQL中。我研究了NoSQL数据库，与关系型数据库相比，它们确实更容易理解和使用。这是一个存储艺术家信息并允许用户保存播放列表的音乐流媒体应用程序。

我想知道它是否有任何优势(性能？，硬件成本？，简化的代码？，可伸缩性？)切换到NoSQL DB (CouchDB？、MongoDB？、Cassandra?)。切换到NoSQL数据库会有什么得失？

请给我建议。

Answer 1

对"NoSQL“的礼貌解释已经变成了Not Only SQL。如果您的数据确实是真正的关系型数据，或者如果您的功能依赖于joins和ACIDity之类的东西，那么您应该以关系型方式存储这些数据。在这篇文章中，我将解释如何与两个NoSQL数据存储一起使用MySQL。现代的web规模的数据存储都是关于如何为工作选择最佳工具的。

也就是说，NoSQL实际上是对以下事实的一种反应:关系方法和思维方式已经被应用于它实际上不是很适合的问题(通常是具有数千万行或更多行的大型表)。一旦表变得这么大，典型的SQL“最佳实践”就是手动分割数据--即在表A中放置记录1到10,000,000，在表B中放置记录10,000,001到20,000,001，依此类推。然后，通常在应用程序模型层中，根据该方案执行查找。这就是所谓的application-aware scaling。它很耗时且容易出错，但是为了在维护长表存储的MySQL的同时进行扩展，它或多或少已经成为了一种标准的MO。对我来说，NoSQL代表了application-unaware的替代方案。

键值

当我的MySQL原型开始变得太大而无法发挥作用时，我个人将尽可能多的数据转移到闪电般的Membase上，它的性能优于Memcached，并增加了持久性。Membase是一个分布式键值存储，通过在集群中添加更多的商用服务器，它可以或多或少地线性扩展(例如，Zynga使用它来处理每秒50万次操作) --因此，它非常适合Amazon EC2、Joyent等云时代。

众所周知，分布式键值存储是获得巨大线性规模的最佳方式。键值的缺点是可查询性和索引性。但是，即使在关系世界中，可伸缩性的最佳实践也是将尽可能多的工作卸载到应用程序服务器上，在商用应用程序服务器上的内存中进行联接，而不是要求中央RDB集群处理所有这些逻辑。由于simple select + application logic确实是在MySQL上实现大规模的最佳方式，因此过渡到Membase (或它的竞争对手，如Riak)并不是太糟糕。

存储的文档

有时--尽管我不会经常争论--应用程序的设计本质上需要二级索引、范围可查询性等。针对这一点的NoSQL方法是通过像MongoDB这样的document store。像Membase一样，Mongo在关系数据库特别薄弱的领域非常好，比如application-unaware scaling、auto-sharding和maintaining flat response times even as dataset size balloons。它比Membase慢得多，而且做纯水平缩放有点棘手，但好处是它的可查询性很高。您可以实时查询参数和范围，也可以使用Map/Reduce对真正庞大的数据集执行复杂的批处理操作。

在我上面提到的同一个项目中，我们使用MongoDB来存储分析/指标数据，这才是Membase真正闪亮的地方。

为什么要在SQL中保留内容

我简要地谈到了“真正的关系”信息应该留在关系数据库中的事实。正如评论员Dan K.所指出的，我错过了讨论离开RDBMS的缺点的部分，或者至少完全离开RDBMS的部分。

SQL首先是本身，是众所周知的，并且在很长一段时间内一直是行业标准。一些"NoSQL“数据库，比如谷歌的App Engine数据存储(构建在Big Table上)实现了他们自己的类似SQL的语言(谷歌的被巧妙地称为Google Query Language的GQL )。MongoDB通过其令人愉快的JSON query objects采用了一种全新的方法来解决查询问题。尽管如此，SQL本身仍然是从数据中获取信息的强大工具，这通常是数据库的出发点。

使用关系型数据库管理系统最重要的原因是ACID或Atomicity, Consistency, Isolation, Durability。我不会重新散列Acid-NoSQL的状态，因为在this post中已经很好地解决了这个问题。可以这么说，Oracle's RDBMS拥有如此巨大的市场是有原因的:有些数据需要纯粹的ACID遵从性。如果您的数据是这样的(如果是这样，您可能很清楚这一点)，那么您的数据库也是如此。保持低pH！

编辑：查看here.的帖子他比我更好地代表了企业对企业的视角，部分原因是我的整个职业生涯都在消费者领域。

Answer 2

我认为这在很大程度上取决于您想要存储在数据库中的内容。我没有使用CouchDB或Cassandra的经验，所以我会让别人为我代言，但我经常使用MongoDB和MySQL。

如果您正在开发需要事务的应用程序，例如帐单应用程序，您肯定会想要使用MySQL，因为它支持事务。MySQL是ACIDic，即它是原子的、一致的、隔离的和持久的。这实际上意味着，当您在MySQL中更新一行时，它肯定会发生。然而，MySQL的问题是它不能很容易地水平扩展(通过添加越来越多的服务器)。MySQL服务器倾向于通过添加更多的内存、硬盘空间等来进行垂直扩展，但它们最终会达到一个天花板，它可能会带来巨大的成本。

MongoDB是一个文档数据库。它将类似JSON的文档存储在集合中，并且是无模式的-因此每个文档可以是不同的。这对于你的应用程序的灵活性来说是非常好的。许多开发人员说，noSql解决方案更多地是为程序员开发的，而且它们往往更容易构建(根据我的经验)。此外，MongoDB通过将数据库分成块进行水平扩展。事实上，现在甚至可以实现自动化。

但使用MongoDB也有缺点。如果您在生产中使用它，那么您真的必须将它放入一个复制从设备中。这是因为MongoDB没有完整的单服务器持久性。因此，如果您遇到电源故障，您可能必须修复整个MongoDB数据库，这可能需要几个小时。如果你资金充足，这在成本上可能不是什么大问题，但如果你是一个新组织，资金很少，这可能会很困难(使用云计算？)。此外，MongoDB不支持事务，这是保证原子性和隔离性所必需的。最后，MongoDB只是最终是一致的(尽管我已经看到了这一论点的几个方面)-这意味着当写入发生时，不能保证所有其他进程立即看到信息-只有最终。

在我看来，如果你正在存储关于曲目的艺术家信息和元数据，那么MongoDB将是一个很好的解决方案。如果你在存储用户数据、帐单数据等，那么将其存储在MySQL中。

Answer 3

这个问题只有一个正确的答案:只有在您遇到性能问题或您希望流量大幅增加并(通过压力测试)测量到您的体系结构不适合的情况下才更改您当前的解决方案。

否则，甚至不需要评估替代方案。