【ElasticSearch】——架构初识（1）

背景

现在需要针对大量的数据进行搜索，比如对生产上的日志进行查询，对于这种大数据量的，一般都是需要用到分布式搜索，而ElasticSearch是一个比较好的选择。

一、概念

ElasticSearch就是分布式搜索引擎，底层就是基于lucene，核心思想就是在多台机器上启动多个es进程实例，组成一个es集群。es中存储的基本单位是索引，一个索引就是对应mysql中的一张表，type代表一种类型（其实就是索引下的一个逻辑分类），mapping代表表结构，document代表表中的一条数据（是以json数据格式存储的），field代表表中的字段

index -> type -> mapping -> document -> field。

正常的我们为了支持高可用性，高并发，会将一个索引拆分成多个shard，每个shard存储部分数据，这样做的好处就是很好得支持横向扩展，另外这样将数据分布在多台服务器上，提高了吞吐量和性能。每个shard都是会有多个备份，每个shard都有一个primary shard（建立索引时一次设置，不能修改，默认 5 个）负责写入然后同步到其他几个replica shard（随时修改数量，默认 1 个）中。对于master节点的选举跟zookeeper选举一样，这里就不多说了。

二、实战

记得我们公司的一个基于ElasticSearch做的一个日志搜索工具，每次第一次的时候都是需要好几秒才能加载出来，甚至有的时候更长的时间，但是第二次的时候就会快很多，这是因为filesystem cache的原因，其实就是缓存，所以我们思想是不是就是尽量加大我们的缓存，将尽量多的数据放在缓存中，一般缓存中空间占到我们数据的50%就是一个比较好的状态，但是内存的资源毕竟是有限的，随着数据量的增加，我们能够缓存的数据比例就会下降，如果我们将非关键数据或者冷数据放在缓存中也是一种浪费资源的情况。

es+hbase：hbase适用于海量数据的在线存储，但是不要做复杂的搜索，只做一些简单的根据id查询就行，es中只存储id和一些搜索条件就行，这样我们在查询的时候只是需要根据查询条件到es中找到对应的id集合，然后到hbase中的根据id集合查询出对应的数据返回给前端。

数据预热：加入上面的方式还是导致了每个机器的写入量超过了filesystem cache的一倍，我们就是可以在自己的后台中的没隔一定时间就去搜索一下热数据，刷新到filesystem cache中，这样每次用户取的数据都是从缓存中去拿的，速度一定快了。

冷热分离：es可以做mysql的水平拆分，可以将访问少的数据单独放在一个索引中，将访问频繁的数据放在另外一个索引中，这样可以确保热数据在预热之后不会被冷数据冲刷掉

document模型设计：es里面避免使用关联等复杂查询，影响效率，可以在写入的时候将关联的数据写入，这样查询的时候就不用去关联查询数据。

分页性能优化：es的分页是比较坑的，因为是分布式的，每一个索引都是会拆分成多个shard，每个shard保存一部分的数据，这样我们在分页时候是要查询所有的shard的数据，然后在处理，比如5个shard，查询第100页的10条数据，他会从每个shard中查询前1000条数据，总共就是5000条数据，然后再次分页拿到第100的数据，所以按照这样的原理我们的分页越到后面花费的时间越长。

不允许深度分页：遇到上面的问题我们应该怎么来解决这个问题呢，看看现在的微博或者是其他的软件都是一页一页的刷新的，都是不允许直接跳页的，这样的就能够避免上面的情况，我们在每刷新一页的时候都是会异步缓存他的下一页的数据（search_after），这样我们在下滑的时候就非常的快了，但是初始化时必须指定 scroll 参数，告诉 es 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。