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阶段后的魔术。

图1：演示启动面板

您可以在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

参考文献：

• 维基百科文章： http ： //en.wikipedia.org/wiki/MongoDB
• MongoDB手册： http : //docs.mongodb.org/manual/
• 2d MongoDb索引： http ://docs.mongodb.org/manual/core/geospatial-indexes/
• MongoDB实际应用中，身份验证。 凯尔·班克（Kyle Banker），酒吧。 曼宁（Manning），©2012，ISBN 9781935182870
• OpenShift： https ：//www.openshift.com/
• Node.js： http ： //nodejs.org/
• jQuery Mobile： http ： //jquerymobile.com/
• Git命令： http : //git-scm.com/docs
• GitHub帮助： https : //help.github.com/
• NoSql是SQL续集吗？： http ://keyholesoftware.com/2012/10/01/is-nosql-the-sql-sequel/

代码项目

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

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

mongodb 地理距离