我开始构建一个新的基于Spring的多用户文档管理应用程序，我想冒险进入NoSQL / MongoDB世界。来自RDBMS背景，我对MongoDB有几个问题，主要是：
首先，我不期望高负载或大量读取与写入。我怀疑对写入的读取大约是10比1.此外，我不期望非常高的负载 - 特别是开始。
1）据我所知，没有简单的方法来进行多次收集交易。在RDBMS中，我可以轻松地在单独的表中维护每用户文档ID计数器，但似乎没有办法在MongoDB中可靠地执行此操作，因为它将位于单独的集合/文档中。因此，我不确定是否/如何解决此问题。
2）此外，根据我的阅读，NoSQL很棒，数据完整性不是主要关注点（例如：博客评论等）。但是，我不确定这如何转换为应用程序的主数据存储。这是否意味着可以更新文档并使其失败？我遇到了一个older unaccredited rant讨论了失败的提交/等等，这进一步激起了人们的担忧。
3）看似缺乏类似JPA的NoSQL标准意味着我必须选择我的数据库并坚持使用它。与JPA不同，我可以轻松地将一个数据库供应商换成另一个符合JPQ / SQL标准的供应商，我必须考虑MongoDB的代码并重新设计我的结构/查询，如果我想切换到另一个NoSQL DB。我已经看过Hibernate OGM，但它似乎仍处于起步阶段，只能提供基本的支持。绝对不会避免mongodb特定的查询。这些问题是否可以轻松减轻？作为NoSQL世界的新手，我在使用NoSQL时仍然无法理解正确的商业案例。
答案 0 :(得分：0)
这些都是好问题。这是关于MongoDB的2美分，以及一些可以帮助您了解更多内容的参考资料。我不会谈论任何其他的NoSQL问题因为那里有很多东西，NoSQL除了＆＃34之外没有真正的统一原则;它没有使用SQL＆＃34;，除了有时人们会使用SQL，所以，是的。
MongoDB不进行连接。期。 MongoDB没有事务 - 无论是在一个集合中还是涉及多个集合。原子的单位是文件。这在应用程序中如何工作？通过schema design以及一些必要时恢复部分ACID语义的技术，例如使用two-phase commits。在关系数据库中，模式设计很简单，并且基于数据的结构而不是其用例。连接和事务填补了抽象的规范化数据表示与数据使用的具体方式之间的差距。已经链接的数据建模介绍解释了MongoDB的情况，相反：
数据建模的关键挑战是平衡应用程序的需求，数据库引擎的性能特征和数据检索模式。在设计数据模型时，请始终考虑数据的应用程序使用情况（即查询，更新和处理数据）以及数据本身的固有结构。
特定的＆＃34; rant＆＃34;显然很老，因为它谈到默认情况下未确认写入。 This isn't the case anymore。鉴于任何分布式计算机系统在网络上运行，很容易想出一种表现不佳的方法。 MongoDB博客在series on consistency中涵盖了很多这样的内容。我建议浏览有关日记，复制和写入问题的文档，看看这是否让您对MongoDB作为主要数据存储感觉更好。
烨。这附带NoSQL领域。不存在的是常见的数据访问语言或标准，因为一切都是新的并且试图变得不同。回顾30年。