mysql数十亿_[案例]如何异构一个数十亿级别的数据库

数据源为mysql，目标介质为elasticsearch。

1、 我们能利用的资源

1.1 源数据模型

源库是别人(库存)的数据，分为A,B,C三种类型的库存模型，需要将三种类型的模型整合成一中通用库存模型方便我方(商家)做业务。

典型的互联网企业是协作方式，通过数据副本实现业务之间的解耦。

1.2 特殊表(非重点)

D为库存占用订单详情，也要异构一份。

1.3 分库分表

ABCD均做了分库分表，A(16个库，4096张表),B(1,512),C(1,256),D(8,1024)

1.4 数据量

数据总量在数十亿级别

1.5 线上影响

不影响对方业务，数据源只有对方mysql分组中对应的抽数从库。

1.6 性能要求

未来要支持复杂的条件查询，对查性能有很高要求，目标介质是ES。

2、 难点

2.1 导数

交易库存复杂的分片规则，数据量大，导数是个大工程。

2.2 更新频繁

写操作频繁，ES 创建索引的tps能否满足要求。

2.3 一致性如何保证

通过mq 实现 base最终一致性。

3、 最终方案

3.1 系统整体架构

首先增量数据采用canal做收集(图中binLake同集群化canal)，ABC库全部存入es，D库存入mysql。

3.2 如何做全量倒库

sop对应的类型A，使用多个topic分散消息中间件压力，同时解决中间件同一topic的连接数限制。

3.3 如何提高es写性能(bulk)

通过jmq异步创建es索引，通过redis队列实现bulk模式提交对应用的透明化

如何提高Elasticsearch性能

如何提高Elasticsearch性能

solr查询快，但更新索引时慢(即插入删除慢)，用于电商等查询多的应用；

2.ES建立索引快(即查询慢)，即实时性查询快，用于facebook新浪等搜索。

如何提高ES性能：

1.ES更新操作尽量提供批处理，减少写入次数；(bulk)

2.按商家维度分多套集群， 在集群里再按照商家维度分片；

3.热点集中问题解决方案：路由规则可定制化由ES团队负责；

4.提供数据重建reindex功能，要求mapping配置source为true；(方便重建数据)

5.ES团队要求，业务方需要提供至少10台物理机用以部署；

6.深分页条数建议控制在1万条以内，做分页用scroll方式实现，禁止跳转到大页

Elasticsearch同Solr对比

Elasticsearch同Solr对比

二者安装都很简单；Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能;Solr 支持更多格式的数据，而 Elasticsearch 仅支持json文件格式；Solr 官方提供的功能更多，而 Elasticsearch 本身更注重于核心功能，高级功能多有第三方插件提供；Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。

Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。

solr查询快，但更新索引时慢(即插入删除慢)，用于电商等查询多的应用；

2.ES建立索引快(即查询慢)，即实时性查询快，用于facebook新浪等搜索。

并发数-吞吐量-响应时间

并发数-吞吐量-响应时间

用于指网站性能/服务器性能时候：并发数：系统同时处理的请求数(分为查询类请求数、事务类请求数)。吞吐量：系统在单位时间内处理请求的数量。只不过是一个很宽泛的术语，大家经常指的吞吐量的单位可能是：TPS/QPS、页面数/秒、人数/天、处理业务数/小时等等。几个相关的概念：

TPS、QPS、RPSTPS：Transactions Per Second(每秒事务处理数)，指服务器每秒处理的事务次数。一般用于评估数据库、交易系统的基准性能。

QPS：Queries Per Second(查询量/秒)，是服务器每秒能够处理的查询次数，例如域名服务器、Mysql查询性能。

RPS：Request Per Second(请求数/秒)RPS(Request Per Second)和QPS可以认为是一回事。

RT：Response Time(响应时间)：客户端发一个请求开始计时，到客户端接收到从服务器端返回的响应结果结束所经历的时间，响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。也叫Think Time。

并发数与TPS/QPS的关系：QPS(TPS)= 并发数/平均响应时间这里的并发数如果为事务处理请求数，则为TPS，如果为查询请求数，则为QPS。