Buz*_*zut 26 mongodb storage-engine mongodb-3.0
在 mongoDB3 中出现了一个新的存储引擎:WiredTiger。然而,MMAPv1仍然是 Mongo 的默认选择。
一个可能并不比另一个更好,这通常是用例和为工作选择正确工具的问题。但是哪种发动机适合什么工作?
事实上,虽然 MMAPv1 是默认引擎,但WiredTiger 似乎在几乎所有领域都更好。它具有与 MMAPv1 相同的功能以及:
我在MongoDB 的博客上找到了一个比较表:
所以除非你在 Solaris 上,否则有理由不选择 WiredTiger 吗?
编辑
这里有两个视频详细解释了WiredTiger和MMAPv1的内部 结构。
Mar*_*erg 26
就我个人而言,出于三个原因,我现在更喜欢 mmapv1 存储引擎。
并不是说 WiredTiger 不成熟。但是 mmapv1 很容易理解,并且经过了上下、前后和上下的战斗测试。WiredTiger 最近遇到了一些严重的问题(有关详细信息,请参见http://jira.mongodb.com),我不愿意让我的客户很难找到下一个问题。
鉴于,WT 有一些非常棒的功能。问题是:我没有看到任何人从中受益。压缩?无论哪种方式,您都很难为获得相当便宜的磁盘空间而牺牲性能。缺少扩展文档的文档迁移问题?嗯,我们仍然有 16MB 的大小限制,并增加了嵌入文档的复杂性,尤其是当嵌入过度时。
还有其他功能,但总的来说:到目前为止,我认为它们没有太大好处。
对于新项目,WT 可能没问题,尤其是从 3.2 开始,因为以下不适用。
进行数据迁移很昂贵. 需要计划,需要所有利益相关者就该计划达成一致,必须制定和商定紧急应变计划,需要准备、执行和审查迁移。现在,参与此过程的利益相关者所需的时间成倍增加,并且数据迁移的成本飞涨。另一方面,投资回报似乎相当小。如果将这些因素考虑在内,您可以进行相当多的扩展而不是进行迁移。给您一个印象:如果迁移计划、执行和审查正确,我估计每个利益相关者大约需要一个“人周”。以每人每小时 100 美元的成本计算,只有三个人参与(经理、DBA 和开发人员),这相当于 12.000 美元。请注意,这是一个保守的估计。
以上所有这些因素使我得出结论,无论如何都不要使用 WT。在这一刻。
这篇文章已经有几个月了,所以它值得更新
我对成熟度的原始评论有点过时了。WiredTiger 已经有一段时间没有出现任何重大问题,并且已成为 MongoDB 3.2 的默认存储引擎
我的原始评论仍然具有一定的有效性,恕我直言。
然而,当预算紧张,或者更一般地说,性能不是主要问题时,性能权衡相当小,并且您基本上会用轻微的性能影响(与未压缩的 WT 相比)来换取磁盘空间,利用否则会空闲周围:CPU。
MongoDB 3.2 Enterprise 引入了对 WiredTiger 存储进行加密的功能。对于具有增强安全需求的数据,这是一个杀手级功能,使 WT 成为唯一选择的存储引擎,无论是技术上(MMAPv1 不支持加密)还是概念上。撇开加密磁盘分区的可能性,当然,尽管在某些环境中您可能没有该选项。
我不得不承认,我在上面的分析中基本上忽略了WT的那个功能,主要是因为它在我写原始答案时不适用于我或我的客户。
根据您的设置,主要是当您有许多并发写入客户端时,此功能可能会提供很大的性能提升。
进行迁移仍然很昂贵。但是,考虑到成熟度的变化和对功能的看法的变化,在以下情况下进行迁移可能是值得的:
对于新项目,我现在使用 WiredTiger。由于从压缩到未压缩的 WiredTiger 存储的迁移相当容易,我倾向于从压缩开始以提高 CPU 利用率(“物有所值”)。如果压缩对性能或用户体验有明显影响,我会迁移到未压缩的 WiredTiger。
对于有很多并发作者的项目,迁移与否的答案也几乎总是“是”——除非项目的预算禁止投资。从长远来看,如果部署是合理规划的,那么性能提升应该是物有所值的。但是,您需要在计算中增加一些开发时间,因为在某些情况下需要更新驱动程序,并且可能存在需要处理的问题。
对于预算紧张且暂时无法承受更多磁盘空间的项目,迁移到压缩的 WiredTiger 可能是一种选择,但压缩会给 CPU 带来一些负载,这在 MMAPv1 中是闻所未闻的。此外,对于这样的项目,迁移成本可能高得令人望而却步。
小智 5
我的两分钱:
WiredTiger中的日志可能会在硬关机时丢失更新,因为它使用内存缓冲来存储日志记录。
在写入操作之间,虽然日志记录保留在 WiredTiger 缓冲区中,但在 mongod 硬关闭后更新可能会丢失。
如果 mongod 实例在没有将写入应用于数据文件的情况下崩溃,则日志可以重播对共享视图的写入,以最终写入数据文件。