es查询性能优化

1. filesystem cache

2. 数据预热

3. 冷热分离

4. document 模型设计

5. 分页性能优化

一、filesystem cache

往 es 里写的数据，实际上都写到磁盘文件里去了，**查询的时候**，操做系统会将磁盘文件里的数据自动缓存到 `filesystem cache` 里面去

es 的搜索引擎严重依赖于底层的 `filesystem cache`，你若是给 `filesystem cache` 更多的内存，尽可能让内存能够容纳全部的 `idx segment file ` 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会很是高。

归根结底，要让 es 性能要好，最佳的状况下，就是你的机器的内存，至少能够容纳你的总数据量的一半。

好比说如今有一行数据。`id,name,age ....` 30 个字段。可是如今搜索，只须要根据 `id,name,age` 三个字段来搜索。仅仅写入 es 中要用来检索的**少数几个字段**就能够了，好比说就写入 es `id,name,age` 三个字段，而后你能够把其余的字段数据存在 mysql/hbase 里，通常是建议用 `es + hbase` 这么一个架构。

hbase 的特色是**适用于海量数据的在线存储**，就是对 hbase 能够写入海量数据，可是不要作复杂的搜索，作很简单的一些根据 id 或者范围进行查询的这么一个操做就能够了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 `doc id`，而后根据 `doc id` 到 hbase 里去查询每一个 `doc id` 对应的**完整的数据**，给查出来，再返回给前端。

写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。而后你从 es 检索可能就花费 20ms，而后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms

 

二、数据预热

假如说，哪怕是你就按照上述的方案去作了，es 集群中每一个机器写入的数据量仍是超过了 `filesystem cache` 一倍，好比说你写入一台机器 60G 数据，结果 `filesystem cache` 就 30G，仍是有 30G 数据留在了磁盘上。

其实能够作**数据预热**。

能够将平时查看最多的一些商品，好比说 iphone 8，热数据提早后台搞个程序，每隔 1 分钟本身主动访问一次，刷到 `filesystem cache` 里去。

对于那些你以为比较热的、常常会有人访问的数据，最好**作一个专门的缓存预热子系统**，就是对热数据每隔一段时间，就提早访问一下，让数据进入 `filesystem cache` 里面去。这样下次别人访问的时候，性能必定会好不少。

 

冷热分离