Elasticsearch1.lucenne基本概念-CSDN博客

本文介绍了Elasticsearch中Lucene的数据写入流程，包括数据同时写入index buffer和translog，每隔一定时间buffer内容被写入新的segment。接着详细阐述了commit(flush)操作，当translog达到一定大小时，数据被写入新segment并更新commit point。还讨论了Lucene的数据恢复过程，依赖translog和commit point进行数据恢复。最后，讨论了segment合并的必要性和具体步骤，以优化查询效率。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

数据写入流程

1.数据同时写入indexbuffer缓冲和translog日志文件
2.默认每隔一秒钟，buffer中的数据被写入新的segmentfile，并进入os cache，此时segment被打开并供search使用
3.buffer被清空
4.重复1~3的步骤，新的segment不断添加，buffer不断被清空，而translog中的数据不断累加

commit(flush)操作

当translog文件达到一定的阀值(默认512M)，commit操作发生
1.buffer中的所有数据写入一个新的segment，并写入os cache，打开供使用
2.buffer被清空
3.一个commitponit被写入磁盘，标明了所有写入的indexsegment
4.oscache中的所有indexsegment缓存数据，被fsync强行刷到磁盘上
5.现有的translog被清空，创建一个新的translog

lunce的数据恢复

基于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"
}

Segment合并

在这里插入图片描述
每秒产生一个segment，那么就会产生很多的segment，而查询需要扫描所有的segment，那么就会很耗时
默认会在后台执行segment，merge操作，在merge的时候，被标记为deleted的document也会被彻底物理删除
合并流程
1.选择一些有相似大小的segment，merge成一个大的segment
2.将新的segmentflush到磁盘上去
3.写一个新的commit point，包括了新的segment，并且排除旧的那些segment
4.将新的segment打开供搜索
5.将旧的segment删除