在 MongoDb Documentation 3.2 中，我看到它们支持 3 个存储引擎， MMAPV1、WiredTiger、In-Memory，选哪一个很纠结。

我从描述中感觉到 WiredTiger 比 MMAPV1 更好，但在其他来源中，他们说 MMAPV1 更适合重读……而 WiredTiger 适合大量写入...

在选择其中一个时是否有一些限制？ 有人可以建议一些最佳做法，例如

当我有这种类型的应用程序时，通常最好这个，否则选择其他...

最佳答案

这是来自个人经验，但是请查看此博客条目，它很好地解释了不同类型的引擎: Mongo Blog v3

Comparing the MongoDB WiredTiger and MMAPv1 storage engines.Higher Performance & Efficiency Between 7x and 10x Greater Write Performance MongoDB 3.0 provides more granular document-level concurrency control, delivering between 7x and 10x greater throughput for most write-intensive applications, while maintaining predictable low latency.

对我来说选择非常简单，我需要文档级别的锁，这使得 WiredTiger 成为理想的选择，我们没有企业版的 mongo，因此内存引擎不可用。 MMAPv1 Btree 是将内存映射到硬盘的非常基本的技术，效率不高。

The MMAP storage engine uses a process called “record allocation” to grab disk space for document storage. All records are contiguously located on disk, and when a document becomes larger than the allocated record, it must allocate a new record. New allocations require moving a document and updating all indexes that refer to the document, which takes more time than in-place updates and leads to storage fragmentation. Furthermore, MMAPv1 in it’s current iterations usually leads to high space utilization on your filesystem due to over-allocation of record space and it’s lack of support for compression. As mentioned previously, a storage engine’s locking scheme is one of the most important factors in overall database performance. MMAPv1 has collection-level locking – meaning only one insert, update or delete operation can use a collection at a time. This type of locking scheme creates a very common scenario in concurrent workloads, where update/delete/insert operations are always waiting for the operation(s) in front of them to complete. Furthermore, oftentimes those operations are flowing in more quickly than they can be completed in serial fashion by the storage engine. To put it in context, imagine a giant supermarket on Sunday afternoon that only has one checkout line open: plenty of customers, but low throughput!

每个人都有不同的要求，但在大多数情况下，WiredTiger 将是理想的选择，因为它使文档级别而非集合级别的原子操作具有很大优势，您根本无法超越。

更多的读取而不是很多的写入

如果阅读是您主要关心的问题，这里是解决这个问题的一种方法。

您可以调整 Mongo 驱动程序 Read Preference Modes通过以下方式:

1. 设置副本集，例如 1 个主节点和 3 个从节点。
2. 将写入关注设置为 majority这将使 写得慢一点(权衡)。
3. 将阅读偏好设置为次要。

当您有大量读取时，此设置将执行得非常好，但作为权衡写入会更慢。但是读取数据的吞吐量会很大。

如果您有其他问题，请将它们添加为评论，我希望这会有所帮助，我将尝试在此答案中解决。

您也可以查看MMAPv1 vs WiredTiger查看并注意他是如何从 MMAPv1 更改为 WiredTiger 的。卖方正在记录您无法超越的性能。

For new projects, I use WiredTiger now. Since a migration from a compressed to an uncompressed WiredTiger storage is rather easy, I tend to start with compression to enhance the CPU utilization ("get more bang for the buck"). Should the compression have a noticeable impact on performance or UX, I migrate to uncompressed WiredTiger.

MongoDB 数据库分析器

确定您的数据库需求的最佳方法是设置测试集群并在其上运行应用程序 MongoDB profiler 与大多数数据库分析器一样，MongoDB 分析器可以配置为仅写入有关花费超过给定阈值的查询的配置文件信息。因此，一旦您知道慢查询，您就可以确定它是读取还是写入还是 cpu vs ram，然后从那里开始。

关于mongodb - MongoDB 的 MMAPV1、WiredTiger 或 In-Memory StorageEngine 如何选择？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37985134/