在Mongodb上使用地理空间索引的全文搜索

Question

假设我想开发一个Android应用程序，允许用户搜索距离您最近的酒店。 这在当今的应用程序中非常常见，例如AirBnb。

这是我正在使用的数据集：

{
    "name" : "The Most Amazing Hotel",
    "city" : "India",
    "type": "Point"
    "coord": [
        -56.16082,
        61.15392
      ]
}

{
    "name" : "The Most Incredible Hotel",
    "city" : "India",
    "type": "Point"
    "coord": [
        -56.56285,
        61.34590
      ]
}

{
    "name" : "The Fantastic GuestHouse",
    "city" : "India",
    "type": "Point"
    "coord": [
        -56.47085,
        61.11357
      ]
}

现在，我想在name字段上创建一个文本索引 ，以便按名称搜索，然后根据坐标按地理空间索引排序。

因此，如果我搜索“The Most”这个词，它将按名称搜索“The Most”并返回最近的酒店，其中包含“The Most in them”。

mongodb甚至支持这种类型的搜索吗？

我在这里阅读mongodb的指南： https ： //docs.mongodb.org/manual/core/index-text/

复合文本索引不能包含任何其他特殊索引类型，例如多键或地理空间索引字段。

据我了解，我不是在创建复合文本索引。 这是一个简单的文本索引，这意味着我只索引name字段的文本，而不是city和name字段。

Answer 1

有一个公平的案例，你真的根本不需要这个，因为很难证明这种操作的用例是合理的，我认为“搜索酒店”不是“文本搜索”的组合。 “和”geoSpatial“搜索确实适用。

实际上， “大多数人”会寻找靠近某个位置的东西，或者甚至更可能接近他们想要访问的各个位置 ，作为其主要标准的一部分，然后其他“获胜者”可能会更加加权到“成本” “，”评级“，”品牌“，”设施“，甚至可能靠近餐馆等 。

将“文本搜索”添加到该列表是一个非常不同的事情 ，在这个特定的应用程序中可能没有太多实际用途。

尽管如此，这可能值得一些解释，并且这里有一些概念可以理解为什么这两个概念至少对这个用例没有真正“网格化” 。

修复架构

首先，我想建议稍微“调整”您的数据模式：

{
    "name" : "The Most Amazing Hotel",
    "city" : "India",
    "location": {
        "type": "Point",
        "coordinates": [
               72.867804,
               19.076033
        ]
    }
}

这至少将"location"作为有效的GeoJSON对象进行索引，并且您通常需要GeoJSON而不是传统的坐标对，因为它确实为查询和存储开辟了更多选项，而且距离标准化为米而不是全球范围内等同的“弧度”。

为什么他们不一起工作

因此，您的阅读基本上是正确的，因为您不能同时使用多个特殊索引。 首先看一下复合索引定义：

db.hotels.createIndex({ "name": "text", "location": "2dsphere" })

{“ok”：0，“errmsg”：“错误的索引键模式{name：\\”text \\“，location：\\”2dsphere \\“}：不能为单个索引使用多个索引插件。”， “代码”：67}

所以这是无法做到的。 即使单独考虑：

db.hotels.createIndex({ "name": "text" })
db.hotels.createIndex({ "location": "2dsphere" })

然后尝试进行查询：

db.hotels.find({
    "location": {
        "$nearSphere": {
            "$geometry": {
                "type": "Point",
                "coordinates": [
                   72.867804,
                   19.076033
                ]
            }
        }
    },
    "$text": { "$search": "Amazing" }
})

错误：命令失败：{“waitedMS”：NumberLong（0），“ok”：0，“errmsg”：“text和geoNear在同一查询中不允许”，“code”：2}：undefined

这实际上支持了以下三种方式无法在复合索引中定义的原因：

1. 正如初始错误所示，MongoDB中处理这些“特殊”索引的方式实际上需要“分支”到所选索引类型的“特殊”处理程序，并且两个处理程序不在同一个位置。

2. 即使使用单独的索引，由于逻辑基本上是一个“和”条件，MongoDB无论如何都不能实际选择多个索引，并且由于两个查询子句都需要“特殊”处理，因此实际上需要这样做。 它不能。

3. 即使这在逻辑上是$or条件，你基本上回到第1点，即使应用“索引交集”，还有这种“特殊”索引的另一个属性，它们必须应用于查询操作的“顶层”为了允许索引选择。 将它们包装在$or意味着MongoDB不能这样做，因此不允许这样做。

但你可以“作弊”

所以每个基本上都必须是独家的，你不能一起使用它们。 但是当然你可以随时“欺骗”，这取决于哪种搜索顺序对你更重要。

首先是“位置”：

db.hotels.aggregate([
    { "$geoNear": {
        "near": {
            "type": "Point",
            "coordinates": [
               72.867804,
               19.076033
            ]
        },
        "spherical": true,
        "maxDistance": 5000,
        "distanceField": "distance",
        "query": {
           "name": /Amazing/
        }
    }}
])

甚至：

db.hotels.find({
    "location": {
        "$nearSphere": {
            "$geometry": {
                "type": "Point",
                "coordinates": [
                   72.867804,
                   19.076033
                ]
            },
            "$maxDistance": 5000
        }
    },
    "name": /Amazing/
})

或者先通过文字搜索：

db.hotels.find({
    "$text": { "$search": "Amazing" },
    "location": {
        "$geoWithin": {
            "$centerSphere": [[
               72.867804,
               19.076033
            ], 5000 ]
        }
    }
})

现在，您可以使用.explain()仔细查看每个方法中的选择选项以查看发生的情况，但基本情况是每个选项只选择一个要分别使用的特殊索引。

在第一种情况下，它将是用于主要集合的集合上的geoSpatial索引，并将根据它们与首先给定的位置的接近度找到结果，然后通过为name字段给出的正则表达式参数进行过滤。

在第二种情况下，它将使用“文本”索引进行主要选择（因此首先找到“惊人”的东西）并从这些结果应用geoSpatial过滤器（不使用索引）与$geoWithin ，在这种情况下执行通过在所提供的距离内的一个点周围的圆内搜索来过滤结果，这基本上相当于$near作用。

不是“所有”查询都是相等的

但要考虑的关键是每种方法都有可能返回不同的结果。 通过首先缩小位置，可以检查的唯一数据是指定距离内的那些位置，因此除了距离之外的任何“惊人”都不会被附加过滤器考虑。

在第二种情况下，由于文本术语是主要搜索，因此将考虑“惊人”的所有结果，并且辅助过滤器可以返回的唯一项目是允许从初始文本返回的项目。过滤。

这在整体考虑中非常重要，因为两个查询操作（“text”和“geoSpatial”）都在努力实现非常不同的事情。 在“文本”案例中，它正在寻找给定术语的“最佳结果”，并且本质上仅返回与排名顺序中的术语匹配的限制数量的结果。 这意味着当应用任何其他过滤条件时，很可能满足第一条件的许多项目不符合附加标准。

简而言之， “不是所有的东西”惊人的“必须接近查询点” ，这意味着具有100 results的现实限制，并且通过最佳匹配，这100个可能不包含所有“近”项。

此外， $text运算符实际上并不以任何方式对结果进行“排序”。 它的主要目的实际上不仅是为了“匹配”一个短语而是为了“得分”结果，以便将“最佳”匹配浮动到顶部。 这通常在查询本身“之后”完成，其中投影值被“排序”并且最可能如上所述“受限制”。 可能在聚合管道中执行此操作然后应用第二个过滤器，但如上所述，这可能排除了在另一个目的中“接近”的事物。

相反的情况也可能是正确的（ '有很多“惊人的”东西远离这一点' ），但是由于实际的距离限制，这种情况变得不太可能。 但是给出的另一个考虑因素是这不是真正的文本搜索，而只是使用正则表达式来匹配给定的术语。

作为最后一点，我总是在这里使用"Amazing"作为示例短语而不是问题中建议的"Most" 。 这是因为“词干”在这里（以及在大多数专用文本搜索产品中）的文本索引中的工作方式，因为特定术语将被忽略 ，就像“和”，“或”，“the”，甚至“in” “也是如此，因为它们并不真正被认为对短语有价值 ，这就是文本搜索的作用。

因此，事实上，正则表达式实际上更适合匹配这些术语，如果确实需要的话。

结论

这真的让我们回到原点，因为“文本”查询真的不属于这里。 其他有用的过滤器通常与真正的“地理空间”搜索标准协同工作越好，真正的“文本搜索”在重要的列表中真的很低。

更有可能的是，人们希望位于距离他们希望访问的目的地的距离“设置交叉点”内的位置，或者至少接近某些或大多数距离。 当然，如前所述的其他因素（*“价格”，“服务”等）是人们普遍需要的东西。

以这种方式寻找结果并不是一个“合适的” 。 如果你认为你真的必须，那么应用其中一种“作弊”方法，或者实际上使用不同的查询，然后使用其他一些逻辑来合并每组结果。 但是服务器单独执行此操作确实没有意义，这就是它不尝试的原因。

因此，我将专注于首先使您的geoSpatial匹配正确，然后应用对结果重要的其他批评。 但我真的不相信“文本搜索”无论如何都是有效的。 相反，“作弊”，但只有你真的必须。