课件地址

分片对于ES而言相当关键，她是ES真正存储数据的地方，她是ES实现天然水平扩展的基础，她是保证ES高可用高性能的基石。 分片的本质是啥呢？一个ES分片本质上就是一个Lucene Index，那Lucene Index的本质又是什么呢？Lucene Index 的本质是一个倒排索引的存储结构，那倒排索引是啥呢？倒排索引是索引的一种，是相对于正排索引来命名的，索引的存在就是加快查询的速度，倒排索引通过分词和文档ID的关系来加快文档的查询速度。那索引中包括文档的所有内容嘛？这个一直是我的疑惑，如果包含，那这个索引就太重了，如果不包含，那拿到文档ID后还需要再找一次文档的内容，希望老师能回答一下！ 最后Lucene Index 对应的倒排索引不是一直固定唯一的，她是有许多的小的倒排索引合并后才形成的一个唯一的倒排索引。小的倒排索引在Lucene中叫做Segment，单个的Segment倒排索引文件是自包含的，不可变的。当有新文档写入时，并且执行了Refresh，就会生产一个新的Segment倒排索引文件。在Lucene中有一个文件，用来记录所有Segment倒排索引文件的信息，这个文件叫做Commmit Point。 在查询时会查询所有Segment倒排索引文件，并对结果汇总。 当删除文件信息时会保存在.del文件之中，查询后进行过滤，所以，被删除的文件并没有立刻被删除，只是记录到一个文件之中了，这是为什么删除ES文档时为什么磁盘空间不降反升的原因。 Segment倒排索引文件会定期合并，最终合并成为一个Segment倒排索引文件，同时也会真正的清除已删除的文件。此时才会真正的释放出来被删除的文档所占用的磁盘空间。 至此分片和倒排索引都联系起来了，不过还是那个疑惑没解开，倒排索引中是否包括所有的文档内容？ 我猜测不包含，通过倒排索引只是拿到了查询的分词和文档ID的关系，还需要根据文档ID获取文档的内容。否则这个倒排索引多重呀！当然，文档ID是文档的唯一标识，拿到文档ID其实等于拿到了文档的内容。

老师，请问4个5G的segment，和一个20G的segment，20G的是否会降低搜索速度，因为4个5G的可以4个一起搜？？

这光头读ppt，不多介绍有点伤啊

手动 force merge 超时，你们有这个问题么？

Force Merge 为什么会占用大量的网络资源？

“Index.merge.policy.segments_per_tier，默认为 10， 越小需要越多的合并操作”。应该是数值越大，越多合并操作？