Elasticsearch 查询和数据同步 - 记一次技术实践

前言

前段时间与同事一块儿为产品接入了 Elasticsearch 框架技术。从参与方案会议到搭建开发上线过程当中有不少讨论点，故产生本文，但愿藉此总结和分享一些经验。

1. 业务模型

接触已有的业务时，数据模型是最先须要知道的信息。我和同事负责接入 Elasticsearch 的产品是一个业务繁多的通信录，简化下来就是 3 个关键的模型，以下：

• 部门（Department）
• 人员（User）
• 标签（Tag）

它们的用途和联系，就跟它们的词义同样。
由此产生的业务以下：

• 经过 标签 查询 部门、人员
• 经过 部门 查询 人员

基于以上模型和业务，在典型的关系型数据库下，为了实现关联关系，天然会有额外的关联表：

• 部门人员关联表：每条记录包含1个部门，1我的员
• 标签对象关联表：每条记录包含1个标签，1个部门或人员

2. 需求

Elasticsearch 的特色有全文检索、分布式、海量数据下近实时查询。
当时为通信录业务引入 Elasticsearch 的需求和目标以下：

• 多字段的匹配或模糊查询。这些部门、人员、标签数据本来存储在 MySQL 中，若是要作匹配多个字段的模糊查询就比较吃力了，考虑一个经常使用功能 “输入姓名/手机号/拼音/首字母来查询人员”。而快速查询此类业务是 Elasticsearch 能够提供的。
• 基础模块能力。其余业务模块也提出了相似全文检索的需求，所以在通信录业务首次应用 es 时，要定义和提供好 es 的访问和工具方法，供其余模块在将来接入时，能复用一些实现，能保持一致的接口和命名风格等。

3. 索引设计

从原 MySQL 数据库表，到 Elasticsearch 的索引，数据模型的变化称为异构。
Elasticsearch 适合解决在 MySQL 中多条件或连表这样比较慢的查询业务，所以除了原有的信息字段，咱们会再附加 3 个模型的关联关系到 es 索引中。

索引 字段	原有	关联关系
部门	部门名、完整部门路径名	（无）
人员	姓名、拼音、首字母、手机号	父部门Id、全部父级部门Id、标签Id
标签	标签名	部门Id、人员Id

（上表略去了一些无关本篇内容的字段，如 SaaS 平台的租户Id、每一个对象的信息详情字段）

• 是否须要添加关联关系的字段，是由业务需求决定的。拿人员索引的 “全部父级部门Id” 举例子，由于有查询部门下全部人员（包括直属、子部门下的）的业务需求，因此会设计这么一个字段。
• 可使用 Elasticsearch 的分词功能来记录关联关系的字段中。为该字段定义一个分隔模式为竖线 “|” 的分词器，把若干个关联Id存成一个拼接的字符串。

4. 版本选择

同事是个版本控，在选择版本时了解和考虑了很是多的信息。不过版本选择确实是为平台接入新技术时的一个重要考虑点。咱们提出这个方案的当时（2018年4月），对比了主要使用的云服务提供商的几个版本，考虑项能够按优先级归纳为：

1. 稳定的
2. 案例资料多的
3. 时新程度，包括 Elasticsearch版本 和 Lucene版本
4. 咱们已经使用了某家云服务提供商，会偏向再用其提供的服务

几个版本对比

咱们当时选择了 Elasticsearch 6.2.2 版本。

v5.6.4

• 是 Spring 整合的各个框架中，支持数最多的版本
• 市面使用人数较多，资料较多
• 其依赖的 Lucene 大版本是v6，较旧

v6.2.2

• 是当时稳定的版本中最新的，性能比 v5 好

v6.2.4

• 是当时最新的版本，修复了许多 bug
• 性能更好，是官方推荐的版本
• 官方的技术文档部分还没更新，得看旧文档
• 市面上找不到相应的人的使用资料

版本发展（于2019年4月）

在写本篇文章时，我再去了解了和 Elasticsearch版本 相关的变动：

• Elasticsearch稳定版本中最新的是 v7.0、v6.7
• 依赖的Lucene版本分别为 v8.0、v7.2
• Spring 的稳定支持程度为：v3.2.x 的 spring data elasticsearch 支持 v6.5.0 的 elasticsearch 版本，比最新版本低一些。

5. 导入已有数据

考虑到要使用 Elasticsearch 时，一般意味着已经有不少数据了。首次使用天然会有导入已有数据的过程，并且这些数据量都是很大的。
咱们的方案是 JDBC 查询并提交给 es。设计要点有：

• 分批。数据量之大已经没法一次存到内存中。数据按明确的边界划分而独立，会让多线程处理、日志记录、重试都变得轻松。按租户来划分就是一种好的方式。
• 缓慢。避免影响线上的服务，同时适当给 JVM 回收和 Elasticsearch 处理留一点时间。
• 异常。信息汇总和失败重试。

具体设计细节以下：

1. 为 SaaS 系统的每一个租户建立一个任务，提交到ExecutorCompletionService。
2. 在该租户的任务中：
   一次查询全部部门；
   分页查询全部人员、部门人员关联；
   一次查询全部标签，标签对象关联；
3. 将关联关系作成便于查询的数据结构，以用于添加 es 文档时的快速查询。
   例如，映射<人员，部门>可用于查询：人员所属的部门；
   例如，映射<部门，标签>可用于查询：部门所贴的标签；
   用到了 Guava 的 Multimap，以达到相似于 Map<String, Set<String>> 的效果。
4. 创建新增 es 文档的批量请求BulkRequest。对于每一个对象，均可以用上一步作好的结构快速获取其关联关系。
5. 提交批量新增请求给 es。

6. 数据源同步

咱们的 MySQL 数据同步到 Elasticsearch 的方案，是在应用层基于事件通知进行的。以人员对象为例，步骤以下：

1. 人员的增删查改事件，都会通知给其余订阅者。这是已有的逻辑；
2. 设计一个“记录人员变更”订阅者，被通知时，将变更储存起来；
3. 设计一个“Es同步”定时任务，天天凌晨，取出变更记录，提交到 Es，以后删除变更记录；

看到这个方案，你可能会问为何不使用像 Logstash 等成熟的框架或插件，而是自写一套同步方法？缘由以下：

• 咱们选择的 MySQL 云服务提供商在当时没有提供 binlog 日志访问。这使咱们没法选择一些基于日志的同步方案。
• 部门、人员、标签的数据表本来没有像 update_time 这样的——能反映变动的列。故又能够排除基于时间去增量同步的方案。
• 人员、标签表的数据量很大，若是要增长一列 update_time 并加上索引，带来的成本有：额外的储存空间（咱们购买的云服务空间每增加百G每一年的成本大约是1000元）；新字段给应用层带来的维护成本。
• 设计出来的 Es 索引和 MySQL 表的字段不一样。一些在 Es 索引中新增的字段，是须要在 MySQL 中作额外查询才能获得的。