一 document写入流程--第一版
1. document写入流程:
(1)document数据首先被写入内存buffer缓冲中。
(2)执行commit操作,写commit point到磁盘。
(3)buffer中的数据就会写入一个新的index segment。
(4)等待在os cache中的index segment被fsync强制刷到磁盘上。
(5)步骤(3)中的新index sgement被打开,供search使用。
(6)清空 buffer。
当index segment被打开以后,search操作就可以到index segment中去搜索了。
2. 删除操作
如果是删除操作,每次commit的时候,就会生成一个.del文件来标明那个index segment中的哪个document被删除了。
3. 更新操作
如果是更新操作,会将现有的doc标记为deleted,然后将新的document写入新的index segment中。后续搜索过来的时候,也许会匹配到一个document的多个版本,但是之前的版本被标记为deleted了,所以只会返回最新版本的doc。
搜索的时候,会依次查询所有的segment,从旧的到新的,比如被修改过的document,在旧的segment中,会标记为deleted,在新的segment中会有其新的数据。
二 document写入流程--第二版
一中的流程是有问题的,每次都必须等待fsync将segment刷入磁盘,才能将segment打开供search使用,这样的话,从一个document写入,到它可以被搜索,可能会超过1分钟!!!这就不是近实时的搜索了!!!主要瓶颈在于fsync实际发生磁盘IO写数据进磁盘,是很耗时的。
写入流程改进如下:
(1)数据写入内存buffer缓冲中。
(2)每隔一定时间,buffer中的数据被写入segment文件,然后写入os cache。
(3)只要segment写入os cache,那就直接打开供search使用,不立即执行commit。
数据写入os cache,并被打开供搜索的过程,叫做refresh,默认是每隔1秒refresh一次。也就是说,每隔一秒就会将buffer中的数据写入一个新的index segment file,先写入os cache中。所以,es是近实时的,数据写入到可以被搜索,默认是1秒。
POST /my_index/_refresh,可以手动refresh,一般不需要手动执行,没必要,让es自己执行就可以了。
比如说,我们现在的时效性要求,比较低,只要求一条数据写入es,一分钟以后才让我们搜索到就可以了,那么就可以调整refresh interval
PUT /my_index
{
"settings": {
"refresh_interval": "30s"
}
}
三 document写入流程--第三版
二中的流程还可以进一步优化。
(1)数据写入buffer缓冲和translog日志文件。
(2)每隔一秒钟,buffer中的数据被写入新的segment file,并进入os cache,此时segment被打开并供search使用。
(3)buffer被清空。
(4)重复1~3,新的segment不断添加,buffer不断被清空,而translog中的数据不断累加。
(5)当translog长度达到一定程度的时候,commit操作发生。
(5.1)buffer中的所有数据写入一个新的segment,并写入os cache,打开供使用。
(5.2)buffer被清空。
(5.3)一个commit ponit被写入磁盘,标明了所有的index segment。
(5.4)filesystem cache中的所有index segment file缓存数据,被fsync强行刷到磁盘上。
(5.5)现有的translog被清空,创建一个新的translog。
基于translog和commit point,如何进行数据恢复?
fsync+清空translog,就是flush,默认每隔30分钟flush一次,或者当translog过大的时候,也会flush。
POST /my_index/_flush,一般来说别手动flush,让它自动执行就可以了。
translog,每隔5秒被fsync一次到磁盘上。在一次增删改操作之后,当fsync在primary shard和replica shard都成功之后,那次增删改操作才会成功。
但是这种在一次增删改时强行fsync translog可能会导致部分操作比较耗时,也可以允许部分数据丢失,设置异步fsync translog。
PUT /my_index/_settings
{
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}
四 document写入流程--最终版
三中的流程还可以再进行优化。
每秒一个segment file,文件过多,而且每次search都要搜索所有的segment,很耗时。
默认会在后台执行segment merge操作,在merge的时候,被标记为deleted的document也会被彻底物理删除。
每次merge操作的执行流程。
(1)选择一些有相似大小的segment,merge成一个大的segment。
(2)将新的segment flush到磁盘上去。
(3)写一个新的commit point,包括了新的segment,并且排除旧的那些segment。
(4)将新的segment打开供搜索。
(5)将旧的segment删除。
POST /my_index/_optimize?max_num_segments=1,尽量不要手动执行,让它自动默认执行就可以了。