MongoDB适合加载随机记录吗？答案

【问题标题】：Is MongoDB suitable for loading random records?MongoDB适合加载随机记录吗？
【发布时间】：2012-06-29 22:02:46
【问题描述】：

我们的应用程序存储具有较短文本（100-1000 个字符的字符串）的记录。它提供对给定查询文本最相似记录的搜索。我们使用 Lucene 来索引文本。完整的记录存储在数据库中。每条记录只属于一个域，现在有 1000 多个域。域名数量不受限制，但增长缓慢。记录不断地添加到所有域中（不统一）。

我们使用 Mysql 作为数据库，每个域都有自己的表。现在由于横向扩展，我们尝试迁移到 MongoDB。所有记录都存储在单个集合中，域是记录的属性。 ID 仍然是从 Lucene 搜索中获得的。但是我们观察到与使用 Mysql 的解决方案相比，从 MongDB 加载记录的性能较差。我怀疑MongoDB的“内存映射存储引擎”是原因。每次搜索都可以返回“随机记录”。通常会从一个域连续进行更多搜索。来自一个域的记录不会存储在集合中的一个位置。这可能会导致许多页面错误。

我的解释对吗？ MongoDB 适合这种记录加载吗？什么可以提高性能？ MongoDB 服务器和应用程序在 Linux 上运行。非常感谢。

【问题讨论】：

唱片长什么样？你是如何导入数据的？您的 Linux 服务器的规格是什么？
一条记录包含文本和一些附加属性（时间戳、created_by、...）。用户不断添加记录——单次插入或批量插入。批量插入实际上是单个插入的序列。记录被插入到 mongoDB 中，带有 id 的文本被插入到 Lucene 索引中。 Linux Ubuntu 10.04 8GB RAM，2 个 CPU 内核（例如 Amazon EC2 大型实例）。
不适合将整个记录存储到Lucene。此外，由于优化，来自一个域的几乎相同文本的记录在索引器中被索引为一个文档。
好的，所以我不确定它是否是手动 mongoimport - 您的应用程序使用什么驱动程序？什么版本的Mongo？ MongoDB 非常适合这种类型的数据，它不应该是一个问题。什么是表现不佳？您正在运行多少个 mongod 实例？我认为您的工作集适合 RAM。请记住，如果您有一个写入繁重的环境，您需要考虑扩展您的写入，这就是您需要查看分片 (docs.mongodb.org/manual/faq/sharding/?highlight=sharding) 的地方，然后关键决定是选择正确的分片键。
谢谢。我们使用 Java 驱动程序 Mongo 2.0.5。索引和工作集应该适合 RAM。但是工作集可以快速更改，因此我担心当数据库大小比 RAM 大小大很多倍时，虚拟内存中可能会出现许多页面错误。我将分片视为减少数据库大小与 RAM 大小比率的解决方案。我们只是粗略的比较，我们会更多地测试速度。

标签： mongodb

【解决方案1】：

因此，您的工作集（数据和索引）必须适合 RAM。有大量关于此的帖子/博客，所以只需谷歌“MongoDB 工作集”，但如您所知，从 RAM 访问而不是分页到磁盘更快。

请记住，如果您有一个写入繁重的环境，您需要考虑扩展您的写入，这就是您需要查看sharding 的地方，然后关键决定是选择正确的分片键。这非常重要，而且它是不可变的，所以要多考虑：）这是一个很好的doc 选择密钥。

另外一点，关于Java驱动，使用version 2.8，有不少变化，包括sharding-related。

最后，您可以免费使用Mongo Monitoring Service 来帮助监控您的实施。它既适合概览，也适合深入研究。

【讨论】：