大数据查询方案

发布时间：2023-12-22 16:23:02 所属栏目：大数据来源：DaWei

导读： 文章目录

背景

在一些业务场景中，一开始业务量并不大，可见性的几年内不会突破非常大的数量，所以一开始设计方案的时候就没有考虑分库分表的实现方案，杀鸡焉用牛刀。

随着业务的

文章目录

背景

在一些业务场景中，一开始业务量并不大，可见性的几年内不会突破非常大的数量，所以一开始设计方案的时候就没有考虑分库分表的实现方案，杀鸡焉用牛刀。

随着业务的不断增长，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的数据么？可以参考文章，总结的非常详细：

总结

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

关于切换方案后如何保证业务平稳过度，及时发现问题，可以参考我以前的文章：

系统迁移必知会（多年总结）

无论是系统迁移还是部分业务的迁移原理都类似，可以借鉴。

（编辑：鄂州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!