2021-01-14 TiDB-3-1业务场景评估--
2021-01-14 TiDB-3-1业务场景评估--
解决方案:
#############################################################
方案一
1、tidb：
1）16C * 32G 2个
这两个节点作为写入节点
2）32C * 64G 2个
这两个节点作为查询节点，尤其是报表相关的 sql
2、tikv：16C * 32G * 1.5T 10个 （无脑计算 2022 年年中数据容量，仅供参考，和数据本身的以及 RocksDB 的压缩率有关）
3、PD：官网配置
方案二
1、tidb：16C * 64G 3个
2、tikv：16C * 64G * 2T 7个 （无脑计算 2022 年年中数据容量，仅供参考，和数据本身的以及 RocksDB 的压缩率有关）
3、PD：8C * 32GB 3个
4、tiflash：48C *192G* 8T 可多盘 2个
5、monitor：16C * 64G 1个
注意如果是使用 tiflash ，实时报表查询的 qps 建议在 10 以下
上面两个方案，建议按照真实的业务逻辑和数据量来跑一遍，尤其是报表数据查询，以及夜间跑批，来看下两个方案的性能，结合测试结果和服务器配置根据需求来选取最终的部署方案 ~
#############################################################
需要使用tiflash的表：
order_d、order_m、order_contact 、order_shipno 、performance_d、performance_m、order_status、locate_d、ib_putaway_indicate、ib_putaway_r、ib_receipt_task_d、、ib_receiving_r_d、stock_lotattr、stock
#########################################################
2021-01-14 TiDB-3-1业务场景评估
#########################################################
TiDB-3-1业务场景评估
（1）当前业务的痛点 & 考虑 TiDB 的原因 Jwms报表应用数据量大，并且在快速增长。
目前是两个节点，每个节点分了四个库，有些大表单库分了十几张表，
研发人员维护、运维成本比较高，并且由于数据量的增长，导致一个分库磁盘使用率报警，后续面临扩容，成本也比较高。
目前单节点mysql四组库，都是一主两从，一组在商城机房，32C128G x3，三组RDS，16C64G x4，总计288C
每个节点申请一套tidb集群，总计两套。
TiDB分布式数据库，tikv方便扩容，研发人员维护运维成本也比较低。高度兼容Mysql，应用迁移成本也比较低。
（2）数据容量
1）当前的数据容量
云仓1：3.8T+1.4T+1.1T+1.3T = 7.6T
云仓3: 3.9T+1.2T+800G+1.4T = 7.3T
2）未来 3~5年的增长量
每年增长5-6T。
（3）单表数据量
单表数据量最大17亿，单节点大于1亿的表数量20+。
（4）请求类型：
1）写入：批量写入或单条写入，如果是批量写入那么 batch size 是怎样的
整体对写入的 duration 耗时是怎样的？
根据日志查看500条批量插入，整体耗时在3秒左右。
batch size最大为500，大部分请求的size都很小，极小部分会达到500，影响不是很大，如果有必要也可以对最大500的size进行拆分插入。
目前写入大部分依赖蜂巢写入数据。
还有一小部分消费MQ写入，最大batch size 500
2）查询：等值查询或范围查询或者其他业务特点
等值、范围、聚合、多表Join，子表、分页查询都有。
A、能否标注下，当前环境中，会进行这些的表的表结构信息。
都是自增ID
B、方便标注或者给出下：
a）范围查询单次会扫描多大的数据量，以及最终想客户端返回的数据量
这个根据客户需要，页面有时间范围的查询按钮，时间跨度的限制最长1年，一般不建议客户这么查。
数据量最大五六千万
b）聚合查询，同 a），另外是多表
join 聚合查询还是单表查询
聚合查询数据量最大五六千万；
多表 join 有聚合查询也有单表查询。
c）多表 join 这些表的数据量请分别标注下
上亿的那20多张表大多数都会参与多表join。
3）读写比：
读/写：1/50
4）是否有大数据平台全量抽取数据？
大数据平台离线全量抽取数据。
5）是否有定期的业务跑批？
每天晚上有跑批任务。
目前的跑批是在通过什么方式来发送任务到数据库的？
A、大事务insert into select的方式，目前已做了分页操作，并且已将tidb集群最大事务调到了10G
B、等值delete方式，pagesize=1000的方式分页删除，总量最大可到几百万。
c、还会有常规的查询Job表数据，然后进行insert update等操作（单条+批量）。
d、大数据平台向数据库直接插入数据。
（5）原架构：
原架构是怎样的，如果是分库分表，那么使用的中间件是什么？
分四个库，都是一主两从，一组在商城机房，三组是公有云RDS。
有十几张大表在单库里又分了十几张表。
分库分表中间件使用sharding-jdbc
（6）qps & tps(总量)
qps：高峰：16000 平峰: 2000
tps：高峰：1200 平峰：400
（7）RTO & RPO
RTO：故障恢复时间的目标
RPO：容忍数据丢失的量 不允许丢失
（8）其他
系统级别：0 级系统
SQL语句整理及说明:
##############################
SQL1:
SELECT
SUM(orderQty) orderQty
FROM
(SELECT
COUNT(id) AS orderQty
FROM
order_m
WHERE is_delete = 0
AND order_status IN (90)
AND update_time >= '2021-01-13 00:00:00'
AND update_time <= '2021-01-13 01:17:04'
AND tenant_id = 'CP20000002970'
AND warehouse_no = '800003324'
UNION
ALL
SELECT
COUNT(id) AS orderQty
FROM
b2b_order_m
WHERE is_delete = 0
AND order_status IN (90)
AND update_time >= '2021-01-13 00:00:00'
AND update_time <= '2021-01-13 01:17:04'
AND tenant_id = 'CP20000002970'
AND warehouse_no = '800003324') a
order_m表总量过两亿，b2b_order_m量小可以忽略，加上条件后，order_m表最大几十万参与计算（极少数或者大促时），一般也就几万数据。
但是该sql执行频繁，一天执行过万次
######################################
SQL2：
SELECT
COUNT(1) COUNT
FROM
(SELECT
m.order_no,
m.order_type,
m.bill_type,
m.order_status,
m.delivery_time,
m.create_time,
m.create_user,
m.update_user,
m.update_time,
m.carrier_name,
m.shop,
m.owner_name,
m.seller_order_no,
m.order_price,
m.receivable,
m.cod_flag,
m.total_sku_sort,
m.total_sku_qty,
m.seller_notes,
m.notes,
m.owner_no,
m.plan_delivery_time,
m.paysure_date,
m.wave_seq,
m.total_weight,
m.hander_flag,
m.hander_user,
m.hander_time,
c.phone,
c.contact,
c.customer_address1,
c.driver_name,
c.community_no,
c.province,
c.city,
c.county,
c.building,
c.floor,
c.community,
c.distribution_road,
c.work_bench,
c.customer_name,
s.waybill_no,
c.driver_tel,
c.driver_car_no,
SUM(s.weight) AS actualTotalWeight,
COUNT(s.package_no) AS packagenum,
GROUP_CONCAT(s.waybill_no) AS waybillnos,
m.channels_order_no,
m.batch_no
FROM
order_m m
INNER JOIN order_contact c
ON m.order_no = c.order_no
AND m.tenant_id = c.tenant_id
AND m.warehouse_no = c.warehouse_no
AND c.is_delete = 0
LEFT JOIN order_shipno s
ON m.order_no = s.order_no
AND m.tenant_id = s.tenant_id
AND m.warehouse_no = s.warehouse_no
AND s.is_delete = 0
WHERE m.is_delete = 0
AND m.delivery_time >= '2021-01-01 00:00:00'
AND m.delivery_time <= '2021-01-13 23:00:00'
AND m.tenant_id = 'CP20000000512'
AND m.warehouse_no = '800000583'
GROUP BY m.order_no,
m.tenant_id,
m.warehouse_no
ORDER BY m.create_time DESC) t
三张表都过2亿，加上条件后，单表最大几十万参与计算（极少数或者大促时），一般也就几万数据。
该sql执行比较频繁，每天执行3000次左右
#########################################
SQL3:
SELECT
m.order_no,
m.order_type,
m.bill_type,
m.order_status,
m.delivery_time,
m.create_time,
m.create_user,
m.update_user,
m.update_time,
m.carrier_name,
m.shop,
m.owner_name,
m.seller_order_no,
m.order_price,
m.receivable,
m.cod_flag,
m.total_sku_sort,
m.total_sku_qty,
m.seller_notes,
m.notes,
m.owner_no,
m.plan_delivery_time,
m.paysure_date,
m.wave_seq,
m.total_weight,
m.hander_flag,
m.hander_user,
m.hander_time,
c.phone,
c.contact,
c.customer_address1,
c.driver_name,
c.community_no,
c.province,
c.city,
c.county,
c.building,
c.floor,
c.community,
c.distribution_road,
c.work_bench,
c.customer_name,
s.waybill_no,
c.driver_tel,
c.driver_car_no,
SUM(s.weight) AS actualTotalWeight,
COUNT(s.package_no) AS packagenum,
GROUP_CONCAT(s.waybill_no) AS waybillnos,
m.channels_order_no,
m.batch_no
FROM
order_m m
INNER JOIN order_contact c
ON m.order_no = c.order_no
AND m.tenant_id = c.tenant_id
AND m.warehouse_no = c.warehouse_no
AND c.is_delete = 0
LEFT JOIN order_shipno s
ON m.order_no = s.order_no
AND m.tenant_id = s.tenant_id
AND m.warehouse_no = s.warehouse_no
AND s.is_delete = 0
WHERE m.is_delete = 0
AND m.delivery_time >= '2021-01-06 00:00:00'
AND m.delivery_time <= '2021-01-13 23:59:59'
AND m.tenant_id = 'CP20000002722'
AND m.warehouse_no = '800002665'
GROUP BY m.order_no,
m.tenant_id,
m.warehouse_no
ORDER BY m.create_time DESC
LIMIT 10
该sql参与的三张表都过两亿，单表最大几十万参与计算（极少数或者大促时），一般也就几万数据。
该sql执行比较频繁，每天执行2500次左右
###############################
SQL4:
select id,
node,
bill_type,
putaway_type,
employee_id,
'' ,
'' ,
sku_no,
'' ,
tenant_id,
warehouse_no,
create_time,
update_time,
create_user,
update_user,
ts,
is_delete,
md5_value
from `performance_d` where (create_time >= '2021-01-12' and create_time < '2021-01-13' ) or (update_time>='2021-01-12' and update_time < '2021-01-13' ) or (ts>='2021-01-12' and ts < '2021-01-13' )
该表数据过亿，条件过滤后还是过亿数据参与计算，数据执行时间3分钟左右
##############################
SQL5:
SELECT
os.order_status orderStatus,
COUNT(1) AS 'productNumber',
os.create_time AS 'createTime'
FROM
order_status os
WHERE os.is_delete = 0
AND os.order_status IN (10, 40, 50, 60, 70, 90, 404)
AND os.create_time >= '2021-01-14 07:00:00'
AND os.create_time <= '2021-01-14 23:59:59'
AND os.tenant_id = 'CP20000003113'
AND os.warehouse_no = '800003886'
GROUP BY os.order_status,
HOUR(os.create_time)
该表是报表库最大表，数据十几亿，按条件过滤后百万级别数据参与计算，执行时间1分钟左右
########################
SQL6:
select 'my15755sa.mysql.jddb.com','jcloud_report','order_status',id,batch_no,order_no,order_status,order_source,previous_status,reason,is_backtrac,tenant_id,org_no,distribute_no,warehouse_no,create_time,update_time,create_user,update_user,ts,is_delete,version from order_status where create_time >= '2021-01-10 00:00:00' or update_time >= '2021-01-10 00:00:00' or ts >= '2021-01-10 00:00:00'
这是大数据离线抽数的sql，该表是报表库最大表，数据十几亿，查询条件使用or，十几亿数据参与计算。执行时间接近两个小时
posted on 2021-04-27 07:17 Sunnynanbing 阅读(148) 评论(0) 编辑 收藏 举报
