背景

在一些业务场景中，一开始业务量并不大，可见性的几年内不会突破非常大的数量，所以一开始设计方案的时候就没有考虑分库分表的实现方案，杀鸡焉用牛刀。
随着业务的不断增长，DB中的数据也会不断的增长，单表数据量很快就突破的到了几千万上亿级别了，此时查询性能会开始下降，特别是范围查询的时候db耗时会越来越长，此时性能已经不能满足正常业务活动了，于是优化就开始了。
之前遇到的场景是在某个业务A下，用户会不断的产生交易数据，数据存在交易数据表中，C端用户查询的时候使用这里的数据进行展示，B端商户查询店铺下的交易数据的时候也是使用相同的交易数据表，随着整体数据增加，单表已经超过1亿，单个商户当日数据也存在超过百万的场景。在业务活动中，插入数据的性能还是比较稳定的，虽然单表超过了1亿的数据，但是每条数据量小，插入和主键查询性能还不是瓶颈，更多的是要解决查询的性能问题。

解决方案

方案1：分库分表+搜索能力

面对逐渐增加的数据，分库分表是肯定可以解决的，但是整体改造的成本是非常大的，从写入到查询方案都得修改，特别的是在一些C端和B端的数据没有分离的场景，更是困难。B端通常都是批量查询或者有各种排序诉求的。于是这种场景下又得对B和C端数据剥离，对于B端场景还得引入搜索引擎来满足查询功能。

方案2：分区+搜索能力

分区

mysql支持分区能力，可以通过id或者店铺id维度进行分区，将数据打散到不同的分区表中，随着业务发展速度，近几年内都可以满足业务诉求。

搜索

本次核心还是要解决搜索的性能问题，B端查询通常有两个场景，一个是列表也的查询，这种场景下每页数据基本在50条内，但是可能会有各种排序条件。另一个是导出场景，主要是满足商户对账或者数据分析的场景下使用，商户会将指定时间内的数据导出。查询的性能会直接影响商户的正常业务活动。
搜索引擎的话目前常用的是ES和solr，根据使用的场景和公司的技术栈来选择，这里选择的是ES。

整体方案

DTS：数据传输服务，这里可以看阿里云提供的服务，或者可以自建同步能力，可用通过cannal+自建的数据处理服务来将rds数据实时同步到ES上。

DTS乱序： DTS通过消息中间件传输数据，万一乱序了会导致新的数据被历史数据覆盖，可以通过顺序消息或者ES的版本号控制能力来保证最新的数据。当然这里是推荐使用ES的版本控制能力。

回表：ES这里定位的是搜索能力提供，这里只存可能需要搜索和排序的字段，ES查询出id后需要通过id回表rds查询实时数据，补全数据。还有是B端数据操作后需要实时展示出来的，ES会存在延迟数据不回流查询的话没法获取到最新的数据，对B端操作是很不友好的

离线数据处理: DTS这里可以解决增量的数据，等到增量数据开启同步验证完成后，历史数据需要同步到ES中，同步的时候注意下ES已经存在的数据的话这条离线数据就可以丢弃了，因为DTS已经同步到了最新的数据了。

单表上限问题：当看到单表超过1亿时，不要惊讶，各种业务场景总是有机会见到的，为啥超过2000w还能正常使用？不是都推荐单表在500w的数据么？可以参考文章，总结的非常详细：https://mp.weixin.qq.com/s/XX_NkIIf_PLyU4IE6lEEYQ

总结

方案选型的时候要根据业务的实际场景来选择的，评估下未来1-3年的发展情况，结合当前业务的紧急程度，持续优化逐步往目标方案上靠近，最合适当前阶段的架构方案就是最好的方案。

关于切换方案后如何保证业务平稳过度，及时发现问题，可以参考我以前的文章：
系统迁移必知会（多年总结）
无论是系统迁移还是部分业务的迁移原理都类似，可以借鉴。

B端大数据量查询优化方案相关推荐

Oracle 大数据量查询优化
前言:平常写的SQL可能主要以实现查询出结果为主,但如果数据量一大,就会突出SQL查询语句优化的性能独特之处.一般的数据库设计都会建索引查询,这样较全盘扫描查询的确快了不少.下面总结下SQL查询语句的 ...
SQL千万级大数据量查询优化
转发自:https://blog.csdn.net/long690276759/article/details/79571421?spm=1001.2014.3001.5506* (防止查询资料找不到 ...
oracle大数据量删除方案
oracle进行大数据量删除的时候,容易报错表temp表空间空间不够导致删除失败,此时的处理方案有: 方案一: 分批删除,提交之后继续执行方案二: 当剩下的数据量小于待删除的数据量时,可以使用转表的 ...
Mysql千万级大数据量查询优化
1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引. 2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索 ...
Mysql大数据量查询优化的思路
项目场景: Mysql大表查询优化,理论上千万级别以下的数据量Mysql单表查询性能处理都是可以的. 问题描述: 在我们线上环境中,出现了mysql几千万级别的日志查询.几百万级别的黑名单库查询分页查 ...
优化大数据量查询方案——SpringBoot（Cloud）整合ES
一.Elasticsearch简介实际业务场景中,多端的查询功能都有很大的优化空间.常见的处理方式有:建索引.建物化视图简化查询逻辑.DB层之上建立缓存.分页-然而随着业务数据量的不断增多,总有那么 ...
mysql大数据量迁移方案
使用navicat等客户端软件功能进行同步使用mysqldump进行导出导入同步使用mysq命令的into file,load file进行同步命令数据量不大可以用navicat,mysqldu ...
Sqlite大数据量查询优化比较-转
标题写的有些大了-- 我做的一个PHP玩具用的是Sqlite数据库,昨天某网站采集了4039篇文章,发现页面打开速度慢的要死,看了一下耗时,发现sqlite在数据量比较大(4000算大?--我觉得挺大 ...
G6展示网络拓扑图，适配大数据量的方案
接手之初,整体样式: 但当数据量变大时,渲染速度慢,且容易卡死浏览器,导致崩溃.大概支持500个节点. 通过浏览器performance工具分析得知,是由于comboForce(分组力导布局)算法冗余 ...

B端大数据量查询优化方案

文章目录

背景

解决方案

方案1：分库分表+搜索能力

方案2：分区+搜索能力

分区

搜索

整体方案

总结

B端大数据量查询优化方案相关推荐

最新文章

热门文章