mongodb - GeoJSON 和 MongoDB : Is it worth it to store points as GeoJSON. 点？

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 点，前者用于我的所有其他位置功能。<​​/li>
• 方便:如果我捕获一个点，并使用 $geoWithin 或 $geoIntersects ，我不需要先将其转换为 GeoJSON 再使用它作为 查询 参数。

我不确定的是:

• future 是否会在 MongoDB 上放弃对 loc: [x,y] 的支持
• 与 2d
相比， 2dsphere 的任何索引优势
• 任何计划中的 GeoJSON 添加到 MongoDB 是否可能导致需要上述一致性。

我宁愿在我的数据仍可管理的情况下迁移到 GeoJSON，也不愿在未来承受很大压力时切换。

我能否请一个彻底(即使是稍微)深思熟虑的答案。我不会很快选择正确的答案，所以我可以评估任何答案。

我也不确定 SO 是否是提出问题的正确位置，所以如果 DBA 是更合适的位置，我会将问题移到那里。我之所以选择 SO，是因为这里有很多与 MongoDB 相关的事件。

Answer 1

我建议使用新的 GeoJSON 格式。虽然我不认为有任何关于放弃对旧格式的支持的公告，但他们将其称为旧格式这一事实应该表明了他们的观点。

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

• 首先，它实际上基于地球是一个球体来计算查询。 2d 索引的一个缺点是它没有考虑到这意味着如果您对查询所涵盖的实际区域而不是基本的纬度/经度感兴趣，则必须自己处理转换。
• 使用复合索引的能力，如果您想执行“首先从该区域获取 100 个最近的结果”之类的操作，那么 2dsphere 是您唯一的选择。
• 使用 geoIntersects 查询的能力。
• geoWithin 几何查询要求您使用 geoJSON 格式。

另一件需要注意的重要事情是，您需要确保所使用的索引支持您使用的查询。例如，如果您使用 2dsphere，则不能使用 $box 查询，因为它不会被索引 - 但是 mongo 不会警告您 - 结果只会执行表扫描，并且会非常慢!

Mongo provide a compatibility chart of which queries can be used with which index