问题标签 [wiredtiger]

我目前正在使用 Vert.x 对我的应用程序执行一些基准测试，并且我正在尝试比较使用 mongo java 同步或异步驱动程序时的结果。

令我惊讶的是，使用同步驱动程序的结果似乎要好得多，因为与异步驱动程序相比，它使用的 mongodb 连接非常少。结果，mongo 请求速度较慢，并且 mongo 总是通过与异步驱动程序崩溃来完成。

与同步驱动程序相比，异步驱动程序打开这么多连接是否正常？如果是，我们是否需要安装 mongo 作为副本集以更好地使用异步驱动程序进行扩展？

例如，这里是 wrk 的测试结果，在 30 秒内有 200 个连接，有 16 个线程。

使用同步驱动程序：

使用异步驱动程序（mongodb 崩溃）：

• MongoDB 3.2.7 有线虎
• Mongo Java 驱动程序 3.2.2
• 顶点 3.3.1
• Mac OS X El Capitan 2.5 Ghz I7 16 Go RAM

更新 1：我通过配置文件和进程限制解决了本地机器上的 mongodb 崩溃问题：https ://unix.stackexchange.com/questions/108174/how-to-persist-ulimit-settings-in-osx-mavericks 但是，我仍然有许多与异步驱动程序打开的连接，这会减慢我的应用程序。

更新2：这是异步驱动程序的一些代码。垂直：http://pastebin.com/SygKuDhg

配置：

更新 3：这是同步驱动程序的代码

http://pastebin.com/FJ7JeSPU

我使用 Jongo 作为 java 同步驱动程序的包装器，并使用 vertx-hk2 将依赖项注入到我的 REST verticle 中。

为什么 Mongo 3.2.6. 调用 db.serverStatus().storageEngine 时不显示存储引擎？

询问的原因是为了获得有关wiredTiger 的更多统计信息。

正如MMAPv1 文档所说

所有记录都连续位于磁盘上，当文档大于分配的记录时，MongoDB 必须分配一条新记录。新分配要求 MongoDB 移动文档并更新引用该文档的所有索引，这比就地更新花费更多时间并导致存储碎片。在 3.0.0 版中更改。
默认情况下，MongoDB 使用 2 大小分配的幂，因此 MongoDB 中的每个文档都存储在包含文档本身和额外空间或填充的记录中。填充允许文档随着更新而增长，同时最大限度地减少重新分配的可能性。

但WiredTiger 文档对此只字未提。所以我只想知道当记录大小发生变化时是否很好，或者它有一些性能问题但在文档中没有提到。

/var/lib/mongodb/ 中有很多 WiredTigerStat.XX.XX 文件。我可以删除它们吗？

假设一个文档（级别 1）应该具有N(k)不同类型的项目作为子文档数组（级别 2），并且由于缺乏对深度嵌套数组子文档的查询优化，这些项目存储在单独的集合中。现在，我们应该获取N(d1)1 级文档，每个文档都有N(d2)多个子文档（一个 1 级文档的 2 级文档总数为N(d2)）

将所有这些项目类型放在一个集合中与每种类型的集合有什么优缺点。考虑到以下几点：

• 使用的存储引擎是WT
  • DB 可以在其他文档被写入同一个集合时读取。在这里。
  • 读写锁是文档级别的，而不是之前的情况下的集合级别。在这里。
• 允许使用稀疏索引，因为字段可能因类型而异
• 部署类型为分片集群
• 所有可查询的字段都被索引（虽然不是盲目的）=>$or操作员可以使用索引
• 支持一种方法的观点自动意味着它会导致其他方法的性能下降。

在多态集合的情况下查询将如何工作：

• 所有不同的类型都可以在单个查询（使用$or）操作中获取，然后附加到服务器应用程序中的父文档。我们还可以使用聚合$group将一种类型的文档组合在一起。因此，
  • 减少网络引起的查询延迟。
  • 减少来自服务器的连接数。
• 由于子文档被附加回其父文档，因此它需要在服务器端进行 for 循环。N(d1)至少必须循环遍历文档 - 如果$group在查询级别使用聚合 - 或者 N(d1) * N(d2)如果子文档尚未分组的话。

如果每种类型都有自己的集合，查询将如何工作：

• N(k)进行查询后，只要查询返回，我们就可以将子文档附加到其父文档。
• 我们可以再次使用聚合$group，从而将服务器端循环限制为N(d1)迭代

支持单一集合：

• 使用的连接数更少。（一致为每个查询 1 个）
• 一致的延迟。（作为前面一点的暗示）
• ?

支持多个：

• 我们更习惯的组织结构。（主观）
• ?

每个案例如何影响性能？

背景：设置了 1 个成员和 1 个仲裁器的 MongoDB ReplicaSet。释放磁盘空间是必要的，因为不再需要 MongoDB 中的数据。所有文件都被db.collection.remove({})命令删除。之后db.runCommand ( { compact: 'collection', force:true} )，db.collection.reIndex()并db.repairDatabase()运行，db.stats()看起来像：

如您所见，DB 中只有 6 个文档（在第二个集合中），总存储大小为 153MB。但是，如果我们查看磁盘空间使用情况：

在 mongodb 目录中：

这个字符串对我来说似乎很奇怪：

问题：神秘 collection-4-2472884588219438804.wt 文件中有什么？为什么它不受紧凑、repairDatabase 命令的影响？有没有办法强制 MongoDB 清空这个文件或以某种方式回收它的空间？

更新：在@james-wahlin 的帮助下，我们发现 9.8Gb 是 Replica Set Oplog 的大小。但是，尽管其他副本集成员可能会丢失数据，但我如何才能强制 MongoDB 释放空间？

如果您使用的是 MMAPv1 存储引擎，则如果文档大小增加，更新可能会导致文档在磁盘上移动。但是，在使用 WiredTiger 存储引擎时，增大或缩小文档是否仍会导致性能问题？如果是这样，推荐的处理方法是什么？

触发此问题的集合包含大小可能在x kB和3x kB之间变化的文档。

我知道mongo在版本3中已经将默认存储引擎改为WiredTiger，而2.6版本有MMap。您可以使用它来更改默认存储引擎

有关于如何升级到 3 并使用 WiredTiger 的说明，但我想知道是否可以保留 2.6 版并使用 WiredTiger？2.6 版是否有等效命令？

注意：我目前无法升级，因为我在需要 2.6 版的共享服务器上

我们正在将 MongoDB 2.6 数据库迁移到 MongoDB 3.2.10 + WiredTiger。迁移后，我们观察到读/写响应时间下降，而不是提高性能。

唯一的好处是数据库大小减少了近 40%。

我们现在在两个不同的独立服务器上运行 2.6 和 3.2.10 + WiredTiger。

WiredTiger 的所有测试报告均为阴性。

我现在没有找到任何迁移到 3.2.10 + WiredTiger 的充分理由。

3.2.10 + WiredTiger 有调优参数吗？

WiredTiger 对于生产环境是否足够成熟？

我最近阅读了一篇博客文章，其中提到了他们在使用 Mongo 3.0 和 3.2.9 WiredTiger 时遇到的问题。

编辑：这个问题不是关于香草 MongoDB 的show collections，而是关于mongo-hacker. 请参阅已接受的答案和评论。

使用 Mongo DB 3.2 + WiredTiger，show collections显示两种尺寸：s1 / s2。

我的猜测是：

• s1：数据库中文档的总大小
• s2：压缩后磁盘上数据库的大小（文档+索引）

这个对吗？我在文档中找不到任何参考。