主要知识点
- 优化写入流程实现近实时
- 优化写入流程实现持久化和数据恢复
- 优化写入流程实现海量磁盘文件合并
一、优化写入流程实现近实时
在第68节中写到了es写入document所要经历的步骤,这个流程有一个问题,那就是每次都必须等待fsync将segment刷入磁盘,才能将segment打开供search使用,这样的话,从一个document写入es直到它可以被搜索,时间可能会超过一秒钟,这就不是近实时的搜索了,这个流程的主要瓶颈在于fsync把数据写进磁盘是很耗时的。如果等这个过程完成才打开index segment进行搜索的话时间会较长。
改进后写入流程别改进如下:
(1)数据写入buffer
(2)每隔一定时间,buffer中的数据被写入segment文件,但是先写入os cache
(3)只要segment写入os cache,那就直接打开供search使用,不立即执行commit
(3)执行commit操作后再把cache中的数据写入到磁盘。
当数据写入os cache,并把index segment打开供搜索的过程,叫做refresh,默认是每隔1秒refresh一次。也就是说,每隔一秒就会将buffer中的数据写入一个新的index segment file,先写入os cache中。所以,es是近实时的,数据写入到可以被搜索的间隔默认时间是1秒。
也可以手动执行refresh,一般不需要手动执行,让es默认执行就行了。
语法:POST /my_index/_refresh
调整refresh的时间间隔
如果时效性要求比较低,比如:要求一条数据写入es,一分钟以后才让我们搜索到就可以,那么就可以调整refresh interval
PUT /my_index
{
"settings": {
"refresh_interval": "30s"
}
}
二、优化写入流程实现持久化
上述主要讲解了优化写入流程实现近实时,但是数据未写入磁盘,所以还不能做到持久化,下面主要讲解优化写入流程实现持久化。
优化写入流程实现持久化的过程大致由以下几个步骤:
(1)es数据写入buffer缓冲,同时把es操作过程写入translog日志文件
(2)每隔一秒钟,buffer中的数据被写入新的segment file,并进入os cache,此时segment被打开并供search使用,这一步就是上面讲到的优化写入流程实现近实时。
(3)当buffer的数据写入到os cache之后,buffer被清空
(4)重复1~3,新的segment不断添加,buffer不断被清空,而translog中的数据不断累加
(5)当translog长度达到一定程度的时候,执行commit操作,commit操作主要执行以下几个步骤:
(5-1)buffer中现存的所有数据写入一个新的segment,并写入os cache,打开Index segment供搜索使用,然后把buffer被清空
(5-2)把一个commit ponit写入磁盘,这个commit ponit 标明了所有的index segment
(5-3)filesystem cache中的所有index segment file缓存数据,被fsync强行刷到磁盘上
(5-4)现有的translog被清空,创建一个新的translog
三、数据恢复
基于translog和commit point,实现数据恢复
fsync操作加上清空translog,就是flush操作,默认每隔30分钟flush一次,或者当translog过大的时候,也会执行flush操作,也可以手动执行flush操作。但是建议不要手动执行flush操作,让es默认执行就行。 语法 : POST /my_index/_flush
translog文件每隔5秒会被fsync一次到磁盘上进行保存。在一次增删改操作之后,当fsync在primary shard和replica shard都成功之后,那次增删改操作才会成功。
但是这种在一次增删改时强行fsync translog可能会导致部分操作比较耗时。并且因为是每隔5秒把translog文件保存到磁盘中,所以可能有5秒的translog文件丢失,进而导致5秒的es数据丢失,如果程序可以允许部分数据丢失,那么将es设置异步fsync translog会大大提升性能,
将es设置异步fsync translog的语法
PUT /my_index/_settings
{
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}
四、优化写入流程实现海量磁盘文件合并
上述优化步骤可以看出es会每秒一个segment file,这就导致es的segment file文件过多,而且每次search都要搜索所有的segment,很耗时,性能会很差,所以es默认会在后台执行segment merge操作,把多个小的segment file merge一个大的segment file ,在merge的时候,被标记为deleted的document也会被彻底物理删除
每次merge操作的执行流程
(1)选择一些有相似大小的segment,merge成一个大的segment
(2)将新的segment flush到磁盘上去
(3)写一个新的commit point,包括了新的segment,并且排除旧的那些segment
(4)将新的segment打开供搜索
(5)将旧的segment删除
也可以手动执行merge操作,但是建议尽量不要手动执行,让它自动默认执行就可以了
语法:
POST /my_index/_optimize?max_num_segments=1,