主要知识点
- 优化写入流程实现近实时
- 优化写入流程实现持久化和数据恢复
- 优化写入流程实现海量磁盘文件合并
一、优化写入流程实现近实时
在第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，