es

1. 十亿级数据ES搜索怎么优化?

es 的搜索引擎严重依赖于底层的 filesystem cache，你如果给 filesystem cache 更多的内存，尽量让内存可以容纳所有的 idx segment file 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高

• 存尽量少字段 ，可以采用es+hbase
• 数据预热，程序定时刷新数据到 filesystem cache
• 冷热分离 ， 冷热数据单独建立索引，避免冷数据刷掉热数据的filesystem cache
• 直接写入计算好数据，避免join操作
• 分页性能优化

​ es 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 shard 上存储的前 1000 条数据都查到一个协调节点上，如果你有个 5 个 shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。

2. 在数据量很大的情况下，怎么实现深度分页？

3. es 读写数据过程 和检索过程

1. 写

• 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
• coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
• 实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
• coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

2. 读

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。

• 客户端发送请求到任意一个 node，成为 coordinate node。
• coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
• 接收请求的 node 返回 document 给 coordinate node。
• coordinate node 返回 document 给客户端。

3.检索

客户端发送请求到一个 coordinate node。

协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard，都可以。

query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。

fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

​