Exchange 导入数据及全文索引同步数据到 ES

Exchange 导入数据及全文索引同步数据到 ES

如题所示,开始时我们将 Exchange 通过 MySQL 导入数据的例子和全文索引的例子做了结合,所以整了这一出戏。

  1. 机器配置 4核 + 16G + SSD CentOS Linux release 7.8.2003 (Core)
  2. 采用 rpm 方式安装 Nebula Graph,三个服务都是单节点。
  3. 定义了 12 个 tag,20 个 edge。
  4. 5 万 6 千多个点、15 万条边
  5. 定义了 12 个 tag 索引 8 个 edge 索引。
  6. 其中有一个 tag 内包含句子,需要做全文索引。

这种情况下,通过 Exchange 一次性全部导入数据后添加和重建索引,使用 导入MySQL数据 - NebulaGraph Database 手册 配置模板设置 batch:1000 partition:32 最终导致 ES 被持续请求没有中断迹象,持续第二天,我们主动切断了 listener 服务,drop 掉了图空间。

在之后的时间里经过对 Nebula 基于 ElasticSearch 的全文搜索引擎的文本搜索_nebula 对日期搜索_图数据库NebulaGraph的博客-CSDN博客 这篇官方博客的研究弄明白了数据同步到 ES 的原理,我看了一下源码。

分析三步走:

  1. 发现机器上一直有针对 9200 端口的 _bulk 批量插入请求。
  2. 阅读源码发现这个触发确实是由 eslistener 引起的。
  3. 根据博文讲述,eslistener 是因为 WAL 日志才会发起。
  4. WAL 日志是由 leader 同步过来的。

经过对 /usr/local/nebula/data/listener/ 目录观察发现不停有数据被同步过来。所以基本确认是 leader 到 listener 之间数据同步导致 ES 持续被请求,最终一个本来应该只有十几 MB 的 ES 索引被操作膨胀到了好几 GB。

因为之前知道单条数据操作没啥问题,所以就拆解了导入数据,分为多个过程导入,每个过程导入时单独创建索引触发es同步,而且调小了 Exchange 配置文件的 batch:25partition:8

在尝试和调整了好几次最终,定型成了上面的结论,最终避免了 leader 和 listener 同步问题,也解决了 ES 问题。

1 个赞

我修改了下你的正文格式,然后这里本来想给你修改下的,但是单条 和 单跳 好像都是逻辑合理的,所以不清楚你正确想表达的是啥。。。你自己修改下

修改了 是 【单条】数据的意思,嗐!