众所周知，Elasticsearch（ES）是日志分析ELK解决方案的重要一环，也是全文检索的好帮手。实际上，ES在LBS（Location based service）场景也同样好用，结合全文检索、结构化检索与分析，ES基本可以做到实时提供基于地理位置的多种信息。

UCloud Elasticsearch（UES）是基于Elasticsearch和Kibana打造的日志管理分析服务。为支持LBS场景，UCloud（优刻得）已于近日推出UES大内存机型，可支持配置16核64G，其性能可以满足更频繁的位置查询。

UES功能进一步升级

UES通过创建集群的方式来创建服务，集群自动初始化优良配置和丰富插件为用户提供快速创建、易于管理以及线性扩容。此外，UES还提供丰富的性能指标监控和可视化管理平台，高性能SSD磁盘有效提升海量日志数据存储、检索、分析的处理效率。通过本次功能升级，现已全力支持LBS场景。

LBS的应用场景有很多，生活中随处可见，比如社交应用中“附近的人”，或是本地服务应用中“附近的餐厅”等。还有一种不太引人注意的场景是零售行业广告营销中的位置营销（LBA）。LBA与前两种稍有不同，技术实现稍显复杂。下面以查看“附近的餐厅”场景为例，概述ES如何建立地理位置索引，以及如何用ES提供的REST API做位置查询。

（图：搜索当前点500米范围内的餐厅结果）

简单来说，ES在其中的作用分为两步。第一步是建立位置索引，存储餐厅经纬度坐标，在客户端用户开始查询时，用ES提供的geo_distance查询出一定距离内所有的餐厅。

本次示例选用UES服务作为基础服务支持，选择内存优化型实例配置，当数据量较大或地理位置查询较频繁时，集群类型可以选择UES提供的“主节点分离”型。

（图：UCloud控制台创建UES集群的界面）

◆ 创建mapping

ES支持geo_point和geo_shape两种地理位置数据结构类型。如果想用经纬度坐标表示位置，可以用geo_point字段；如果想存储和查询复杂的地形，可以用geo_shape字段。本次查询“附近的餐厅”应用场景使用geo_point更合适,代码示例如下：

PUT /index_name

{

"mappings": {

"TYPE_NAME": {

"properties": {

"location": {

"type": "geo_point"

}

}

◆ 建立索引

location字段被声明为geo_point后，就可以索引包含了经纬度信息的文档了。经纬度信息的形式可以是字符串、数组或者对象。例如，将［经度121.457，纬度31.215］的餐厅坐标点存入索引中，代码示例如下：

PUT index_name/index_type/1

"lat": 31.215,

"lon": 121.457

◆ 距离查询

当一个用户在［经度121.453，纬度31.216］的位置查询附近2000米内所有的餐厅时，内部服务可以向ES服务发起geo_distance查询，查询参数包括距离2000米和用户经纬度（121.453, 31.216）。ES服务会返回符合条件的餐厅，本例中会包括上一步中经纬度（121.457, 31,215）的餐厅。

至此就完成了利用UES查询客户端用户附近一定范围内的餐厅需求。在查询期间不需要部署服务，也无需了解地理位置上两点距离的算法，只需向UES发请求即可。本文中讨论的场景也仅是ES服务在地理位置应用（LBS）场景的一个小示例，在实际应用中还有更多地形对比、结合地图SDK的位置聚合等功能，值得继续挖掘。

发现数据更多价值

经过近一年的产品迭代优化，UES在性能表现和功能上更为出色，主要升级点包括：

可以做故障自动恢复，无需担心服务不可用；

提供了节点升级功能，让用户有多种扩容选择；

增加Elasticsearch的6.2.1版本，并全量发布x-pack插件，用户可在控制台一键安装，使用Kibana时更安全，安装后即可在Kibana中看到Elasticsearch服务本身更多监控指标，使用方便；

上线海外可用区，为用户业务的出海需求提供更多支持。

目前，UES也接入了UCloud（优刻得）其它数据分析产品，例如用户可以将UES数据备份到UHadoop，保证了数据安全。未来，UES将会接入UKafka等更多UCloud（优刻得）数据分析产品，为用户提供整套数据挖掘、数据分析以及可视化方案。UES可以省去企业部署和维护的成本，从而发现数据的更多价值。

—End—

点击“阅读原文”，了解更多UES产品信息。