数据查询优化技术方案

数据查询优化技术方案

更多运维进阶知识请看： https://edu./course/30254.html https://edu./course/31241.html

1、需求说明

背景 线索模块作为我们的核心服务模块(crm-service),经常饱受慢查询的困扰,用户体验不好,急需优化。

导致慢查询的原因

业务复杂,查询条件多种多样数据量大,customer_extension数据量为47809164(6.28号查询)关联查询多,实际业务中除了customer_extension主表的数据外,还需要查询customer_extension_extra,follow_status,flow_partner_relation,lock_customer,customer_extension_common等从表信息 实际通过sql优化效果有限,所以考虑引进搜索引擎来解决问题

2、为什么不用分库分表？

查询条件多种多样 索引不能兼顾到所有场景 模糊查询场景多 关联查询多只能根据companyId进行分库分表 各个企业数据体量不一致 会有数据倾斜

3、技术选型

1）Elasticsearch是什么

Elaticsearch简称为ES,是一个开源的可扩展的分布式的全文检索引擎，它可以近乎实时的存储、检索数据。本身扩展性很好，可扩展到上百台服务器，处理PB级别的数据。ES使用Java开发并使用Lucene作为其核心来实现索引和搜索的功能，但是它通过简单的RestfulAPI和javaAPI来隐藏Lucene的复杂性，从而让全文搜索变得简单。

2）Elasticsearch的功能

分布式的搜索引擎 分布式：Elasticsearch自动将海量数据分散到多台服务器上去存储和检索 搜索：百度、谷歌，站内搜索全文检索 提供模糊搜索等自动度很高的查询方式，并进行相关性排名，高亮等功能数据分析引擎（分组聚合） 电商网站，最近一周笔记本电脑这种商品销量排名top10的商家有哪些？新闻网站，最近1个月访问量排名top3的新闻板块是哪些对海量数据进行近实时的处理 海量数据的处理：因为是分布式架构，Elasticsearch可以采用大量的服务器去存储和检索数据，自然而然就可以实现海量数据的处理 近实时：Elasticsearch可以实现秒级别的数据搜索和分析

3）Elasticsearch的特点

Elasticsearch的特点是它提供了一个极速的搜索体验。这源于它的高速（speed）。相比较其它的一些大数据引擎，Elasticsearch可以实现秒级的搜索，速度非常有优势。Elasticsearch的cluster是一种分布式的部署，极易扩展(scale )这样很容易使它处理PB级的数据库容量。最重要的是Elasticsearch是它搜索的结果可以按照分数进行排序，它能提供我们最相关的搜索结果（relevance) 。

安装方便：没有其他依赖，-后安装非常方便；只用修改几个参数就可以搭建起来一个集群JSON：输入/输出格式为 JSON，意味着不需要定义 Schema，快捷方便RESTful：基本所有操作 ( 索引、查询、甚至是配置 ) 都可以通过 HTTP 接口进行分布式：节点对外表现对等（每个节点都可以用来做入口） 加入节点自动负载均衡多租户：可根据不同的用途分索引，可以同时操作多个索引支持超大数据： 可以扩展到 PB 级的结构化和非结构化数据 海量数据的近实时处理

4）Elasticsearch企业使用场景

常见场景

搜索类场景 比如说电商网站、招聘网站、新闻资讯类网站、各种app内的搜索。日志分析类场景 经典的ELK组合（Elasticsearch/Logstash/Kibana），可以完成日志收集，日志存储，日志分析查询界面基本功能，目前该方案的实现很普及，大部分企业日志分析系统使用了该方案。数据预警平台及数据分析场景 例如电商价格预警，在支持的电商平台设置价格预警，当优惠的价格低于某个值时，触发通知消息，通知用户购买。 数据分析常见的比如分析电商平台销售量top 10的品牌，分析博客系统、头条网站top 10关注度、评论数、访问量的内容等等。商业BI(Business Intelligence)系统 比如大型零售超市，需要分析上一季度用户消费金额，年龄段，每天各时间段到店人数分布等信息，输出相应的报表数据，并预测下一季度的热卖商品，根据年龄段定向推荐适宜产品。Elasticsearch执行数据分析和挖掘，Kibana做数据可视化。

5）常见案例

维基百科、百度百科：有全文检索、高亮、搜索推荐功能stack overflow：有全文检索，可以根据报错关键信息，去搜索解决方法。github：从上千亿行代码中搜索你想要的关键代码和项目。日志分析系统：各企业内部搭建的ELK平台。

6）主流全文搜索方案对比

Lucene、Solr、Elasticsearch是目前主流的全文搜索方案，基于倒排索引机制完成快速全文搜索。

7） 三者之间的区别和联系

Solr和Elasticsearch都是基于Lucene实现的。但Solr和Elasticsearch之间也是有区别的 1）Solr利用Zookpper进行分布式管理，而Elasticsearch自身带有分布式协调管理功能 2）Solr比Elasticsearch实现更加全面，Solr官方提供的功能更多，而Elasticsearch本身更注重于核心功能， 高级功能多由第三方插件提供 3）Solr在传统的搜索应用中表现好于Elasticsearch，而Elasticsearch在实时搜索应用方面比Solr表现好

在日志系统中,我们使用的是Elasticsearch,积累了一定的经验

4、方案概述

通过把customer_extension_extra,follow_status,flow_partner_relation,lock_customer, customer_extension_common等表组成一张宽表存储在Elasticsearch一个索引上 整体架构

架构1

无法复制加载中的内容 优点:实现简单 缺点:

上报的内容可能会丢失,导致es和mysql两边数据可能不一致与业务强关联,随着业务的改变修改上报埋点

架构2

无法复制加载中的内容 设置定时任务logstash根据修改时间定时去mysql拉取数据进行同步 优点:

实现简单与业务弱关联 缺点:非订阅模式,定时任务设置太长,数据一致性弱化,定时任务设置太短,导致cpu空转,浪费资源查看错误日志不方便

架构3

canal官方地址：​​server实现流程如下：

canal server 要启动某个 canal instance 时都先向 zookeeper 进行一次尝试启动判断 (实现：创建 EPHEMERAL 节点，谁创建成功就允许谁启动）；创建 zookeeper 节点成功后，对应的 canal server 就启动对应的 canal instance，没有创建成功的 canal instance 就会处于 standby 状态；一旦 zookeeper 发现 canal server A 创建的节点消失后，立即通知其他的 canal server 再次进行步骤1的操作，重新选出一个 canal server 启动instance；canal client 每次进行connect时，会首先向 zookeeper 询问当前是谁启动了canal instance，然后和其建立链接，一旦链接不可用，会重新尝试connect。

PS: 为了减少对mysql dump的请求，不同server上的instance要求同一时间只能有一个处于running，其他的处于standby状态。

canal client实现流程

canal client 的方式和 canal server 方式类似，也是利用 zookeeper 的抢占EPHEMERAL 节点的方式进行控制为了保证有序性，一份 instance 同一时间只能由一个 canal client 进行get/ack/rollback操作，否则客户端接收无法保证有序。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。