随着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,然后再将其用作query
参数我不确定的是:
loc: [x,y]
的支持2dsphere
而非2d
GeoJSON
添加是否可能导致需要上述一致性。我宁愿转移到GeoJSON
,而我的数据仍然可以管理,而不是在未来很大的压力下切换。
我可以请求彻底(即使稍微)考虑过的答案。我不会很快选择正确的答案,所以我可以评估任何回复。
我也不确定SO是否是提出问题的正确位置,所以如果DBA是一个更合适的地方,我会在那里提出问题。我选择了SO,因为这里有很多与MongoDB相关的活动。
答案 0 :(得分:17)
我建议使用新的GeoJSON格式。虽然我不相信有任何关于放弃对旧格式的支持的公告,但他们将其称为遗产的事实应该表明他们的意见。
使用2dsphere而不是2d有一些索引优势。
另一个需要注意的重要事项是,您需要确保您使用的索引支持您正在使用的查询。例如,如果您使用2dsphere,则无法使用$ box查询,因为它不会被编入索引 - 但是 mongo不会警告您 - 结果只会执行表扫描并且会非常慢!
Mongo provide a compatibility chart of which queries can be used with which index
答案 1 :(得分:4)
是的,我认为这是值得的。根据我对地理空间信息系统的经验,最好将您的位置数据存储在一个有用且可转移的标准中。 MongoDB中的GeoJSON支持WGS84基准标准。
在MongoDB中,$near运算符可以搜索传统的2d坐标和GeoJSON坐标。在传统的2d坐标集合中,$ near返回最接近的第一个已排序集合。 $geoNear返回距搜索点元数据距离最近的第一个已排序集合。
另一个好处是能够使用其他地理空间查询(即$ geoWithin和$ geoIntersect),特别是如果您存储其他GeoJSON类型(折线,多边形)
我希望这些信息可以为您提供有关如何处理位置数据的一些思考点。
答案 2 :(得分:2)
如果您的数据库中仅存储点几何,但希望在该数据上支持多个不同的 GeoJSON查询,请注意可以存储点数旧版坐标对格式和使用2dsphere
索引。
mongoose的 GeoJSON支持(MongoDB&gt; = 2.4)的release notes给出以下示例:
遗留坐标对的 2dsphere
索引:
new Schema({
loc: { type: [Number], index: '2dsphere'}
});
GeoJSON
使用2dsphere
索引查询旧版坐标对:
var geojsonPoly = {
type: 'Polygon',
coordinates: [[[-5,-5], ['-5',5], [5,5], [5,-5],[-5,'-5']]]
};
Model.find({ loc: { $within: { $geometry: geojsonPoly }}});