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