使用 dmesg 来查看一些硬件或驱动程序的信息或问题。

关于ES分片中的拷贝物理文件

Elasticsearch | 作者 Charele | 发布于2022年10月11日 | 阅读数:1274

前些日子,看到过一个问题,问的是副分片恢复时,主分片向副分片拷贝物理文件时,
为什么不用zero-copy?
https://elasticsearch.cn/question/3872
 
其中回答了说这种情况下,不能用zero-copy之类的。
我的看法是,其实可以用,但是不是必须。
 
Kafka中用,是因为那是常态,需要连续不断的从一个节点到另一个节copy文件,
(猜的,只用过RabbitMQ,没用过Kafka,也许说错了)
 而ES中,这种copy文件只是偶尔在副分片恢复(其实不止副分片,主分片也用)时,才需要。
所以说收益不大,所以ES里没有专门去用。
 
 
已邀请:

Charele - Cisco4321

赞同来自:

先认识一下“副分片恢复”这个操作,
首先说一个插曲,新版ES里面,加了一个模块,
333.png

刚开始看到这个东东时,没明白是什么意思。
“基于快照的恢复”?快照创建好了,不能恢复,快照还有啥用???
 
后来才明白它的意思。它的作用就是,
在如上场景里面,在分片恢复时phase1()阶段不需要从源节点拷文件了,
可以从快照里取文件。
这是一个选项,可用可不用。前提是,此分片的快照得先存在才行 
 
 副分片恢复是一个复杂的过程,具体步骤在这里不述说了,
网上许多文章。
  采用的是“发请求1”---> “收回应1” ---> "发请求2" ---> "收回应2“ -->,,,,
这样一个一步接一步的形式,
 
1111.png

其中红色的,就是拷贝物理的请求,它是"把物理文件包在这个请求里",
然后副分片节点接收,

Charele - Cisco4321

赞同来自:

222.png

这就是它包装的一个Lucene文件,
其实ES并不会去解析这些文件的内容。
单个"_0.cfe", "_0.cfs"这样Lucene文件,是解析不出什么东西来的,也没必要去解析。
分析出缺失哪些文件,直接拷贝过去就行了。
 
所以,从一个节点向另一个节点copy文件,不管你用零copy也行,别的方式也好,都是可以的。
只是ES没有用而已,说不定在以后的版本中,会改成这零copy的方式。 
 

Charele - Cisco4321

赞同来自:

类似的问题,
https://elasticsearch.cn/question/7377
这里问,为什么ES里面不用bloom filter,
有人解释了不能用等等。
 
我们知道bloom filter,有局限性,但至少在某些场景是可行的。现在不用,并不表代以后不能用。
333.png

 
现在最新版本是8.4.3,,, 
 
 

Charele - Cisco4321

赞同来自:

这个问题,刚好有一个类似的例子。
 关于ES和Cassandra的关系,就不必多说了。
虽然他们是不同的东西,但可以说是一脉相承,懂的自然懂:-)
 
 
他在新版4.0里面,把streaming,就改成了用zero-copy方式去实现,原来不是
qqq.png

用Cassandra的人可能容易理解这个

Charele - Cisco4321

赞同来自:

我想了下,如果自己要实现ES的zero-copy也是可以的
可以参考下Cassandra的代码,看看它是如何实现的(我是说细节),
然后改下这个FileChunkRequest和对应的请求处理,当然实现难度可能不小。
 
收益大不大就是别外一回事了

要回复问题请先登录注册