大流量下的 ElasticSearch 搜索演进
这是泥瓦匠(bysocket.com)的第27篇精华分享
ES (ElasticSearch)是分布式搜索引擎。引擎太晦涩,其实类似一个 MySQL ,一个存储。方便提供下面功能:
- 近实时搜索
- 全文检索,结构化搜索,统计分析
那么存储在 ES 数据哪里来?
答案是数据同步。方式推荐如下:
数据传输(Data Transmission)是阿里云提供的一种支持RDBMS(关系型数据库)、NoSQL、OLAP等多种数据源之间数据交互的数据服务。【阿里的】
https://help.aliyun.com/product/26590.html有赞亿级订单同步的探索与实践【小弟我呆的小组搞的】
https://mp.weixin.qq.com/s/33KACMxXkgzZyIL9m6q4YA
回归到 ES 演进
一、小流量阶段
当时在创业公司,同步每次都是全量的,然后凌晨任务跑一下即可。或者直接同步往 ES CRUD 数据。
单机伪集群,也可以跑。具体全文检索思路:
- 基于「短语匹配」并设置最小匹配权重值
- 哪来的短语,利用 IK 分词器分词
- 基于 Fiter 实现筛选
- 基于 Pageable 实现分页排序
具体看我系列 ES 博客和 GitHub。
二、流量慢慢大了
这个量级预估是 百万 / 千万数据同步和查询。
就不能单机伪集群了,运维层面能解决这个量:
- 多个 ElasticSearch 运行实例(节点 Node)的组合体是 ElasticSearch 集群
- 通过水平扩容为集群添加更多节点
如何水平扩容
主分片在索引创建已经确定。读操作可以同时被主分片和副分片处理。因此,更多的分片,会拥有更高的吞吐量。自然,需要增加更多的硬件资源支持吞吐量。说明,这里无法提高性能,因为每个分片获得的资源会变少。动态调整副本分片数,按需伸缩集群,比如把副本数默认值为 1 增加到 2:
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
基本一个集群 Cluster 含着各个业务搜搜:订单、商品等
三、突然订单流量暴增了
突然发现一个问题:
- A 集群里面的大索引慢查会影响 A 集群的其他小索引。
比如现在同一个 订单 索引大了,慢查。影响了其他业务。那不应该呀,咋办?
答案是:物理隔离为多集群:
- 分为很多集群:集群订单、集群商品等隔离
- 多机房支持
往往这时候问题由来了:业务单点如何优化升级?
一个索引 project , 存储项目相关的数据。项目的数量级越来越大,亿量级,万亿量级。那一个大索引的查询啥的都会出现瓶颈。这时候该怎么优化呢?
解决方案:冷热分离;拆分
大索引的拆分,也不是很难。类似分片的路由规则,根据具体业务指定即可。
这里,我们可以定义 1000 个索引,分别名为 project_1、project_2、project_3…
然后在 ES 集群上面架一层简单的 proxy 。里面核心的业务路由规则可以这样:
project_id 项目自增 ID
index_id 得出来的索引对应的 ID
index_id = project_id % 1000
- ES proxy 层:做总索引和真正分索引的映射
- ES 索引配置管理:做索引与业务的映射
- ES 集群
冷热分离;也是类似的就是中间状态的数据最热独立集群独立索引。定期从里面删除终态数据。那么这个索引数据量少,支持搜搜查询量贼大。何乐而不为。
- 完 –
相关文章