随着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
,我不需要先将它转换为 GeoJSON,然后再将它用作query
参数。
我不确定的是:
- 未来是否
loc: [x,y]
会在 MongoDB 上放弃对 的支持 - 任何索引都受益
2dsphere
于2d
- 对 MongoDB 的任何计划
GeoJSON
添加是否可能导致需要上述一致性。
我宁愿GeoJSON
在我的数据仍然可以管理的时候搬到那里,而不是在未来承受很大压力的情况下切换。
请我请求一个彻底(即使是稍微)深思熟虑的答案。我不会很快选择正确的答案,所以我可以评估任何回复。
我也不确定 SO 是否是提出问题的正确位置,所以如果 DBA 是一个更合适的位置,我会将问题移到那里。我之所以选择 SO,是因为这里有很多与 MongoDB 相关的活动。