MongoDB 已经过时了…现在该怎么办？

Question 1

如果您当前的性能太慢或已达到极限，那么您有三个选择。它们适用于任何问题。

垂直缩放：意思是增加你的机器功率。更多的 CPU 或更多的 RAM。
水平缩放：意思是增加工人数量。更多进程，更多线程，更多机器。
更改设计: 用不同的方法。其他软件、其他算法、其他存储系统，其他等等。

由于您已将 1) 和 2) 从选项中排除，因此只剩下解决方案 3)。所以，去吧...

Answer

如果您当前的性能太慢或已达到极限，那么您有三个选择。它们适用于任何问题。

垂直缩放：意思是增加你的机器功率。更多的 CPU 或更多的 RAM。
水平缩放：意思是增加工人数量。更多进程，更多线程，更多机器。
更改设计: 用不同的方法。其他软件、其他算法、其他存储系统，其他等等。

由于您已将 1) 和 2) 从选项中排除，因此只剩下解决方案 3)。所以，去吧...

Question 2

我们在 Mongo 论坛上发布了同样的问题，Mongo CTO 回复说要重新审视他关于如何优化索引的演示

http://www.10gen.com/presentations/mongosf2011/schemascale

在本次演讲中，Horowitz 先生明确指出，在许多情况下，分片/水平扩展可能会有些过度，而设计方法（包括一些特定于 Mongo 的相当非直观的方法）可以使给定的服务器扩展得更大。

这提出了一些有趣的概念，包括使用客户端逻辑来优化数据库以多种“非规范化”方式的使用方式。演示中有一个明显的潜台词，即“如果你只是按部就班地构建，你很容易遇到与扩展相关的不必要的问题。”例如，Horowitz 先生（MongoDB 的制造商 10Gen 的 CTO）提出了一种“混合”设计，其中不是每个“记录”一个文档，而是在一个文档中放置大约 100 条“记录”，从而产生一种“存储桶”类型的方法。这样做是为了减少索引占用空间。这是在客户端上编码的内容，而不是 MongoDB 的“功能”。这种混合方法可能对我们有用，并且可以使我们的索引大小提高 4 倍或 8 倍。

他还讨论了“右平衡” B 树，这基本上是对索引设计的优化，以便大多数查询仅访问索引的“右侧部分”（而不是跨索引的随机访问，后者要获得良好的性能，需要整个索引都适合 RAM）。这种方法对我们没有帮助，因为我们需要查询整个索引。

我们将使用这些概念作为我们系统审查的一部分。

（有趣的是，在我发布这个问题的所有地方中，唯一做出建设性回应的人是 MongoDB 本身的 CTO。）

更新（2017）

最终我们发现 Mongodb 并不适合生产环境。每隔几个月，它就会转储/删除整个数据库，所有数据都会丢失。（它不是主要数据源，因此我们可以忍受这个问题，尽管并不开心。）

我们现在已经完成了一个迁移到 elasticsearch 堆栈的项目，现在正在将其投入生产。（我们已经成功使用 elasticsearch 多年。）Elasticsearch 数据不像 Microsoft SQL Server 那样持久（我们的 elasticsearch 集群出现故障，数据丢失不可恢复），但 elasticsearch 至少比 Mongodb 可靠 10 倍（经验上，超过 100 倍）。（Elasticsearch 很聪明，不假装支持 Windows 作为生产平台，这是 Mongodb 的一大罪过。）

我们预计将在未来几周内清除整个 Mongodb 环境。

向前！

更新（2018-2019）

elasticsearch 堆栈已经交付。我们发现它非常可靠，可扩展性很强，并且完全没有回头。Mongo 当时闻起来很棒，但它已经消失了好几年了，很高兴摆脱它。我们一直在运行两个 elastic 集群，一个用于日志数据（取代了我们的 Mongo 服务器），另一个用于实际应用程序数据。每个集群都有 1-2TB 的数据。它花了很多架构工作（特别是在应用程序方面）在规模和性能上都具有弹性，但交付它却可以。

Answer

我们在 Mongo 论坛上发布了同样的问题，Mongo CTO 回复说要重新审视他关于如何优化索引的演示

http://www.10gen.com/presentations/mongosf2011/schemascale

在本次演讲中，Horowitz 先生明确指出，在许多情况下，分片/水平扩展可能会有些过度，而设计方法（包括一些特定于 Mongo 的相当非直观的方法）可以使给定的服务器扩展得更大。

这提出了一些有趣的概念，包括使用客户端逻辑来优化数据库以多种“非规范化”方式的使用方式。演示中有一个明显的潜台词，即“如果你只是按部就班地构建，你很容易遇到与扩展相关的不必要的问题。”例如，Horowitz 先生（MongoDB 的制造商 10Gen 的 CTO）提出了一种“混合”设计，其中不是每个“记录”一个文档，而是在一个文档中放置大约 100 条“记录”，从而产生一种“存储桶”类型的方法。这样做是为了减少索引占用空间。这是在客户端上编码的内容，而不是 MongoDB 的“功能”。这种混合方法可能对我们有用，并且可以使我们的索引大小提高 4 倍或 8 倍。

他还讨论了“右平衡” B 树，这基本上是对索引设计的优化，以便大多数查询仅访问索引的“右侧部分”（而不是跨索引的随机访问，后者要获得良好的性能，需要整个索引都适合 RAM）。这种方法对我们没有帮助，因为我们需要查询整个索引。

我们将使用这些概念作为我们系统审查的一部分。

（有趣的是，在我发布这个问题的所有地方中，唯一做出建设性回应的人是 MongoDB 本身的 CTO。）

更新（2017）

最终我们发现 Mongodb 并不适合生产环境。每隔几个月，它就会转储/删除整个数据库，所有数据都会丢失。（它不是主要数据源，因此我们可以忍受这个问题，尽管并不开心。）

我们现在已经完成了一个迁移到 elasticsearch 堆栈的项目，现在正在将其投入生产。（我们已经成功使用 elasticsearch 多年。）Elasticsearch 数据不像 Microsoft SQL Server 那样持久（我们的 elasticsearch 集群出现故障，数据丢失不可恢复），但 elasticsearch 至少比 Mongodb 可靠 10 倍（经验上，超过 100 倍）。（Elasticsearch 很聪明，不假装支持 Windows 作为生产平台，这是 Mongodb 的一大罪过。）

我们预计将在未来几周内清除整个 Mongodb 环境。

向前！

更新（2018-2019）

elasticsearch 堆栈已经交付。我们发现它非常可靠，可扩展性很强，并且完全没有回头。Mongo 当时闻起来很棒，但它已经消失了好几年了，很高兴摆脱它。我们一直在运行两个 elastic 集群，一个用于日志数据（取代了我们的 Mongo 服务器），另一个用于实际应用程序数据。每个集群都有 1-2TB 的数据。它花了很多架构工作（特别是在应用程序方面）在规模和性能上都具有弹性，但交付它却可以。

Question 3

您可能不喜欢“扩展”问题的答案，因为您实际上没有扩展问题；您有设计和实施问题。您没有有效地建立索引。

说真的，如果你觉得你绝对必须保留如此大小的索引，那么无论你寻找哪种数据库产品，你都会遇到同样的问题，即在 RAM 中保留巨大的索引。你必须购买一台高容量服务器（DL380 G7 可以做到这一点，而且它是一款中档商品服务器；没什么特别的）来存储这些索引。

为了提供帮助，搜索“mongodb 优化索引”会出现几个有用的链接：

http://www.mongodb.org/display/DOCS/Optimization

http://www.10gen.com/events/indexingmatters

http://www.deanlee.cn/programming/mongodb-optimize-index-avoid-scanandorder/

http://www.slideshare.net/kbanker/mongo-indexoptimizationprimer

您可能会对自己所做的研究采取防御态度，但是我们这些在生产中使用 MongoDB 的人都知道您忽略了很多要点。

此外，评论“底线：MongoDB 是 FOSS，但我们必须花费 $$$$$$$ 购买硬件来运行它？我们宁愿购买商业软件！”充满了无知和傲慢。

Answer