2021-01-14 TiDB-4-1业务场景评估(运输的货物体积明细)
廖涛-周志亮
TiDB:tidb-z770skbgxw-tidb.tidb-z770skbgxw-hb.jvessel2.jdcloud.com -P 4000
grafana:http://tidb-z770skbgxw-grafana.tidb-z770skbgxw-hb.jvessel2.jdcloud.com:3000
解决方案:
#############################################################
方案一
1、tidb：16C*64G 2个节点
2、tikv:16C*64G*2T 7个节点
3、pd:16C*64G 3个节点
4、Monitor ：16C*64G 1个节点
#############################################################
#########################################################
2021-01-14 TiDB-4-1业务场景评估
#########################################################
TiDB-4-1业务场景评估
（1）当前业务的痛点 & 考虑 TiDB 的原因
运输货物体积明细数据量大，并且在快速增长。
目前是四个节点，每个节点分了四个库，每个库分了32张表，
研发人员维护、运维成本比较高，并且由于数据量的增长，导致磁盘使用率报警，后续面临扩容，成本也比较高。
目前单节点mysql四组库，都是一主一备一从，3*4*16C/64.0G/3T，一共192C。磁盘36T.。目前磁盘总空间最高90%，最低87%。里面包含2张表。本次需要迁移的表占用空间60%左右。
每个节点申请一套tidb集群，总计两套。
TiDB分布式数据库，tikv方便扩容，研发人员维护运维成本也比较低。高度兼容Mysql，应用迁移成本也比较低。
（2）数据容量
1）当前的数据容量
1.3T*4=5.2T
2）未来 3~5年的增长量
每月增长了1.3T
（3）单表数据量
单表数据量最大550w。
（4）请求类型：
1）写入：应用采用的是单条写入。
同步历史数据使用蜂巢写入数据。
2）查询：等值查询或范围查询或者其他业务特点
只有等值查询。存在sum。
A、能否标注下，当前环境中，会进行这些的表的表结构信息。
主键id采用seq生成。
表结构：
CREATE TABLE `payable_goods` (
`id` bigint(20) unsigned NOT NULL DEFAULT 0 COMMENT '主键id',
`business_code` varchar(50) NOT NULL DEFAULT '' COMMENT '业务单号，委托书、车次任务明细等',
`bill_type` int(10) NOT NULL DEFAULT 0 COMMENT '单据类型',
`bill_class` varchar(10) NOT NULL DEFAULT '' COMMENT '运单分类、转运单类型、大件运单类型',
`bill_sub_type` varchar(10) NOT NULL DEFAULT '' COMMENT '运单子类型、转运单运输方式',
`customer_type` int(10) NOT NULL DEFAULT 0 COMMENT '商家类型',
`trust` int(10) NOT NULL DEFAULT 0 COMMENT '是否信任商家0 不信任1信任',
`bill_code` varchar(50) NOT NULL DEFAULT '' COMMENT '单据号',
`package_no` varchar(50) NOT NULL DEFAULT '' COMMENT '包裹号',
`package_num` int(10) NOT NULL DEFAULT 0 COMMENT '包裹数',
`package_total_num` int(10) NOT NULL DEFAULT 0 COMMENT '包裹总件数',
`original_weight` decimal(20,4) NOT NULL DEFAULT 0.0000 COMMENT '原始重量kg',
`original_volume` decimal(20,4) NOT NULL DEFAULT 0.0000 COMMENT '原始体积cm3',
`correct_volume` decimal(20,4) NOT NULL DEFAULT 0.0000 COMMENT '修正体积cm3',
`share_volume` decimal(20,4) NOT NULL DEFAULT 0.0000 COMMENT '分摊体积cm3',
`waybill_sign` varchar(500) NOT NULL DEFAULT '' COMMENT '运单打标',
`send_pay` varchar(500) NOT NULL DEFAULT '' COMMENT '订单打标',
`evn` tinyint(1) NOT NULL DEFAULT 0 COMMENT '数据类型，0:生产、1UAT、2TEST',
`remark` varchar(200) NOT NULL DEFAULT '' COMMENT '备注',
`create_user` varchar(50) NOT NULL DEFAULT '' COMMENT '创建人',
`update_user` varchar(50) NOT NULL DEFAULT '' COMMENT '更新人',
`create_time` datetime NOT NULL DEFAULT '1970-01-01 00:00:00' COMMENT '创建时间',
`update_time` datetime NOT NULL DEFAULT '1970-01-01 00:00:00' COMMENT '更新时间',
`is_delete` tinyint(1) NOT NULL DEFAULT 0 COMMENT '是否有效0有效1无效',
`ts` timestamp(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '时间戳',
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_bill_code` (`bill_code`,`bill_type`,`business_code`),
KEY `idx_business_code` (`business_code`,`is_delete`,`share_volume`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='货物明细表';
3）读写比：
读/写：1/10
4）是否有大数据平台全量抽取数据？
大数据平台离线全量抽取数据。
5）是否有定期的业务跑批？
实时写入，凌晨会存在跑大批量数据。
（5）原架构：
原架构是怎样的，如果是分库分表，那么使用的中间件是什么？
根据业务单号分库。4个实例，每个实例4个库，一共16个库。
分库分表中间件使用sharding-jdbc
（6）qps & tps(总量)(写入)
qps：高峰：306656平峰: 100000
tps：高峰：961 平峰：80
（7）RTO & RPO
RTO：故障恢复时间的目标
RPO：容忍数据丢失的量 不允许丢失
（8）其他
系统级别：0 级系统
SQL语句整理及说明:
##############################
SQL1:
select
sum(share_volume)
from payable_goods
where
business_code=#{po.businessCode,jdbcType=VARCHAR}
and is_delete=0
business_code有索引，查询量
######################################
SQL2：
select
id, business_code, bill_type, bill_class, bill_sub_type, customer_type, trust, bill_code,
package_no, package_num, package_total_num, original_weight, original_volume, correct_volume,
share_volume, waybill_sign, send_pay
from payable_goods
where
business_code=#{po.businessCode,jdbcType=VARCHAR}
and is_delete=0
查询结果list，结果最大2w条左右。每天查询10w次左右。