Exchange 导入数据及全文索引同步数据到 ES
如题所示，开始时我们将 Exchange 通过 MySQL 导入数据的例子和全文索引的例子做了结合，所以整了这一出戏。
- 机器配置 4核 + 16G + SSD CentOS Linux release 7.8.2003 (Core)
- 采用 rpm 方式安装 Nebula Graph，三个服务都是单节点。
- 定义了 12 个 tag，20 个 edge。
- 5 万 6 千多个点、15 万条边
- 定义了 12 个 tag 索引 8 个 edge 索引。
- 其中有一个 tag 内包含句子，需要做全文索引。
这种情况下，通过 Exchange 一次性全部导入数据后添加和重建索引，使用 导入MySQL数据 - NebulaGraph Database 手册 配置模板设置 batch:1000 partition:32 最终导致 ES 被持续请求没有中断迹象，持续第二天，我们主动切断了 listener 服务，drop 掉了图空间。
在之后的时间里经过对 Nebula 基于 ElasticSearch 的全文搜索引擎的文本搜索_nebula 对日期搜索_图数据库NebulaGraph的博客-CSDN博客 这篇官方博客的研究弄明白了数据同步到 ES 的原理，我看了一下源码。
分析三步走：
- 发现机器上一直有针对 9200 端口的 _bulk 批量插入请求。
- 阅读源码发现这个触发确实是由 eslistener 引起的。
- 根据博文讲述，eslistener 是因为 WAL 日志才会发起。
- WAL 日志是由 leader 同步过来的。
经过对 /usr/local/nebula/data/listener/ 目录观察发现不停有数据被同步过来。所以基本确认是 leader 到 listener 之间数据同步导致 ES 持续被请求，最终一个本来应该只有十几 MB 的 ES 索引被操作膨胀到了好几 GB。
因为之前知道单条数据操作没啥问题，所以就拆解了导入数据，分为多个过程导入，每个过程导入时单独创建索引触发es同步，而且调小了 Exchange 配置文件的 batch:25 和 partition:8。
在尝试和调整了好几次最终，定型成了上面的结论，最终避免了 leader 和 listener 同步问题，也解决了 ES 问题。