MongoDB 最常见的 10 个错误说法( 二 ) _MongoDB

3
迷思 1：MongoDB 的版本是 3.2
如果你在 Debian Stretch 上使用apt get mongodb安装 MongoDB，它会安装 3.2 版本。不幸的是，这个版本已经是 5 年前的了！从那时起，已经发布了 5 个主要版本，它们包含大量的新特性，以及安全性、性能和可伸缩性方面的改进。
MongoDB 的当前版本是 4.4（截至 2020 年末）。如果你要安装，应该安装MongoDB社区服务器版，但最好请先了解一下MongoDB Atlas，也就是我们的托管数据库即服务（DBaaS）产品！
4
迷思 2：MongoDB 是一个 JSON 数据库
你肯定听说过 MongoDB 是一个 JSON 数据库的说法，特别是如果你最近访问过 MongoDB 的主页。

文章插图
不过，正如前面提到的，MongoDB 不是一个 JSON 数据库。它支持额外的数据类型，比如对象、原生日期对象、更多的数字类型、地理原语和高效的二进制类型等等。
MongoDB 实际上是一个 BSON 数据库。
这似乎是一个微不足道的区别，但却很重要。与基于文本的格式相比，它在存储、传输和遍历方面更高效，而且比 JSON 支持更多的数据类型。
MongoDB 存储的是 BSON 文档
用于查找的实际上也是 BSON 文档
结果以 BSON 文档的形式输出
BSON 甚至是 MongoDB 的有线协议
如果你习惯了使用 JSON，可以将 MongoDB 看成是 JSON 数据库，这就是为什么我们有时会这样描述它！等你使用 MongoDB 一段时间，就会开始对 BSON 的优势大加赞许。
4
迷思 3：MongoDB 不支持事务
一些第三方文章将 MongoDB 描述成 BASE 数据库。BASE 是指“基本可用、软状态、最终一致” 。
但这不是真的，从来都不是！MongoDB 从来都不是“最终一致”的。对主文档的读写是强一致性的，对单个文档的更新始终是原子的。软状态是指需要持续不断的更新数据，否则数据就会过期，但 MongoDB 并非如此。
最后，如果太多的节点不可用，无法达成仲裁，MongoDB 将进入只读状态（降低可用性）。这是有意这么设计的，因为这样可以确保在出现问题时保持一致性。
MongoDB 是一个 ACID 数据库。它支持原子性、一致性、隔离性和持久性。
对单个文档的更新始终是原子的，从 4.0 版本开始，MongoDB 也支持跨多个文档和集合的事务。从 4.2 开始，甚至支持分片集群的跨分片事务。
虽然 MongoDB 支持事务，但在使用它时仍然要谨慎。事务是以性能为代价的，而且由于 MongoDB 支持丰富的分层文档，如果你的模式设计正确，就没有必要经常跨多个文档更新数据。
5
迷思 4：MongoDB 不支持关系
关于 MongoDB 另一个过时的说法是，你不能在集合或文档之间建立关系。你可以使用聚合管道来连接文档，它们非常强大，你可以使用直观的查询模型来查询和转换来自多个集合的数据。
MongoDB 从 2.2 开始就支持查找（连接）。
下面的示例文档演示了将订单集合和库存集合连接之后，在返回的订单文档中包含了嵌入到数组的库存文档。

文章插图
我认为，能够在返回的主文档中嵌入相关文档比在关系连接中为每个关系复制行更直观。
6
迷思 5：MongoDB 完全是关于分片
你可能听人说过分片是 MongoDB 的一个很酷的特性。这绝对是 MongoDB 的一个很酷的核心特性。
分片是指将数据分成片段，并将每个片段放到不同的复制集或集群中。这是一种处理庞大数据集的技术。MongoDB 可以自动将数据和请求发送到正确的副本集，并将来自多个分片的结果合并起来。
但分片存在一个很根本的问题。
我在前面提到过，副本集的最小节点数是 3，这样才能实现仲裁。在进行分片时，至少需要两个副本集，因此至少需要 6 台服务器。除此之外，你还需要运行多个 mongos 实例。mongos 是分片集群的代理，负责路由请求和响应。要实现高可用性，至少需要两个 mongos 实例。

文章插图
因此，这意味着一个分片集群最少需要 8 台服务器，每增加一个分片，就会增加至少 3 台服务器。
分片集群还会使数据变得难以管理，并且会限制可执行的查询类型。如果你确实需要进行分片，那么分片对你来说确实是有用的，但更简单的办法是直接升级硬件，通常这样更便宜、更容易。
数据的伸缩主要与 RAM 有关，所以如果可以的话，请购买更多的 RAM 。如果 CPU 是瓶颈，那就升级 CPU 。如果磁盘容量是个问题，那就买一个更大的磁盘。