在MySQL上使用NoSQL数据库

我有一个在Java堆栈上运行的Web应用程序（Struts 2 + Spring + Hibernate）并且在MySQL中持久存在。我查看了NoSQL数据库，它们比RDBMS更容易推理和使用。这是一个音乐流媒体应用程序，存储艺术家信息，并允许用户保存播放列表。

我想知道切换到NoSQL DB（CouchDB？，MongoDB？，Cassandra？）是否有任何优势（性能？，硬件成本？，简化代码？，可扩展性？）。切换到NoSQL数据库会给您带来什么损失？

请指教。

对“NoSQL”的礼貌解释已成为Not Only SQL 。如果您的数据确实是真正的关系，或者您的function取决于连接和ACIDity之类的东西，那么您应该以关系方式存储该数据。在这篇文章中，我将解释如何将MySQL与两个 NoSQL数据存储一起使用。现代的网络规模数据存储就是要了解如何为工作选择最佳工具。

也就是说，NoSQL实际上是对这样一个事实的反应：关系方法和思维方式已经应用于实际上并不适合的问题（通常是具有数千万行或更多行的大表）。一旦表格变大，典型的SQL“最佳实践”就是手动对数据进行分片 – 即将表1中的记录1到10,000,000，表B中的10,000,001到20,000,001，依此类推。然后，通常在应用程序模型层中，根据该方案执行查找。这就是所谓的application-aware扩展。这是时间密集且容易出错的，但是为了在长桌面商店维护MySQL的同时扩展某些东西，它已成为一个或多或少的标准MO。对我来说，NoSQL代表了application-unaware替代方案。

核心价值

当我有一个MySQL原型开始变得太大而不是为了自己的好处时，我亲自将尽可能多的数据移动到闪电般快速的Membase ，它的性能优于Memcached并增加了持久性。 Membase是一个分布式键值存储，可以或多或少线性扩展（Zynga使用它来处理每秒50万次操作），方法是将更多商品服务器添加到集群中 – 因此它非常适合云时代亚马逊EC2 ， Joyent等

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

文件商店

有时候 – 虽然我认为不像许多人想的那么频繁 – 应用程序的设计固有地需要二级索引，范围可查询性等.NoSQL方法是通过像MongoDB这样的document store 。与Membase一样，Mongo在关系数据库特别弱的一些领域非常出色，比如application-unaware无意识缩放， auto-sharding以及maintaining flat response times even as dataset size balloons 。它比Membase慢得多，做纯水平刻度有点棘手，但好处是它具有很高的可查询性。您可以实时查询参数和范围，也可以使用Map / Reduce在真正庞大的数据集上执行复杂的批处理操作。

在我上面提到的同一个项目中，我使用Membase来提供大量的实时播放器数据，我们使用MongoDB存储分析/度量数据，这正是MongoDB的亮点。

为什么要保留SQL

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

首先，有SQL本身。 SQL是众所周知的，并且长期以来一直是行业标准。一些“NoSQL”数据库，如谷歌的App Engine数据存储（基于Big Table），实现了他们自己的类似SQL的语言（谷歌的名字很可爱， Google Query Language是GQL）。 MongoDB通过其令人愉快的JSON查询对象采用了一种全新的查询问题方法。尽管如此，SQL本身是一个从数据中获取信息的强大工具，这通常是数据库的重点。

保持RDBMS的最重要原因是ACID ，或Atomicity, Consistency, Isolation, Durability 。我不会重新讨论Acid-NoSQL的状态，因为它在SO上的post中得到了很好的解决。可以这么说，有一个理性的原因，甲骨文的RDBMS拥有如此巨大的市场，而这一市场无处可去： 一些数据需要纯ACID合规性 。如果您的数据确实存在（如果确实如此，您可能很清楚这一事实），那么您的数据库也是如此。保持低pH值！

编辑：查看Aaronaught的post。他比我更好地代表了企业对企业的观点，部分原因是因为我把我的整个职业生涯都花在了消费领域。

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

如果您正在开发需要事务的应用程序，例如计费应用程序，您肯定希望使用MySQL，因为它支持事务。 MySQL是ACIDic，它是Atomic，Consistent，Isolated和Durable。这实际上意味着当你更新MySQL中的一行时 – 保证发生这种情况。然而，MySQL的问题在于它不能非常容易地水平扩展（通过添加越来越多的服务器）。 MySQL服务器往往通过增加更多内存，硬盘空间等垂直扩展，但它们最终达到了上限，并且可能会产生巨大的成本。

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

但是使用MongoDB有一些缺点。如果你在生产中使用它，你真的必须用它来放置一个复制从属。这是因为MongoDB没有完整的单服务器持久性。因此，如果您遇到电源故障，您可能需要修复整个MongoDB数据库，这可能需要数小时。如果您的资金充足，这可能不是一件大事，但如果您是一个资金不多的新组织，那么就很困难（使用云计算？）。此外，MongoDB不支持保证primefaces性和隔离所必需的事务。最后，MongoDB最终只是一致的（尽管我已经看到了这个论点的一些方面） – 这意味着当写入发生时，所有其他进程都不能保证直接看到信息 – 只是最终。

在我看来，如果你存储艺术家信息和关于轨道的元数据，那么MongoDB将是一个很好的解决方案。如果您正在存储用户数据，计费数据等，则将其存储在MySQL中。

这个问题只有一个正确的答案：只有当您遇到性能问题或者预计流量大幅增加并且已经测量（通过压力测试）您的架构不适合时，才能更改当前的解决方案。

否则 – 甚至无需评估替代方案。

对于它的价值，我喜欢Aaronaught对这里提出的一个非常相似的问题的回答。

我发现NoSQL数据库很难用于原型设计，因为你必须知道如何将数据结构化。使用NoSQL，架构可以满足您的查询需求。但是在原型中，您还不知道如何获取数据，并且每次要在原型中添加新function时，您会发现自己要么执行太多查询，要么重构模式。

使用关系数据库，您只需标准化数据，就可以提出任何问题。如果模型与现实世界实体不匹配，则只需重构模式。

每次我添加一种新的方式来查看Web应用程序中的数据时，我不得不多次重构我的MongoDB数据库。毫不奇怪，我正在融合一个关系模式，它很少利用文档数据库可能的嵌套数组和对象。

如果你环顾四周，你会发现NoSQL最成功的用途是那些使用关系数据库开发应用程序的人，现在他们了解了他们的function，可以切换到NoSQL，知道要放入什么内容以满足他们的查询。如果您仍在探索您的应用以及您想要询问数据库的各种问题，我建议坚持关系。

有几个人喜欢Aaronaught的答案，但同时删除了相应的问题，我从Stackoverflow存档中复制了他的答案：

在人们开始称之为“NoSQL”之前，这项技术的原始名称是分布式键/值存储。这是一个更具描述性的名字，我原本记得看着它并且“嘿，很酷，我敢打赌这最终会对很多人非常有用。” 这个术语已经扩展到基本上包括“任何不是关系数据库的东西”，但通常，当大多数人谈论NoSQL时，他们谈论的是关键/价值存储。

自NoSQL这个词被创造以来，它一直被吹捧为银弹。我对像Cassandra这样的产品感兴趣并跟进他们的进展，但他们仍然是不成熟的技术，并声称他们“替换”SQL或RDBMS一般（或他们将在不久的将来）是充其量的似是而非的推理，如果不是一个彻头彻尾的谎言。

适合NoSQL保护伞的产品和技术适用于以下问题领域：

您计划部署一个大规模的高并发数据库（数百GB，数千个用户）;

哪个不需要ACID保证;

或关系或约束;

存储一组相当窄的数据（相当于SQL中的5-10个表）;

将在商用硬件上运行（即Amazon EC2）;

需要在非常低的预算下实施并“扩大规模”。

这实际上描述了今天的很多网站。谷歌和Twitter非常适合这些要求。如果一些推文丢失或延迟，这真的很重要吗？另一方面，这些规范适用于近0％的业务系统，这是我们很多人在开发方面的工作。大多数企业有不同的要求：

中到大型数据库（10-100 GB），并发性相当低（最多数百个用户）;

ACID（特别是A和C – primefaces性和一致性）是一项艰难的要求;

数据高度相关（层次结构，主要细节，历史）;

必须存储各种各样的数据 – 在规范化模式中，数百或数千个表并不少见（更多用于非规范化表，数据仓库等）;

在高端硬件上运行;

有大量资金可用（如果您的企业有数百万客户，那么您可能会发现25,000美元左右躺在沙发后面）。

高端SQL数据库（SQL Server，Oracle，Teradata，Vertica等）专为垂直扩展而设计，他们喜欢在拥有大量内存的机器上，通过SAN和SSD实现快速I / O，以及偶尔进行水平扩展通过聚类（HA）和分区（HC）。

在性能方面，“NoSQL”通常与“SQL”相比是有利的。但完全最大化，高端SQL数据库服务器或集群几乎可以无限扩展。这就是他们打算部署的方式。谨防可疑的基准测试，比较在入门级服务器（或更糟糕的是，像Amazon EC2这样的云服务器）上运行mysql的规范化程度低，索引不良的SQL数据库，以及类似部署的NoSQL数据库。苹果和橘子。如果您使用SQL，请不要被这种炒作吓到。

SQL不会去任何地方。作为NoSQL的结果，DBA不再像PHP程序员那样因Java和XML而消失。

NoSQL也不会去任何地方，因为开发社区已经正确地认识到RDBMS并不总是解决每个问题的最佳解决方案。

所以，作为一名开发人员，你至少应该了解NoSQL是什么，它引用了什么产品（Cassandra，BigTable，Voldemort，db4o等），以及如何构建和编写一个简单的数据库这些。但是，不要开始丢弃所有的SQL数据库，或者认为你的职业生涯将被淘汰 – 这是炒作，而不是现实。