我们将调试和事务日志转储到MongoDB.
我们真的很喜欢，MongoDB因为：
但是有一个大问题MongoDB：索引必须适合物理 RAM。实际上，这将我们限制为 80-150 GB 的原始数据（我们目前在具有 16 GB RAM 的系统上运行）。
因此，对于我们拥有 500 GB 或 1 TB 的数据，我们需要 50 GB 或 80 GB 的 RAM。
是的，我知道这是可能的。我们可以添加服务器并使用MongoDB sharding. 我们可以购买一个特殊的服务器盒，它可以容纳 100 或 200 GB 的 RAM，但这是摇尾巴的狗！我们可以在硬件上花费 boucoup $$$ 来运行FOSS，当 SQL Server Express 可以在更少的硬件上处理更多的数据时Mongo（SQL Server 不满足我们的架构需求，或者我们会使用它！）我们不会花费巨额$ 在硬件上，因为它是必要的，只是因为Mongo架构，而不是因为固有的处理/存储需求。（还有分片？撇开成本不谈，谁需要三个、五个或更多服务器的持续复杂性来管理相对较小的负载？）
底线：MongoDB是FOSS，但我们必须在硬件上花费 $$$$$$$ 才能运行它？我们宁可购买商业软件！
我确定我们不是第一个遇到这个问题的人，所以我们问社区：
我们下一步要去哪里？
（我们已经运行了 Mongo v2）
mai*_*ilq 16
如果您处于当前性能太慢或达到限制的点，那么您有三个选择。对于任何问题，它们都是正确的。
当您从选项中排除 1) 和 2) 时，只剩下解决方案 3) 了。所以去吧...
Jon*_*ica 12
我们在 Mongo 论坛上发了同样的问题，Mongo CTO 回复了，说要回顾他关于如何优化索引的演讲
http://www.10gen.com/presentations/mongosf2011/schemascale
在本次演讲中，Horowitz 先生明确指出，分片/水平扩展在许多情况下可能是过度的，并且设计方法（包括一些特定于 Mongo 的相当非直观的方法）可以使给定的服务器扩展得更远。
这提出了一些有趣的概念，包括使用客户端逻辑来优化以多种“非规范化”方式使用数据库的方式。演示中有一个明确的潜台词，即“如果您只是按照书本进行构建，您很容易遇到与缩放相关的不必要的问题。” 例如，Horowitz 先生（10Gen 的 CTO，MongoDB 的制造商）提出了一种“混合”设计，其中每个“记录”不是一个文档，而是在一个文档中放入 100 个“记录”，从而产生“桶”类型的方法。这样做是为了减少索引占用空间。这是在客户端编码的东西，而不是 MongoDB 的“功能”。这种混合方法可能对我们有用，并且可以使我们的索引大小提高 4 倍或 8 倍。
他还讨论了“右平衡”btrees，它基本上优化了索引设计，以便大多数查询仅访问索引的“右手部分”（而不是跨索引的随机访问，为了表现良好，需要整个索引适合 RAM）。这种方法对我们没有帮助，因为我们需要查询整个索引。
我们将使用这些概念作为我们系统审查的一部分。
（有趣的是，在我发布这个问题的所有地方中，唯一给出建设性回应的人是 MongoDB 本身的 CTO。）
更新 (2017)
我们发现 Mongodb 最终不适合在生产环境中使用。每隔几个月，它就会转储/清理整个数据库，并且所有数据都将丢失。（它不是主要数据源，所以我们可以忍受这个问题，尽管不是很开心。）
我们现在已经完成了一个转移到 elasticsearch 堆栈的项目，并且现在正在将其推向生产。（我们已经成功使用elasticsearch 多年。）Elasticsearch 数据并不像 Microsoft SQL Server 那样持久（我们有 Elasticsearch 集群因不可恢复的数据丢失而失败），但 elasticsearch 至少是 10 倍（从经验上来说，超过 100 倍） ) 比 Mongodb 更可靠。（Elasticsearch 聪明地不假装支持 Windows 作为生产平台，这是 Mongodb 的一大罪过。）
我们希望在接下来的几周内清除我们对 Mongodb 的整个环境。
向前！
更新（2018-2019）
elasticsearch 堆栈已经交付。我们发现它非常可靠，非常具有可扩展性，并且根本没有回头。Mongo 当时闻起来很香，但现在它已经消失多年了，很好地摆脱了它。我们一直在运行两个弹性集群，一个用于日志数据（取代了我们的 Mongo 服务器），另一个用于实际应用程序数据。每个集群有 1-2TB 的数据。需要大量的架构工作（特别是在应用程序方面）才能在扩展和执行方面获得弹性，但交付确实如此。
| 归档时间： |
|
| 查看次数： |
7634 次 |
| 最近记录： |