听课笔记（67讲—70讲）

第67讲

倒排索引是不可变的，所以就不需要锁。

第68讲

 数据——>buffer——>index segment——>os cache(commit)——>os disk

在这时候，buffer会被清空，同时web端可以搜索到刚才插入的数据了。

以上是的插入的过程：

如果是删除的时候，每次commit的时候，文件就会标记为.del，再次搜索过来的时候，看到segment中的数据是.del状态，就不会被查询到了。

更新的原理：实际上是将现有的文件标记为.del的形式，然后将新的document文件写入到新的index segment中，下次search过来查询的时候，也许会匹配到segment上的多个版本，但是之前标记的文件就不会被返回了。

第69讲

以上写数据的过程就不是实时的了，肯定是有问题的。。。

其实实际上是讲数据一被写到OS cache中，来不及写往os disk中去，就接受web端search了。

在hive中有fs image是存放metadata的元数据的。

在这个里边落地磁盘的时候也有一个refresh，默认是1s。

在这里落地磁盘的时候，有一个fresh，跟MapReduce是一样的。不同的是：这里可以指定落地磁盘的时间，有两种设定的方式：

①手动设定的方式：post /my_index/_refresh:（这种设定默认的时间是1s）

②机器设定：

put /my_index

{

"setting":{

"refresh_interval":"30s"

}

}

第70讲

在写数据的时候，在将数据写入内存buffer缓冲的同时，还将数据写入日志文件translog中，随着时间的推移，translog文件就会变大，当达到一定程度就会触发flush，溢写OS cache，同时buffer就会被清空。

首先数据来了之后写入buffer缓冲区，同时写入translog中，等隔1s会写入到segment file，这里每次写入的segment file是不相同的。当translog中的数据集聚到一定程度的时候，就会触发segment file写入数据到OS cache中，数据写入OS cache的时候web端search就可以看到了，同时buffer缓冲区中的数据会被清空。

translog中的文件达到一定程度的时候会触发flush，触发commit操作，这个操作执行的是数据从内存缓冲buffer缓冲区到segment file之间的操作。写一个commit point到磁盘上去，表明有哪些index segment

OS cache上的数据是强行通过fsync刷新到OS disk磁盘上去的。接着把现有的translog文件清空，这就完成了数据的持久化操作。

当机器重启了的时候，或者当OS cache挂机了的时候，OS cache上的数据全部丢失，此时可以通过translog里边存储的上一次refresh之后的数据记录，然后进行恢复。

 增删改操作也会触发translog去执行。