- 快召唤伙伴们来围观吧
- 微博 QQ QQ空间 贴吧
- 文档嵌入链接
- 复制
- 微信扫一扫分享
- 已成功复制到剪贴板
何志勇-分进合击:分布式数据库在平安应用实践
何志勇老师针对互联网金融分享了平安科技的实战经验,他从数据库选型画像开始分析,道出引入分布式数据库期间的思考,并从多方面对比解析不同类型的分布式数据库,最终作出取舍,解决业务痛点。
展开查看详情
1 .数据库技术沙龙-深圳站 分进合击 --分布式数据库在平安应用实战 何志勇 1
2 .目录 1 业务需求与应用场景 2 分布式数据库的选型与引入 3 应用实战 4 未来规划
3 .Part I 业务场景与需求
4 . 账户管家应用场景 平安口袋银行 服务用户数1.2亿 月服务次数1000万 平安金管家 底部向左滑 平安好车主 陆续接入其他app中
5 . 账户管家应用架构 标准H5接口 丰富可重用的场景 参数化弹性设计 功能 专业公司-我的 交易控制与逻辑处理 来源 登陆管理 账户加挂 资产模型/资产展示 账户加挂/映射管理 接 消息中心 业务账户 接 入 出 H5接入 网 网 关 关 账户模型 配置管理 任意门 任意门各入口 Powered by 平安云计算基础构架
6 . 业务需求简述 • 账户类型及其相关业务类型多,具体业务类型在前期并不是非常明确, 相同账户对接的服务多样,可根据需求进行动态加入; • 不同功能模块分期接入,数据量、用户访问并发量逐渐增加,具体规 模体量前期不能完全需求; • 账户消息及访问流水,需要用于统计分析; • 其中消息中心数据量大,初步评估日写入量可达3亿,每行大小约5k • 支持SQL及多表关联查询 • 前端与后台能打包成产品,不受商业license 限制
7 . 从DBA角度看业务 01 • 数据量大,约3亿*5kB=1.5T, 并发量高 业务 02 • 业务模块分期接入,并发逐 渐增加,数据库层要求能弹 性扩容 ? 需求 03 • 数据库层支持混合事务 数据库 04 • 开源数据库产品
8 . 数据库选型画象 Type 数据库 弹性扩容 TP AP 开源 oracle N Y Y N PostgreSQL N Y Y Y SQL MySQL N Y N Y SQLserver N Y Y N Mysql +中间件 Y Y N Y Mongodb Y Y N Y NoSQL Hbase Y Y N Y 时序数据库 InfluxDB Y N/A Y Y 内存缓存 Redis Y N/A N/A Y 内存数据库 Timesten N Y Y N 图数据库 Neo4j Y Y N Y MPP YellowBrick N Y Y N
9 . 数据库选型 • 问题: • 不支持标准SQL Mongodb • 多表关联复杂 • 对分析型事务支持不好 • 分库分表路由是静态的,易导致数据分布不均 MySQL+中间件 • 前期需求分析要求高 • 事务一致性必须由中间件实现,比较复杂 • 不支持标准SQL HBASE • 多表关联范围查询性能下降快 • 不支持分析事务 • 不支持数据修改及标准SQL InfluxDB • 多表关联复杂
10 .Part 2 分布式数据库的选型与引入
11 . 分布式数据库选型与引入 Amazon RDS SQL Azure VoltDB OceanBase sequoiadb CockroachDB TiDB ……
12 .分布式数据库选型与引入 功能与架 备份与恢 配置与管 SQL特性 构 复 理 应用场景 TiDB or 基准测试 测试 CRDB ?
13 . TiDB VS CRDB 之功能与架构 对比项 cockroachdb TiDB 事务隔离级别 SI,SSI(默认) SI 分为TiDB server,pd SQL,tansaction kv,Distribution 组件/架构 server,Tikv server,需要分别部 Replication,Storage 署 接口协议 pg mysql 客户端 psql,cockroach mysql 数据库字符集 UTF8 UTF8MB4 存储kv RocksDB RocksDB RocksDB 最小单位 range region 复制协议 raft raft 应用场景 OLTP,OLAP OLTP,OLAP 服务支持 国外,社区 国内,社区
14 .TiDB VS CRDB 之功能与架构
15 . TiDB VS CRDB之 SQL 特性 Item Type CRDB TiDB Table and View Standard ✓ ✗ references Table Expressions WITH ORDINALITY CockroachDB ✓ ✗ Extension table partition Standard ✓ Planned Matching using Common Extension ✓ ✗ Value Expressions and POSIX regular Boolean Formulas expressions Permissions role Standard ✓ ✗ Common Table Common Extension Planned ✗ Miscellaneous Expressions Stored Procedures Common Extension Planned ✗ Aggregate function Common Extension ✓ Partial Encryption mysql Extension /decryption and Partial ✓ Compression function function window function postgreSQL, MSSQL,oralce ✓ ✗ Extension json ,jsonb ✓ ✓ Partial
16 . TiDB VS CRDB之配置与管理测试 Type DML CRDB TiDB 说明 查看数据库,表等对象 ✓ ✓ 大小 在线添加列是否锁表 ✗ ✗ CRDB 支持事务,不会锁表,TiDB 不支持 事务,DDL自动提交且不成回滚,不锁表, schema 对象 在线更改列名是否锁表 ✓ ✗ TiDB语法上支持,功能上暂不支持列重命 名 表重命名 ✓ ✓ 统计信息查看,收集与 ✗ ✓ 管理 kill DML 场景1:普通 ✓ ✓ select kill DML 场景2 ✓ ✓ 当开启事务t1(insert 语句)后,另一个 begin;insert.commit事 会话查不到t1 的相关会话,这个时候如果 务 另起一个窗口发起一个查询 s1 select 会话管理 count(*) 这时查询一直在exec 状态,在发 起一个cancel s1,发现cancel 不了,查询 query 信息还是executing 状态,如果 commit/rollback t1, s1 结束,提示已被 cancel kill DDL ✓ ✓ 节点添加 ✓ ✓ 集群管理 节点删除 ✓ ✓ RBO ✓ ✓ SQL 优化器 CBO partial ✓
17 . TiDB VS CRDB之备份与恢复 备份方 DB 工具 功能 是否开源 说明 式 dump/import 1.数据导出 是 data 备份/还原 数据库总大小:182.5 GiB 导出时间:1小时 否(企业版 backup/restore 备份/还原 导出数据大小:66G 全备, 支持) CRDB 导出格式:sql,单个sql文 增备 件 备份还原,支持postgres 2.恢复功能在2.0测试 pg_dumper 9.5+ backup 到本地不支持,目 是 前功能支持导到http mydumper/load 备份/还原 是 er 1.数据导出, • 数据同步: 同步TiDB 集 数据库总大小:149.5 群数据到其他数据库 导出时间:1分钟,导出 • 实时备份和恢复: 备份 全备, 设置:(线程16,chunk TiDB TiDB-Binlog TiDB 集群数据,同时可 增备 是 64M) 以用于TiDB 集群故障时 导出格式:sql,多个sql文 恢复 件 增量导入数据 导出数据大小:61G syncer 是
18 . TiDB VS CRDB之基准测试 基本信息: CockroachDB 版本:2.0.0 TiDB 版本:2.0.0 测试工具:Sysbench 1.0.4 环境信息: 主机 cpu processor Memory Disk Intel(R) Xeon(R) CPU E5-2640 v4 @ 主机1 2.40GHz 2*20 251G ssd Intel(R) Xeon(R) CPU E5-2640 v4 @ 主机2 2.40GHz 2*20 251G ssd Intel(R) Xeon(R) CPU E5-2640 v4 @ 主机3 2.40GHz 2*20 251G ssd 测试架构:
19 .TiDB VS CRDB之基准测试
20 . TiDB VS CRDB之基准测试 ——单条SQL性能 测试数据 CRDB时间 TiDB时间 DML 说明 量 (s) (s) cockroachdb 当前还没有提供,可以参考以下论坛 https://forum.cockroachlabs.com/t/how-to-quickly- retrieve-estimate-number-of-rows-in-table/263/3 select count(*) 1千万 5~10 <2 cockroachdb创建索引的时间很长 insert 数据大概10分钟 insert 1千万 1200 1001 左右 insert into select from 1百万 na na 两都均报报错transaction is too large to commit delete 1百万 241 na TiDB在delete时报错transaction is too large to commit delete 15w 134 10 cockroachdb 在删除时必须加上where条件 update 10万 14.88 9.4 update tbtest3 set k=1 where 1=1; SELECT id, k, c FROM test.sbtest1 LIMIT 20 OFFSET 分页查询 1千万 1.5 1.55 200000; 分析函数排名 1千万 100 19.27 备注1 备注1:分析排名函数 CRDB SELECT id, k, c, rank() OVER (PARTITION BY k ORDER BY k) AS rn FROM sbtest1 ORDER BY k, 4 LIMIT 20 offset 2000; TiDB select b.id, b.k, b.c, if(@k = b.k, @rank := @rank + 1, @rank := 1) as rank from (select id, k, c from sbtest1 order by k ) b, (select @rownum := 0, @k := null, @rank := 0) a order by k,4 limit 20 offset 2000;
21 . TiDB VS CRDB之基准测试 tidb&cr read write tidb&cr read only 25000 1200 50000 3500 20000 1000 3000 40000 800 2500 15000 30000 2000 qps 600 tps qps tps 10000 20000 1500 400 1000 5000 200 10000 500 0 0 0 0 130 190 250 310 370 430 490 550 610 670 730 790 850 910 970 130 190 250 310 370 430 490 550 610 670 730 790 850 910 970 10 70 1030 1090 1150 10 70 1030 1090 1150 threads threads cr_qps tidb_qps cr_tps tidb_tps cr_qps tidb_qps cr_tps tidb_tps
22 . TiDB VS CRDB之基准测试 tidb &cr point select tidb &cr update index 70000 12000 60000 10000 50000 8000 tps/qps tps/qps 40000 6000 30000 20000 4000 10000 2000 0 0 130 190 250 310 370 430 490 550 610 670 730 790 850 910 970 130 190 250 310 370 430 490 550 610 670 730 790 850 910 970 10 70 1030 1090 1150 10 70 1030 1090 1150 threads threads cr_tps cr_qps tidb_tps tidb_qps cr_tps cr_qps tidb_tps tidb_qps
23 . TiDB VS CRDB之基准测试 tidb&cr update non index tidb &cr delete 25000 50000 45000 20000 40000 35000 15000 30000 25000 10000 20000 15000 10000 5000 5000 0 0 130 190 250 310 370 430 490 550 610 670 730 790 850 910 970 10 70 1030 1090 1150 130 190 250 310 370 430 490 550 610 670 730 790 850 910 970 10 70 1030 1090 1150 cr_tps cr_qps tidb_tps tidb_qps cr_tps cr_qps tidb_tps tidb_qps
24 . TiDB VS CRDB之基准测试 tidb &cr insert 14000 12000 10000 8000 6000 4000 2000 0 130 170 210 250 290 330 370 410 450 490 530 570 610 650 690 730 770 810 850 890 930 970 10 50 90 1010 1050 1090 1130 1170 cr_tps cr_qps tidb_tps tidb_qps 说明: 1. 测试场景包括 rea-write,read only,point select ,update index ,update noindex,insert ,delete, 具体包括的脚本参见附录 sysbench 脚本 2. 以上测试中sysbench原如脚本有更改,cockroach 在数据准备时id使用了 sequence, tidb id列使用auto_increment 3. 以上的测试场景tidb 性能均优于cockroach,由于2的原因,insert 场景对 cockroach 会有性能影响,本次对比不作参考
25 . TiDB VS CRDB之应用场景测试 产险xxxx查询分析场景测试 Select c1 c2,c3, c4,c5,c6 (select ..from 基表信息 SQL xxxxx1_ p1 where ) a1, 表名 rows (select count(0) from xxxxx2_ cs, xxxxx_mode 399 xxxxx3_ dp) a2, xxxxx_price_oper 139,198 .......(此处省去16个select) xxxxx_dept_price 4,457,797 from xxxxx_brand a, xxxxx_fits 145,594 xxxxx_manufacturer b, xxxxx_series 1,415 xxxxx_series c, Xxxxx_facturer 222 xxxxx_category_series d xxxxx_category 1,902 Where… xxxxx_brand 228 结果 DB 时间 备注 oracle 134.8s 执行时间超过10分钟(默认值),报gc life time 小于 TiDB 49分35秒 事务,需要更改这个值才可以执行完 CRDB na 不支持带条件关联的标量子查询
26 . 小结 1. 功能与架构上两者事务隔级别不同,CRDB 为SSI,TiDB为SI ;TiDB支持Spark生 态 2. SQL特性,CRDB支持的SQL特性更为丰富,支持窗口函数,分区表,视图等; 3. 备份与恢复方面CRDB分为开源与企业版本工具,TiDB均为开源,性能上TiDB 要优于CRDB 4. 配置与管理上,CRDB 对schema 对象在线定义支持事务,TiDB在优化器上支持 CBO 更全面 5. 基准测试方面, TiDB在单条SQL的性能,高并发select ,update,delete均优于 CRDB,高并发压力下,CRDB读写场景下随着并发的增加性能下降明显,TiDB性 能较稳定 6. 应用场景测试,CRDB不支持标量子查询,TiDB能支持非常复杂的查询,但性 能较oracle 相差比较大。
27 .Part 3 应用实战
28 . 业务测试 1.测试点:数据写入性能 3.测试结果 1) 直接通过程序插入数据库 压测性能如下: 2.DB主机环境信息: 主机 cpu mem disk host1 24c 384 ssd host2 24c 384 ssd host3 24c 384 ssd 组件 节点数 分布机器 说明 TiDB 3 host1,host2,host3 2) 通过消息通接口压测TPS 670 PD 3 host1,host2,host3 Tikv 3 host1,host2,host3 1T/TikV
29 . 业务测试 3)使用批量写入与消息队列消费,对应的架构如图: 测试架构 配置: 客户端 APP APP …… cpu mem 数量 说明 app nginx 2c 4g 2 App nginx App nginx MQ 8c 16G 4 brocker 为3主3从 与db在一台服务 db nginx 24C 386G 1 器上 receiver MQ consumer DB nginx 结果:TPS达3000