mongodb 地理距离_MongoDB地理空间移动演示

mongodb 地理距离

蒙古语:名词(pl mongo或mongos)–蒙古的货币单位。 等于图格里克的百分之一。 源自蒙古的“银”

我已经写过有关NoSQL DBMS的文章[ http://keyholesoftware.com/2012/10/01/is-nosql-the-sql-sequel/ ]。 我们知道NoSQL DBMS有几种类别。 MongoDB是可扩展的NoSQL面向文档的数据存储,具有内置的地理空间索引。 让我们看一下它的特性,然后查看一个移动地理空间演示应用程序。

MongoDB特征

  1. 没有架构。 插入的文档可以具有不同的属性。 这是一把两刃剑,可以快速更改应用程序,或随时间轻松接受具有添加或新属性的数据。
  2. 没有SQL查询语言。 通过使用JSON而不是SQL查询输入的API进行CRUD。
  3. 面向文档。 将每个记录查看为集合中唯一键控的JSON文档。 数据库包含集合,而不是表。
  4. BSON。 我被吓坏了 MongoDB实际上使用BSON,这是JSON的二进制序列化表示形式[ http://bsonspec.org/ ]。 文档存储为BSON,但是JSON进入MongoDB,而JSON从其中出来。 除非我们使用的语言绑定比直接使用BSON的多,否则我们可以将数据视为JSON。
  5. 类型。 有UTF-8字符串,数组,嵌入式文档,日期,正则表达式,布尔值,64位数字,对象ID(OID),二进制,时间戳和JavaScript代码。
  6. 基于文档的查询。 指定JSON文档作为find参数。 如果没有提供,则结果是所有文档,一次一页。
  7. 索引任何文档属性。 属性是JSON属性名称。
  8. 原子更新。 数据更新力争就地进行。 MongoDB服务器将锁定整个集合,直到更新完成。 如果文档必须增长太多,则写入将成为较慢的复制和重写。 我们可以检查结果。 每个文档都有填充以防止过度的复制和重写。
  9. 写关心。 MongoDB使我们能够指定对写操作结果的关注。 以下越来越挑剔的类型的写入问题给出了一个概念:所有错误都被忽略,只有良好的写入未被确认,服务器关闭时日志保护,或者所有副本都已确认写入。
  10. 副本集。 这是一组共享单个数据集的分布式MongoDB服务器。 他们选出一位大师。 故障转移要求副本集自动选择一个新的主服务器。 这提供了高可用性和冗余。
  11. 最终的一致性。 副本集的所有成员都努力最终与所选主服务器同步。
  12. 自动分片。 MongoDB通过在服务器之间划分集合来水平扩展。 如果添加服务器,则MongoDB会自动将收集数据重新平衡到新服务器[ http://docs.mongodb.org/manual/sharding/ ]。
  13. 内存映射 。 数据流入和流出反映磁盘存储的内存映射文件。
  14. 休息。 mongod服务器提供了一个简单的只读REST查询接口。 一些语言绑定提供了功能齐全的REST服务[ http://docs.mongodb.org/ecosystem/tools/http-interfaces/#HttpInterface-RESTInterfaces ]。
  15. 映射减少。 复杂的聚合任务使用map-reduce [ http://docs.mongodb.org/manual/core/map-reduce/ ]。 如果分片了目标集合,则每个分片服务器都可以处理map-reduce操作的各个部分。 可以将单词计数视为适合于映射减少的琐碎示例。 此处查询结果中的所有单词都减少为一个数字。
  16. 聚合。 聚合框架无需获取更复杂的map-reduce就可以获取聚合值。 所有文档都通过一个聚合管道,其中可选的运算符可以过滤数据。 例如,一个运算符是$ sort。 无状态表达式可以从管道中的当前文档生成输出文档。
  17. GridFS。 任何大小的文件都可以驻留在跨服务器的256K块中的集合中。 我们可以将读取放置到文件的中间,而无需将数据完全加载到内存中。 mongofiles命令有助于处理GridFS文件。
  18. 地理空间索引。 我们可以索引任何属性。 此外,我们可以在空间上索引某些属性。 如果属性由2D或3D数值作为坐标组成,则可以将该属性作为2D或3D空间索引编制索引。 坐标通常是地球位置,但是游戏网格有效。 下一节将介绍有关地理空间索引的更多信息。
  19. 上限集合。 我们可以限制或设置馆藏上限,以使最旧的文档在馆藏大小达到上限后消失。 这对于日志记录和分析很有用。 它可以构成企业首次涉足NoSQL。
  20. 贝壳。 内置的基于命令的客户端提供管理和查询功能。
  21. HTTP控制台 。 我通过URL访问内置的基于Web的控制台,该URL的端口比mongod服务器的端口高1000。 例如,对于localhost上的标准端口27017,请使用http:// localhost:28017 /

地理空间数据库

我喜欢几何图形和贴图[ http://keyholesoftware.com/2013/01/28/mapping-shortest-routes-using-a-graph-database/ ]。 我提到过MongoDB支持2d地理空间索引。 每个条目都可以将文档与二维空间中的点相关联。 它可能是地图上的一个点,也可能是游戏网格中的一个点。 MongoDB使用这些索引支持以下几种基于位置的数据:

  • 接近查询,根据距离到提供点的距离来返回文档。
  • 选择在给定区域内具有位置值的文档的有界查询。
  • 选择与精确坐标匹配的文档的精确查询。

我见过一些移动应用程序,它们返回位于我手机附近的实体的列表或地图。 例如,请参阅Gas Buddy [ http://gasbuddy.com/ ]。 这样的应用程序将如何工作? 我想边做边学。 似乎我需要空间数据以及一种查询位置附近的方法。

行动中的MongoDB 》一书附录E论述了空间查询。 它提供了指向适合于导入邮政编码信息的压缩JSON数组文件的链接[ http://mng.bz/dOpd ]。 每个JSON数组对象如下所示:

{ "_id": "510dcc6b24b2186932ec4362", "city": "SPOKANE", "zip": "99205", "loc": { "y": 47.69641, "x": 117.439912 },"pop": 42032, "state": "WA"}

该对象是具有城市,州,邮政编码,邮政编码人口和xy坐标的文档。 y是纬度; x是经度。 每个_id是唯一的-数据库主键。 该文件已准备好导入到MongoDB中。

我使用他们网站[ http://www.mongodb.org/ ]上的说明安装了MongoDB。 MongoDB有一个基于命令的管理和查询控制台mongo 。 在那里,我创建了数据库地理空间。 我运行了mongoimport命令来填充数据库:

$ mongoimport -d geospatial -c zips zips.json

回到蒙哥,我发出:

use geospatial;
db.zips.find();

“查找”参数是JSON匹配文档。 空的find参数产生所有文档的分页控制台转储,每个文档的格式都类似于前面看到的示例JSON文档。 我想查询给定经度和纬度附近的记录。 我需要zips集合上的2d空间索引。 我参考了《 操作 手册》 中的《 MongoDB》和《 MongoDB手册》,以了解如何使用以下方法创建地理空间二维索引:

db.zips.ensureIndex( { loc : "2d" } )

这使我的zip集合大脑可以针对所提供的纬度和经度来响应邻近查询。 MongodDB发挥了魔力。 MongoDB邻近查询元键为$ near 。 我想在每个文档中的一个经度/纬度(即y / x)对象附近的位置附近压缩zip收集文档。 例如:

db.zips.find( { 'loc': {$near : [ 47.6, 117.45] } } ).limit(3)

这转储了三个JSON文档,其中包含与我家乡的坐标最接近的邮政编码:

{ "_id" : ObjectId("510dcc6b24b2186932ec4361"), "city" : "SPOKANE", "zip" : "99204", "loc" : { "y" : 47.640682, "x" : 117.471896 }, "pop" : 24611, "state" : "WA" }
{ "_id" : ObjectId("510dcc6b24b2186932ec4360"), "city" : "SPOKANE", "zip" : "99203", "loc" : { "y" : 47.629443, "x" : 117.404121 }, "pop" : 20454, "state" : "WA" }
{ "_id" : ObjectId("510dcc6b24b2186932ec435e"), "city" : "SPOKANE", "zip" : "99201", "loc" : { "y" : 47.666485, "x" : 117.436527 }, "pop" : 9599, "state" : "WA" }

请注意,查询输入是JSON文档。 该$ near运算符是MongoDB地理空间功能。 limit(3)是一个过滤API调用。

地理空间REST服务

凉! 接下来,我需要一个只读的REST服务,该服务可以返回与通配符部分城市查询匹配的记录列表。 用户可以将这些结果文档字段之一发送到另一个REST目标,该目标将返回$ near记录的列表,我将从中获得每个邮政编码。 我可以使用mongo控制台测试两个查询。

我将Node.js用作HTTP服务器是因为它的MongoDB语言绑定提供了功能齐全的REST路由……并且我想尽可能地使Node.js厌烦。 那是另一篇博客文章。

红帽OpenShift平台即服务(PaaS)云给了我免费放置服务的地方。 它有一套“墨盒”可供选择。 其中包括MongoDB和Node.js。 OpenShift具有基于Git的部署以及可在其中运行mongo shell的SSH shell。 我将数据库导入驻留在我的云层中的MongoDB实例。 我基于三个MongoDB查询编写了一个简单的Node.js REST服务。 我使用Git命令将其部署到了OpenShift。

在这一阶段,我可以使用浏览器或curl命令测试我的REST服务。 示例网址如下。 单击它们以查看JSON结果。

  • 名称包含KANS的城市列表… https: //geospatial-mauget.rhcloud.com/cities/KANS
  • 邮政编码27516附近的位置列表… https: //geospatial-mauget.rhcloud.com/near/zip/27516
  • …重定向到邮政编码27516的纬度/经度附近的位置列表… https: //geospatial-mauget.rhcloud.com/near/lat/35.579952/lon/78.790807

移动地理空间应用

我的REST服务需要一个客户端。 我为Node.js服务器提供了一条附加路由,该路由仅返回缓存的静态index.html页面。 该页面包含该服务的单页jQuery-Mobile客户端。 物理页面包含针对此简单应用程序以HTML5,CSS和jQuery Mobile JavaScript实现的控制器和视图。

该页面根据用户的触摸来执行AJAX REST调用。 然后,它呈现返回的JSON。 第一个逻辑页面位于上面的第一个预输入搜索定位查询的前面。 请参见图1和图2。每个用户输入字符都会导致对MongoDB的往返查询,并显示位置列表。 触摸任何搜索结果行以呈现第二个逻辑页面。 参见图3。它使用查询二来查询给定邮政编码的纬度/经度。 该查询始终导致重定向,以查询三个查询以获取经度/纬度的$ near结果列表。 我在服务器上使用了重定向,而不是向客户端添加代码来发出查询3。因此,客户端无需处理纬度/经度,就可以请求并接收附近城市的邮政编码列表。

此时,请求-响应周期离开MongoDB。 该服务重定向到Google地图,以将这些$ near结果显示在地图上。 每个地图图钉都是最接近所选邮政编码的邮政编码。 触摸图钉会弹出有关该邮政编码的信息。 Google和一些JavaScript执行了Mongo阶段后的魔术。

image03

图1:演示启动面板

image04

image05

您可以在GitHub上克隆或下载源代码的存档: https : //github.com/mauget/geospatial-mongodb 。 存储库克隆或Zip文件下载选项位于该页面的右下方。 您将需要自己的Google Maps API密钥,否则您的副本将无法在Google Maps上使用。

您可以在https://geospatial-mauget.rhcloud.com/上尝试我的部署。 它的布局是静态的,因此在电话中看起来更好。 对于假电话,请尝试http://iphone5simulator.com/ 。 向Red Hat致敬,因为它提供了“免费获取三个应用程序”的OpenShift PaaS云服务,该服务托管了该演示,并且在一小时的不使用后便不会进入睡眠状态。

有什么好处?

该应用程序是一个演示。 但是,请考虑将位置集合变形为更细粒度的公司地址集合,而不是将邮政编码和邮政编码总数进行粗略的收集。 每个企业都可以注册一个文件,该文件具有其街道地址的GPS纬度/经度以及企业信息。 该文档可以代表加油站,一块房地产,一家餐厅,一个公园,一个气象图,一家餐厅及其美食……无论有用的应用程序想要在地球上某个点附近呈现什么地理位置。 某些商业文档可能具有不同的属性,例如餐馆的美食类型。 没有模式,因此由应用程序来处理路由属性或忽略它们。

该应用程序可以查询附近的位置。 响应操作将呈现这些地址的地理地图,并为每个地址添加一个图钉。 另一个视图可以是按距离或字母顺序排列的位置列表。 触摸图钉或列表项可查看其信息的深入信息。 一项夜间工作可以实时更新业务数据而不会受到干扰。 最终的一致性对这种更新很友好。

为什么选择MongoDB? 关系型DBMS具有空间API,包括Oracle和DB2。 请在本文顶部重新阅读MongoDB的特征。 看来MongoDB适合大响应数据。 分布式关系型DBMS最终将在跨副本管理事务时碰壁,同时尝试扩展到某个点。 我们不在乎这种应用程序的交易。 如果我们可以轻松获得扩展的水平和垂直缩放比例,则最终的一致性是可以接受的折衷方案。 有些电话和平板电脑的编号可能像沙粒一样,可以从这种应用程序中提取出来。

–娄·莫格(Lou Mauget),asktheteam @ keyholesoftware.com

参考文献:

代码项目

参考: Keyhole Software博客上来自我们JCG合作伙伴 Lou Mauget的MongoDB地理空间移动演示

翻译自: https://www.javacodegeeks.com/2013/07/mongodb-geo-spatial-mobile-demo.html

mongodb 地理距离

  • 0
    点赞
  • 0
    收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:编程工作室 设计师:CSDN官方博客 返回首页
评论
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值