索引分片

索引分片-水平扩展：

索引分片-水平扩展

索引分片-应对故障：

索引分片-应对故障

数据路由

路由策略：

1、 路由公式：shard = hash(routing) % number_of_primary_shards
2、 默认的routing值是_id,也可以手工指定
3、 确定好主分片的数量后，永远不会改变

路由策略

查询与写入过程

索引写入过程 索引查询过程 索引查询取回过程 索引查询过程-多文档获取 索引写入过程-多文档bulk

索引原理

1、 动态更新索引，不修改已经生成好的倒排索引，而是新生成一个段（segment）
2、 每一个段（segment）都是一个倒排索引
3、 ES另外使用一个commit文件，记录索引内所有的segment
4、 生成segment的数据是在内存的buffer中

索引原理 索引原理 索引原理

准实时查询原理

1、segment刷新到文件系统缓存
2、refresh_interval默认1s间隔，可以手动设置

PUT /my_index/_settings
{
    "index" : {
        "refresh_interval" : "30s"
    }
}

3、主动调用/_refresh接口刷到缓存

POST /_refresh
POST /blogs/_refresh

4、可以使用 "refresh_interval":"-1" 禁用刷新

准实时查询原理

事务日志

事务日志 事务日志 事务日志 事务日志

1、lunce的commit操作非常昂贵，segment从文件系统缓存刷新到磁盘，更新commit
2、translog记录发生在索引上的各种操作
3、每个不同的shard都有自己的事务日志
4、默认5秒进行一次fsync（index.translog.sync_interval）
5、默认512MB进行一次Flush（index.translog.flush_threshold_size）
6、主动调用/_flush接口
7、异步translog

PUT /my_index/_settings
{
    "index.translog.durability": "async",
    "index.translog.syunc_interval": "5s"
}

段合并

段合并过程：

1. 过多的segment会影响数据读取的性能，占用文件句柄和内存资源
2. 专门的merge线程池负责
3. 手工调用接口
   1. 新版本_forcemerge接口
   2. 老版本_optimize接口
   3. POST /my_index/_forcemerge?max_num_segments=1

段合并过程 段合并过程

段合并配置
合并线程数量：

1. index.merge.scheduler.max_thread_count
2. 默认值：Math.min(3, Runtime.getRuntime().availableProcessors() / 2)

合并线程的限速配置：

1. 5.0之前indices.store.throttle.max_bytes_per_sec=20mb
2. 5.0之后不要配置，使用了Lucene的CMS(ConcurrentMergeScheduler)的auto throttle机制

merge默认最大segment为5GB，最多同时合并10个段
forcemerge有单独的一个线程运行

索引删除与更新

在删除或更新时：

1. 段（segment）是不可以改变的，不能把旧文档从段中删除，也不能修改段中的文档；
2. 每个提交点包含一个.del文件，旧文档设置删除标记；
3. 更新的文档写入当前开启的段；
4. 此时查询，内部会将这个旧文档匹配到，但在最终结果返回时会过滤掉；
5. 在后台段合并时，文档才会正在删除。

索引原理总体图