ES千亿级搜索实战-架构优化

水的精神

已于 2023-11-08 17:27:23 修改

阅读量3.5k

点赞数 3

分类专栏： Elasticsearch ES搜索优化文章标签： elasticsearch 架构搜索引擎 es搜索优化

于 2022-09-27 23:44:27 首次发布

本文链接：https://blog.csdn.net/star1210644725/article/details/127080177

版权

Elasticsearch 同时被 2 个专栏收录

157 篇文章 50 订阅

订阅专栏

ES搜索优化

47 篇文章 15 订阅

订阅专栏

不管什么数据库，在应对千亿级别以上的数据的实时检索场景，都会有一定的压力。ES是搜索引擎，优秀的设计理念能够提速，但是也会表现的力不从心。往往会出现，集群随着数据越来愈多，而变得越来越慢的问题。

通常数据在来到10亿，对于命中两三亿结果集的时候，搜索时间都到了5秒以上。在百亿的搜索场景下，效果更差，可能在10秒以上。来到千亿级别，效果就更差了，可能来到了几十秒。

解密随着数据量变多，搜索速度变慢的原因

ES是天然的分布式搜索引擎。任何一个分布式的处理流程里边，其核心思想都是分治。将大问题，拆分小问题。但是也有逃不脱一个致命的问题，就是结果合并。越大的规模，合并的压力就越大，耗时就越大。

假如有一个es集群，100个数据节点，有一个索引一共有1000个分片。一次请求的检索这1000个分片都要参与。首先这里会遇到第一个问题，你能保证这1000个分片，能够平均分配在每个节点上吗？也就是每个节点上10个分片。假如不能，这是一个致命的问题，因为此时数据已经发生了倾斜，出现了严重的算力不平衡的问题。

第二个问题，你能保证在一次检索中，这1000个分片能够同是去执行吗？答案是不能！es默认一次检索在一个节点上执行的分片只能有5个分片在并行，也就是说，即使你的分片数均匀的，你仍然有两次串行的存在。这可能就要多花费一倍的时间。

即使你通过改参数突破了第二个问题，接着又面临第三个问题，第三个问题是，你的堆空间可能会很危险。假如你去执行了一个操作。from 0 size 1000 并且根据查询时间进行了排序，这个操作分给1000个分片去单独处理，最差的情况下，每个分片都要返回1000条数据，然后汇总在协调节点上，此时是1000 * 1000的数据量 1000000，这100W数据需要在协调节点再做一次排序。假如一条数据10K，那么就需要9个G的堆空间，数据暂存在堆中。默认情况下，协调节点和数据节点都是在一起的。一个请求就占用了9个G的堆空间，用来接数据，你的堆还能有多少空间？要不要GC？这里在大规模数据下，一定要把协调节点和数据节点分开！

所以怎么办呢？给集群做减法

此时面对这样的数据场景，想要有不错的搜索性能，就一定要有足够的机器资源。按照上边的例子。我扩一们可以倍的机器资源，来应对问题。但是100台机器的价格又是多少呢？

大规模检索，面临的最大的问题是，一次搜索参与的分片数太多。此时我们考虑的是如何减少分片数。

在没有条件扩一倍资源的时候，换个方向考虑，是不是可以想办法，去减少数据？资源不够的情况下，要琢磨每一点资源应该如何花的更充分。对数据做减法，将不用于检索的字段从原有的结构中拿出去；通过架构设计来减少数据，例如ES只做索引，不存储元数据。将数据存在可以利用key 快速取数据的库中。当然这种key value 的数据库不是redis，基于内存的，代价就更大了。更是花费不起的！必须是硬盘类型的库，好像也就只有HBase比较适合了。ES存储必须检索的字段，然后剩余的整个数据放在HBase里边。这一套会比较重，但是大规模数据下，是一个最有效的方案。

假如能从数据上减少50的数据。就约等于提升了一倍的机器资源！