MongoDB-具有多种排列的搜索引擎

我们有一个mongo集合，可以在许多字段上搜索和排序。例如（很抱歉，由于保密原因，我无法放置真实的收藏），让我们看一下：

MathProblem
{
    Creator : String,
    Difficulty : integer (from 0 to 4),
    Categorie : integer (from 0 to 40),
    NbOfQuestion : integer (less than 20),
    Likes : integer,
    Dislikes : integer,
    Succeeded : integer,
    Failures : integer
}

我们可以搜索创建者、难度、分类和问题。按喜欢、不喜欢、成功和失败来排序

例：

• 给我难度3的问题，分类为20，对它们进行排序 当然是喜欢
• 给我5个问题的问题，按失败分类
• 给我难度1的问题，分类10，2个问题，由爱因斯坦创造
• 把所有问题都按顺序给我

等等。。。你可以看到所有的排列都是可能的，我们可以在一个字段上进行选择性排序

这里的问题是，我们有数百万的记录。索引至少花费了我们30亿美元。而且，因为我们有这么多索引，它会大大降低这个集合的写入速度。当它压碎文字时，它锁定了阅读。所以我们有大量的读操作，可能写操作会少一点，但仍然有很多

我搜索“搜索引擎解决方案”，但我只能在“全文搜索”上找到东西，这不是我的情况

我们还尝试将难度、分类和NbOfQuestion合并到一个数组中（通过将值乘以10因子使其保持清晰），以便仅在该数组上进行索引，并节省一些空间

任何事后诸葛亮都将不胜感激

谢谢

查尔斯

查尔斯

你的问题没有简单的解决办法。目前最好的解决方案可能是使用MongoDB的分片功能向外扩展

这里的目标是将您的工作集分割到多台机器上，以减少一次写入会“压碎”的数据量。此外，我建议至少升级到MongoDB v 2.0.7，因为2.X分支中有许多新功能（如长时间操作时的收益率和页面错误时的收益率），这些功能旨在减少写锁对系统的影响。有关MongoDB并发性的更多信息，请参见

干杯

---

David

尽管Solr/Elasticsearch（均由Lucene支持）以全文搜索引擎的形式销售，但它们完全适合您的用例。我在comples searchpages中广泛使用ES（并且已经使用SOLR好几年了），包括刻面、排序等。我确实读了一些关于ElasticSearch的书，但是没有看到性能/内存分析，它将如何处理大量索引。我的单元格中的快速分析：搜索lucene索引性能应该有大量信息是的，切分是一种解决方案，一种原始的解决方案。我不是DBA，所以我想知道我是否从正确的角度看待这个问题。