document写入原理
1. 数据写入es中是首先写到内存buffer缓存中
2. 每隔一段时间执行commit point
3. 执行commit操作后,buffer中的数据写入新的index segment中
4. 等待在os cache中的index segment被fync强制刷到磁盘上
5. 新的index segement被打开,供search使用
6. buffer被清空
每次commit point时,会有一个.del文件,标记了哪些segment中的哪些document被标记为deleted了
搜索的时候,会依次查询所有的segment,从旧的到新的,比如被修改过的document,在旧的segment中,会标记为deleted
在新的segment中会有新的数据
现在流程的问题,每次都必须等待fsync将segment刷入磁盘,才能将segement打开供search使用,这样的话,从一个document写入,到
它可以被搜索,可能会超过1分钟!!这就不是近实时的搜索了!!!!!主要瓶颈在于fsync实际发生磁盘ID写数据进磁盘,是很耗时
的。
写入流程改进如下:
1. 数据写入buffer
2. buffer满后,buffer的数据被写入segment文件,但是先写入os cache
3. 只要segment写入os cache,那就直接打开供search使用,不立即执行commit
数据写入os cache,并被打开供搜索的过程,叫做refresh,默认是每隔1秒refresh一次,也就是说,每隔一秒就会将buffer中的数据写
入一个新的index segment file,先写入os cache中。所以,es是近实时的,数据写入到可以被搜索默认是1s
POST /myindex/_refresh可以手动refresh
如果我们要求的时效性比较低,只要求一条数据写入es,一分钟以后才让我们搜索就可以了,那么就可以调整refresh interval
PUT /myindex
{
"settings":{
"refresh_interval":"30s"
}
}
再次优化写入流程
1. 数据写入buffer缓存和translog日志文件
2. 每隔一秒种,buffer中的数据被写入新的segment file,并写入os cache,此时segment被打开并供search使用
3. buffer被清空
4. 重复1-3,新的segment不断添加,buffer不断被清空,而translog中的数据不断累加
5. 当translog长度达到一定程度的时候,commit操作发生
1. buffer中的所有数据写入一个新的segment,并写入 os cache,打开供使用
2. buffer被清空
3. 一个commit point被写入磁盘,标明了所有的index segment
4. filesystem cache中所有index segment file缓存数据,被fsync强行刷到磁盘上
5. 现有的translog被清空,创建一个新的translog
基于translog和commit point,如何进行数据恢复
机器被重启,disk上的数据并没有丢失,此时就会将translog文件中的变更记录进行回访,重新执行之前的各种操作,在buffer中
执行,再重新刷一个一个的segment到os cache中,等待下一次commit发生即可
fsync+清空translog,就是flush,默认每隔30分钟flush一次,或者当translog过大的时候,也会flush
translog,每隔5s被fsync一次到磁盘上,在一次增删改操作后,当fsync在primary shard和replica shard都成功之后,那么增删
该操作才会成功
但是这种在一次增删改时强行fsync translog可能会导致部分操作比较耗时,也可以允许部分数据丢失,设置成异步fsync translog
PUT /index/_settings
{
"index.translog.durability":"async",
"index.translog.sync_interval":"5s"
}
每秒一个segment file,文件过多,而却每次search都要搜索所有的segment,很耗时,默认会在后台执行segment merge操作,在merge
的时候,被标记为deleted的document也会被彻底物理删除,每次merge操作执行流程
1. 选择一些有相似大小的segment,merge成一个大的segment
2. 将新的segment flush到磁盘上
3. 写一个新的segment flush到磁盘上去
4. 将新的segment打开供搜索
5. 将旧的segment删除