您现在的位置是：首页 > 文章详情

Elasticsearch 字段类型之 Range 经典应用场景

日期：2020-07-06点击：662收藏

作者介绍：

李猛(ynuosoft)，Elastic-stack 产品深度用户，ES 认证工程师，2012 年接触 Elasticsearch，对 Elastic-Stack 开发、架构、运维等方面有深入体验，实践过多种 Elasticsearch 项目，最暴力的大数据分析应用，最复杂的业务系统应用；业余为企业提供 Elastic-stack 咨询培训以及调优实施。

现状背景

背景需求

产品信息，数据量在几个 TB 级以上，每种工业产品都有大量的标签信息，标签信息多数属于数值类型，且是属于范围那种数据，如某安防头盔尺寸是 L 码，配合适合范围55cm~65cm，对于此种数据查询，若标签属性较少，还可以走传统的数据库索引查询，若标签属性很多，则显然很吃力。

原有方案

企业技术负责人入行IT很早，原始的技术栈组合是 Sqlserver+Clucene 组合，原始工业产品信息存储在数据库中，搜索查询走 Clucene，有很多问题，如下：

• 自主包装 Clucene 核心库，框架与业务代码深度耦合，单次需求变更都需要发布版本，不具备稳定性
• 索引实时更新几乎没有，属于离线更新，且更新一次周期很长
• Clucene 版本很旧，对于搜索的支持还是早期分词阶段，仅支持倒排索引
• 对于范围搜索，采用的是分词方式实现，不能做到精确的范围搜索，这个是最核心迫切需要的功能
• 基于 Clucene 开发的搜索应用，索引数据太大，客户花很多精力实现分布式，且效果不理想。

技术实现

相比传统关系型数据库，Elasticsearch 实现的方式更加直接高效。

Range类型设置

Elasticsearch 支持多种范围类型

• 数值类型
• 日期类型
• IP地址类型

若在关系数据库中则每个标签属性需要2个字段表示范围值。

Range数据填充

填充范围数据，有多种表达式
• 大于，gt
• 小于，lt
• 大于等于，gte
• 小于等于，lte

Range数据查询

查询语法很简单，不过查询的关联关系有几种

• 相交，查询条件的范围与字段数据范围有交叉，默认使用
• 包含，查询条件的范围值，包含字段的数据范围值
• 反包含，与包含相反，查询条件的范围值包含在字段的数据范围之内。

若在关系数据库中查询相交则需要2组表达式合并才可以，若多个标签属性同时查询，则更复杂。

技术原理

在跟客户企业沟通中，发现比较重要的信息是，技术负责人对于搜索领域的知识认知比较陈旧，Lucene 发展早已不仅仅是倒排索引，已经支持了很多索引算法，且应用领域也早就突破分词搜索，Elastic 产品版本近年更新很快，相应的 Lucene 也一样。

为什么选择 Elasticsearch 替代关系型数据库做范围查询最合适呢？原因如下：

产品功能

Elasticsearch 从 2016 年引入了 BKD 树算法，在构建索引时会依据字段类型设置不同的算法实现，无需要人工干预，只要设计正确的类型，如下

• 若是字符类型的，基于 Inverted Index 构建索引
• 若是数值类型，基于 BKD-Tree 构建索引

算法介绍

• Bkd-Tree 作为一种基于 K-D-B-tree 的索引结构，用来对多维度的点数据 (multi-dimensional point data) 集进行索引。关于构建 BKD-Tree 过程不在本文探讨范围内，详细可以查阅更专业的论文。
• 从前面客户需求描述得到，客户的工业产品信息有很多范围类型的标签属性，在 Elasticsearch 中，仅需要构建一个索引即可满足高效查找，且默认是所有标签属性自动构造索引。
• 想想看若基于传统关系型数据库实现，每标签属性都需要至少 2 个字段，且多个标签属性要任意组合查询，不能通过一个索引实现，需要创建很多索引，查询时还必须保持最左原则；
• BKD-Tree 索引查询效率比关系型数据库的 BTree 更胜一筹。

结语

经验总结

• Elastic 核心基于 Lucene，功能发展非常成熟，普通用户没有必要基于 Lucene 自主开发搜索应用，只需要关注自己的业务实现。
• 数据产品的竞争更多的是产品背后实现算法的竞争，对于我们来说需要经常更新自己的知识体系，选择最合适的技术方案响应变化。
• DB 与 ES 混合应用已经成为当前潮流，Elastic 已经成为当前查询应用标配
• ES 用的好，下班必须早