GeoJSON和MongoDB:将点存储为GeoJSON.Point值得吗？

Question

随着2.3 >位置数据处理和查询,MongoDB 的引入变得更加有用.MongoDB将文档存储为BSON,因此每个文档都包含所有文档字段,这显然可能导致比传统RMDBS更大的数据库.

我曾经将折线和多边形存储为一系列索引点,一个额外的字段代表每一行的顺序(我这样做是为了确保一致性,因为我使用JavaScript,因此点并不总是以正确的顺序存储).它是这样的:

polyline: {
  [
    point: [0,0],
    order: 0
  ],
  [
    point: [0,1],
    order: 1
  ]
}

而现在我使用:

polyline: {
  type: 'LineString',
  coordinates: [
    [0,0],
    [1,0]
  ]
}

我已经看到文档大小有所改善,因为一些折线最多可以有500个点.

但是,我想知道存储我所有Point数据的好处是什么GeoJSON.我对文档大小的增加感到气馁,例如:

loc: [1,0]

比...更好

loc: {
  type: 'Point',
  coordinates: [0,1]
}

因此更容易合作.

我的问题是:

是否更好/建议将点存储为GeoJSON对象而不是2点阵列？

我考虑的是以下内容:

大小限制:我可能有数百万个带位置的文档,这可能会影响集合的大小,可能会影响我的口袋.
一致性:最好处理lng, lat格式中的每组坐标,而不是坚持lat, lng使用点,而前者用于我所有其他位置功能.
方便:如果我抓住一个点,并使用$geoWithin或$geoIntersects使用它,在将其用作query参数之前,我不需要先将其转换为GeoJSON .

我不确定的是:

我宁愿搬到GeoJSON我的数据仍然可以管理的地方,而不是在未来的大量压力下转换.

我可以请求彻底(即使稍微)考虑过的答案.我不会很快选择正确的答案,所以我可以评估任何回复.

我也不确定SO是否是提出问题的正确位置,所以如果DBA是一个更合适的地方,我会在那里提出问题.我选择了SO,因为这里有很多与MongoDB相关的活动.

Answer 1

我建议使用新的GeoJSON格式.虽然我不相信任何关于放弃对旧格式的支持的公告,但他们将其称为遗产的事实应该表明他们的意见.

使用2dsphere而不是2d有一些索引优势.

首先,它实际上基于地球是一个球体来计算查询.2d索引的一个缺点是,如果您对查询所涵盖的实际区域而不是基本的lat/lng感兴趣,则不会考虑这种意义,即您必须自己处理转换.
使用复合索引的能力,如果你想做一些事情,比如"先从最近的这个区域得到100个结果",那么2dsphere是你唯一的选择.
使用geoIntersects查询的能力.
geoWithin几何查询要求您使用geoJSON格式.

另一个需要注意的重要事项是,您需要确保您使用的索引支持您正在使用的查询.例如,如果您使用2dsphere,则无法使用$ box查询,因为它不会被编入索引 - 但是mongo不会警告您 - 结果只会执行表扫描并且会非常慢!