对 NoSQL/MongoDB 的担忧

Question

我开始构建一个新的基于 Spring 的多用户文档管理应用程序，我想冒险进入 NoSQL/MongoDB 的世界。来自 RDBMS 背景，我对 MongoDB 有几个担忧，主要是：

1. 缺少交易
2. 更注重性能/可扩展性而不是数据完整性
3. 缺乏 JPA 标准

首先，我不期望高负载或大量读取与写入。我怀疑读取到写入的比率约为 10 比 1。此外，我预计负载不会很高 - 尤其是开始时。

1) 据我所知，没有简单的方法来进行多收款交易。在 RDBMS 中，我可以轻松地在单独的表中维护每个用户的文档 ID 计数器，但考虑到它将位于单独的集合/文档中，似乎没有办法在 MongoDB 中可靠地执行此操作。因此，我不确定是否/如何解决这个问题。

2) 此外，根据我的阅读，NoSQL 在数据完整性不是主要问题的情况下非常有用（例如：博客 cmets 等）。但是，我不确定这如何转化为应用程序的主要数据存储。这是否意味着可以更新文档并使其失败？我遇到了一个older unaccredited rant，它讨论了失败的提交/等，这进一步激起了人们的担忧。

3) NoSQL 似乎缺乏类似 JPA 的标准，这意味着我必须选择我的数据库并坚持使用它。与 JPA 不同，我可以轻松地将一个数据库供应商换成另一个符合 JPQ/SQL 的供应商，如果我想切换到另一个 NoSQL 数据库，我必须考虑使用 MongoDB 进行编码并重新设计我的结构/查询。我见过 Hibernate OGM，但它似乎仍处于起步阶段，仅提供基本支持。绝对不是可以避免 mongodb 特定查询的东西。

这些问题容易缓解吗？作为 NoSQL 世界的新手，我仍然无法理解何时使用 NoSQL 的正确业务案例。

Answer 1

这些都是好问题。这是我关于 MongoDB 的 2 美分和一些帮助您了解更多信息的参考资料。我不会谈论任何其他 NoSQL 东西，因为那里有很多东西，除了“它不使用 SQL”之外，NoSQL 没有真正的统一原则，除了有时人们让它与 SQL 一起工作，所以，是的。

1. MongoDB 不进行连接。时期。 MongoDB 没有事务——无论是在一个集合内还是涉及多个集合。原子性的单位是文档。这在应用程序中如何工作？通过schema design和一些必要时恢复部分ACID语义的技术，例如使用two-phase commits。在关系数据库中，模式设计很简单，并且基于数据的结构而不是其用例。连接和事务填补了抽象的规范化数据表示与数据使用的具体方式之间的空白。作为对比，已经链接的数据建模介绍解释了 MongoDB 的情况：

   数据建模的关键挑战是平衡应用程序的需求、数据库引擎的性能特征和数据检索模式。在设计数据模型时，请始终考虑数据的应用程序使用情况（即数据的查询、更新和处理）以及数据本身的固有结构。

2. 那个特定的“咆哮”显然已经很老了，因为它谈到默认情况下不确认写入。 This isn't the case anymore。给定在网络上运行的任何分布式计算机系统，很容易想出一种使其表现不佳的方法。 MongoDB 博客在 series on consistency 中介绍了很多此类内容。我建议您浏览有关日志、复制和写入问题的文档，看看这是否会让您对 MongoDB 作为主要数据存储感觉更好。

3. 是的。这伴随着 NoSQL 领域。不存在的是通用的数据访问语言或标准，因为一切都是新的并且试图与众不同。 30 年后再来看看。