1、iDB在平安核心系统的引入及应用()目录分布式数据库TiDB的引入TiDB应用实战未来规划1分布式数据库TiDB的引入TiDB引入POC:基于2.0版本应用场景测试功能与架构01060504 03SQL特性基准测试02备份与恢复配置与管理TiDB 功能与架构Item事务隔离事务隔离级别级别TiDBSI分为TiDB server,pd组件组件/架构架构server,Tikv server,需要分别部署接口协议接口协议 mysql客户端客户端数据库字数据库字符集符集mysqlUTF8MB4存储存储kvRocksDBRocksDB最小单位最小单位 region复制协议复制协议 raft应用场景应用场
2、景 OLTP,OLAP服务支持服务支持 国内，社区TiDB SQL特性ItemUNSIGNED INTTypeTiDBCommon ExtensionSET, ENUMMySQL, PostgreSQLExtensionrow valueConstraintsTransactionsCheckStandardStandardForeign KeySAVEPOINTMultiple indexes per query Common ExtensionIndexesFull-text indexesCommon ExtensionIndex renamesCHANGE/MODIFY COLUMNS
3、tandardStandardschema changesUPSERTPostgreSQL, MSSQLStatementsClausesExtensionRETURNINGCommon ExtensionTiDB SQL特性ItemTypeTiDB说明Table and ViewreferencesStandardRoadmap 支持Table Expressionstable partitionStandardRoadmap 支持Matching using POSIX Common Extensionregular expressionsValue Expressions andBool
4、ean FormulasPermissionsroleStandardCommon ExtensionRoadmap支持Roadmap支持Common TableMiscellaneousExpressionsStored ProceduresAggregate functionCommon ExtensionCommon ExtensionPartialEncryption /decryption mysql ExtensionandCompression functionfunctionwindow functionpostgreSQL,MSSQL,oralceExtensionRoadm
5、ap支持json ,jsonbPartial配置与管理测试TypeDMLTiDB说明查看数据库，表等对象大小在线添加列是否锁表TiDB DDL自动提交且不成回滚，不锁表不支持事务schema 对象在线更改列名是否锁表TiDB语法上支持，功能上暂不支持列重命名表重命名统计信息查看，收集与管理kill DML 场景1：普通 selectkill DML 场景2begin;mit事务当开启事务t1（insert 语句）后，另一个会话查不到t1 的相关会话，这个时候如果另起一个窗口发起一个查询 s1 select count(*) 这时查询一直在exec 状态，在发起一个cancel s1,发现can
6、cel 不了，查询query 信息还是executing 状态，如果commit/rollback t1, s1 结束，提示已被cancel会话管理kill DDL节点添加节点删除RBO集群管理SQL 优化器CBO备份与恢复备份、恢复方式DB工具功能是否开源说明备份/还原1.数据导出：mydumper/loader是数据库总大小：150G导出时间：1分钟，导出设置：（线程16，chunk64M）导出格式：sql,多个sql文件导出数据大小：64G2.恢复： 数据同步: 同步TiDB 集群数据到其他数据库TiDB-Binlog 实时备份和恢复: 备份TiDB 集群数据，同时可以用于TiDB 集群
7、故障时恢复是全备，增备从mysql 到tidb 增量同步数据,TiDB备份数据文件大小：64Gsyncer是是表个数：32表数据库量：1.05千万Loader 并发数：64恢复时间：1h:44m: 21s全量数据高速导入到 TiDB 集群的工具，支持 mydumper 或 CSV 输出格式的数据源恢复所有数据TiDB-Lightning2.1 版本后才发布基准测试基本信息：TiDB 版本：2.0.0测试工具：Sysbench 版本：1.0.12并发数：1200基础数据：32个表/1千万环境信息：Ti D B 压力测试架构（一）appLoad Bal ancerHapr oxyTi DBPDTi
8、 DB集群PD集群Ti DBPDTi DBPD主机主机cpuprocessor MemoryDiskRa f tRa f tRa f tRa f tIntel(R) Xeon(R) CPU E5-2640v4 2.40GHzIntel(R) Xeon(R) CPU E5-2640v4 2.40GHzIntel(R) Xeon(R) CPU E5-2640v4 2.40GHz主机主机1主机主机2主机主机324c24c24c251G251G251GssdssdssdTi KV集群Ti KVTi KVTi KVHost 1Host 2D C 1Host 3测试架构：部分图例说明:主机 组件数据同步集
9、群存储节点基准测试单条SQL性能测试数 TiDB执行时DML说明备注1：模拟分析排名函数Oracle/Postgresql:SELECT id, k, c, rank()OVER (PARTITION BY kORDER BY k) AS rn FROMsbtest1 ORDER BY k, 4LIMIT 20 offset 2000;TiDBselect b.id, b.k, b.c, if(k= b.k, rank := rank +1, rank := 1) as rankfrom (select id, k, c fromsbtest1 order by k ) b,(select r
10、ownum := 0,k := null, rank := 0) aorder by k,4 limit 20offset 2000;据量间（s）selectcount(*)1千万1千万2与oracle 相近insert1001insert into事务太大，报错transaction is too large toselect from1百万nacommitTiDB在delete时报错transaction is too large todelete1百万nacommitdeleteupdate15w10万109.4update tbtest3 set k=1 where 1=1;SELEC
11、T id, k, c FROM test.sbtest1 LIMIT 20OFFSET 200000;分页查询模拟分析函数排名1千万1千万1.55备注119.27基准测试sysbench测试TiDB read writeTiDB read only2000015000100005000010008006004002000500004000030000200001000003500300025002000150010005000ThreadsThreadstidb_qpstidb_tpstidb_qpstidb_tps基准压力测试sysbench测试Tidb point selectTiDB u
12、pdate index120001000080006000400020000700006000050000400003000020000100000Threadsthreadstidb_tpstidb_qpstidb_tpstidb_qps基准压力测试sysbench测试TiDB update non indexTiDB delete2000015000100005000050000400003000020000100000ThreadsThreadstidb_qpstidb_tpstidb_qpstidb_tps基准压力测试sysbench测试tidb insert1400012000100
13、0080006000400020000tidb_tpstidb_qps应用场景测试产险xxxx查询分析场景测试基表信息(8个表)SQLSelect c1 c2,c3, c4,c5,c6 (select .fromxxxxx1_ p1 where ) a1,(select count(0) from xxxxx2_ cs，xxxxx3_ dp) a2,表名表名rowsxxxxx_mode399139,198xxxxx_price_operxxxxx_dept_pricexxxxx_fits.(16 select)此处省去 个4,457,797145,5941,415222from xxxxx_b
14、randxxxxx_manufacturer b,xxxxx_series c,xxxxx_category_series dWherea,xxxxx_seriesXxxxx_facturerxxxxx_categoryxxxxx_brand1,902228应用场景测试DB时间时间优化后优化后备注备注oracle134.8sn/a执行时间超过10分钟（默认值），报gc life time 小于事务，需要更改这个值才可以执行完，优化点：从TiDB引擎底层优化执行计划TiDB49分35秒34S小结应用场景测试功能与架构TiDB事务隔级别为SI ,支持Spark生态,支持动态扩容，跨数据中心部署支持
15、标量子查询，能支持非常复杂的查询，查询引擎可朔性强SQL特性01基准测试TiDB在单条SQL的性能较好，高并发场景下，性能较稳定，060504 03兼容mysql语法，2.0版本不支持窗口函数，分区表，视图，trigger等02但DML事务大小有限制。备份与恢复配置与管理备份恢复工具均为开源，支持多线程备份恢复，当前版本不支持物理备份，loader 恢复时间偏长支持在线DDL，2.0只支持串行的DDL,在优化器上支持CBO ，可以支持复杂的SQL2TiDB应用实战平安财神节活“暖宝保”业务业务需求 压力测试遇到的问题活动背景0401020301 活动背景平安“财神节”活动：“财神节”是中国平安
16、综合性年度线上金融狂欢节。2019年平安集团“财神节”活动于2019年1月8日正式启动，涉及寿险，产险，银行，养老险，健康险，普惠，证券，基金，健康互联，陆金所，壹钱包，互娱，不动产等多个领域，活动参与的BU数量，与推广的力度是历年之最。中国平安108财神节成绩单：“1.08单日成交额超过1000亿”单日交易额破千亿背后：几百个后台数据库实例的运维保障。平安财神节活“暖宝保”应用场景02 业务需求活动时间 : 2019年1月8日业务类别：以微服务的方式对接所有的个财个意互联网出单，包括移动app端、各种合作伙伴对接出单业务场景 : 秒杀、红包雨性能要求：需要支持高并发、低延迟，高响应（可能会存
17、在短时间的高峰），高可用，预估TPS:1000次 insert/s 、4000次 select/s 、 2250次 update/s ，TPS 延迟200ms系统级别：产险一类出单系统数据增长：一年存储量10TB，后续增长预估按照一年10TB增加，数据需在DB中保存25年，预计需在DB中保存2050TB的应用数据注：业务中保单价格低至19.9 元，且是互联网应用，业务反馈TPS存在不确定性，可能远远大于以上评估值！DBA眼中的业务需求 并发量高，响应时间快，低延迟01? TPS需求存在不确定性，数据业务需求数据库特性库层要求能按需求快速弹性扩容数据库03 数据库存储的容量大，同时需支持TP，A
18、P业务数据库画像Type数据库数据库弹性扩容弹性扩容TPYAPY开源开源oracleNNNNYNYPostgreSQLMySQLYYSQLYNYYSQLserverMysql +中间件MongodbHbaseYNYYNNNYYYYNoSQLYYY分布式数据库分布式数据库时序数据库时序数据库内存缓存内存缓存TiDBYYYInfluxDBRedisYN/AN/AYYYYN/AYY内存数据库内存数据库TimestenNeo4jNYNY图数据库图数据库MPPYNYYellowBrickNYN使用TiDB挑战时间紧迫开发零使用经验并发量与扩容DB运维管理2018年12月17日2019年1月7日，20天时
19、间内完成开发测试到生产上线，时间短，风险大互联网业务并发需求前期不可完全需求，前期不能很好的以实际压力进行测试，与资源准备TiDB还处于生产落地阶段，一类系统尚未使用过TiDB,没有大规模应用运维经验现有开发大都是基于传统oracle保险业务，对于TiDB没有使用经验03 压力测试测试工具：jmeterTiDB 数据库版本：2.0.10业务场景：jmeter 直连DB,测试保单读写应用场景DB主机环境信息Ti D B 压力测试架构（一）app主机主机host1host2cpu24c24c24cmem384G384G384GdiskSSDSSDSSDSSDNg i nxTi D BPDTi D
20、BPDTi D BPDTi DB集群PD集群host924c384GRa f tRa f tRa f tRa f tTiDB节点信息：组件组件 节点数节点数分布机器分布机器说明说明Ti KV集群TiDBPD33host1,host2,host3host1,host2,host3Ti KVTi KVTi KVTiDB节点与PD节点布在其中的3台机器上Host 1Host 2D C 1Host N部分图例说明:主机 组件1T/TikV节点，Tikv3节点数据从 个节数据同步集群存储节点Tikv315 host1,host2,.,host915点一直增加到 节点03 压力测试jmeter 直连DB,
21、测试写保单场景（单条数据commit,实际为7个insert 为写一个保单）：Transacti Transacti Transacti transatio transatio单个节点单个节点单个客单个客客户端节客户端节点数点数总并发个总并发个数数TPS增长增长 TPS增长率增长率(环环 on Avg on Min on Max n 平均响平均响 n 平均响平均响 tidb实例实例 tikv实例实例 总总耗时耗时总耗时总耗时写入写入/读读 总数据量总数据量 户端并户端并TPS率率(同比同比 )比比 )(平均耗平均耗 (最小耗最小耗 (最大耗最大耗 应时间环应时间环 应时间同应时间同个数个数个数
22、个数（s） （min）取数据量取数据量发数发数时时)844749633535521770时时)647548533761时时)173119393177287326104191比提升比提升比提升比提升2222241000000 20000001000000 20000001000000 20000001000000 20000001000000 20000001000000 40000005005005005005005001000100010001000100020001164130915411820186625471333333317171529152911011073252900:28:37
23、00:25:2900:25:290:18:2100:17:5300:42:0912.46%32.39%56.36%60.31%118.81%12.46%11.26% 11.26%25.00% 15.49%36.61% 15.48%38.27% 2.62%8.77% -47.79%17.72%18.11%2.53%69151536.50%TPS及TPS响应时间与tikv关系TPS与TiKV节点数增加关系3000250020001500100050060.00%40.00%20.00%0.00%3000200010000150.00%100.00%50.00%0.00%-20.00%-40.00%
24、-60.00%33691515033691515TiKV节点数TiKV节点个数TPSTPS增长率(同比 )TPS增长率(环比 )TPSTransaction Avg03 压力测试jmeter 直连DB,测试写保单与查保单场景（单条数据commit,实际为7个insert 为一个保单，其中insert 与read 为同一个批次测试场景）：单个节点写入/读取数据量Transacti Transacti Transacti transationon Min(ms)on Max(ms)on Avg 平均响应时 tidb实例 tikv实例SQL type节点数总数据量单个并发数 总并发个数 TPS总和
25、TPS增长率(ms) 间提升比个数个数insertread334242424242100000030000005003005003005003005003005003005003001500900935711389573315923327419285 822578561000000 400000029193947 58387894587506 234294511306166 226039671000000 400000022199903 443958051000000 400000015605068 312101351000000 400000044753716 895074322552511
26、503317213533insertread200060023.06%49.84%30.57%20.89%-7.06%11014006170132699043257114731184363316954172333insertread200046113034.34%95.31%17.87%7.25%366002000600200060020006001665922502500427202341825281531411411358732371725769153333336insertread99insertread12121515insertread231021730979303 压力测试jmet
27、er 直连DB,测试读写保单中写保单场景：单个节点写入/读取数据量Transacti Transacti Transacti transactio transactioTPS同比增 TPS环比增on Min(ms)on Max(ms)on Avg n平均响应 n平均响应 tidb实例 tikv实例SQL type节点数总数据量单个并发数 总并发个数 TPS总和长率长率(ms) 同比提升环比提升个数个数insertinsertinsertinsertinsertinsert34444410000001000000587506100000010000001000000300000040000002
28、34294540000004000000400000050050050050050050015002000200020002000200093571389540063269325731182310159233333331150172322502720252823.06%49.84%30.57%20.89%-7.06%23.06% 11017211130873717769384.40%140.76%191.06%170.51%4653414134.34%95.31%17.87%7.25%34.34%649.27%58.34%55.32%91215读写保单场景写保单tps与tikv节点关系写保单t
29、ps延迟与tikv节点关系30002500200015001000500250.00%200.00%150.00%100.00%50.00%300025002000150010005001.210.80.60.40.2000.00%336912150-50.00%tikv节点数33691215tikv 节点数TPS总和transaction平均响应同比提升Transaction Avg(ms)TPS总和TPS同比增长率TPS环比增长率transaction平均响应环比提升03 压力测试调整Jmeter 中的事务控制开关autocommit 为false,并在insert 最后添加commit,
30、经测试，4个节点，每个节点写50万数据，总的TPS为2000，时间响应时间为35ms以下，下面是其中一个节点的监控情况：03 压力测试压力测试小结TiDB吞吐在select中即point select，TiDB的吞吐比较好；弹性扩容在insert场景下随着节点数的增加，TPS也会相应的增加，每增加3个节点TPS可提升12%20%左右，同时在相同TiKV节点数下，TPS与响应时间，此消彼长；批量提交性能尤佳业务中一个保单需要同时写7个表，7个表同时commit 比单表commit TPS 高,相同TPS 场景下延迟更小；初始化region分裂耗时长因在测试时没有预热数据（表为空表），对空表写入前
31、几分钟，响应时间会比较大，约58分钟后响应时间趋于稳定。在前几分钟内响应时间大，是因为每个表初始化完都是一个region,大量insert进来后需要进行分裂，消耗时间比较大；Raftstore cpu高问题由于Raftstore 还是单线程，测试中从监控指标看到CPU达到瓶颈是raftrestore线程；TiKV 性能中的“木桶原理”TiKV中一个节点的写入性能变慢会影响到整个集群的TPS与响应时间。上线改善措施优化表的定义与索引 表定义：不使用自增长列（自增长的rowid）作为主键，避免大量 INSERT 时把数据集中写入单个 Region，造成写入热点； 索引：使用有实际含义的列作为主键，
32、同时减少表不必要的索引，以加快写入的速度；对表的region进行强制分裂 查找表对应的region:curl http:/$tidb_ip:$status_port /tables/$schema/$table_name/regions 使用pd-ctl 工具split 对应表的region：operator add split-region $region_id 打散表的隐式id,打散表的数据分布:alter table $table_name shard_row_id_bits=6;表默认时间列改成由业务传具体值 对于写入表中的时间列，由业务逻辑传值进来，不依赖数据库取时间，减少PD TS
33、O分配03 正式上线后的配置组件分布与主机配置情况Service节点数说明TiDBPD83TiDB组件PD组件TiKVPumpDrainer5152Tikv组件Binglog 生成组件解析Bin logNode_export25主机IO,CPU，Memery 等监控Blockbock_exportGrafana251网络监控组件可视化展示Pushgateway1接收 Client Push 上来的数据PrometheusHost125监控数据存储物理主机03 正式上线后的配置生产架构PDPDTi KVTi KVTi KVPDPDPDPDDr ai nerPumpTi KVTi KVTi D B
34、 Ti D B Ti D BBi nl ogS QLTi D BTi D BTi D BTi D BTi D B 同城环境Dr ai nerPB文件Ti KVTi D B 生产环境Ti D B 生产环境Ti D B B i nl og04 遇到的问题2.0.10 版本下in不能下推到表过滤 问题2.0.10 下时区设置导致客户端不能连接Spring框架下TiDB事务问题2.0.10版本下 in不能下推到表过渡问题CREATE TABLE t1 (id int(11) NOT NULL,gid char(1) DEFAULT NULL,col1 int(11) DEFAULT NULL,col2
35、 int(11) DEFAULT NULL,PRIMARY KEY (id)CREATE TABLE t2 (id int(11) NOT NULL,gid char(1) DEFAULT NULL,col1 int(11) DEFAULT NULL,col2 int(11) DEFAULT NULL,PRIMARY KEY (id)表结构););执行计划2.0.10版本下 in不能下推到表过渡问题【解决办法】这个是2.0.10版本中的bug,在2.1后这个问题修复2.0.10 下字时区设置导致客户端不能连接【客户端报错】【客户端执行命令】【服务器端报错信息】tidbhost1:t0tidb_
36、d0:5010:tidb $mysql -h $IP -P $port -u root -D testERROR 1298 (HY000): unknown or incorrect time zone: CSTtidbhost1:t0tidb_d0:5010:tidb $【重启tiDB实例报错】2019/02/20 17:41:33.576 terror.go:328: fatal/home/jenkins/workspace/build_tidb_2.0/go/src/ or incorrect time zone: CST/home/jenkins/workspace/build_tid
37、b_2.0/go/src/ 下字时区设置导致客户端不能连接【原因】对不支持时区设置返回报错，为2.0.10中的bug，【解决办法】为能登录服务器解决这个问题，得绕开对时区的检查，重新编译了个TiDB-Server 登入服务器，把时区设置为正确的，然后使用tidb登录，2.1以后这个bug修复Spring 框架下 TiDB事务问题问题：重复保单号（业务要求每个保单号是唯一的）逻辑：取序列号，首先取当前DB最新值，然后更新，且更新时会带上刚查询出来的值作为更新条件。SQL: select SeqValue from tabupdate xxx_tab set SeqValue=SeqValue+1
38、 where SeqValue=xxx_cur_Value;例：已经更新成10002250207日志第213行，后面进来的线程取到的值还可能是10002250206.【currentSeqValue: 10002250206】Spring 框架下 TiDB事务问题【原因】TiDB 使用乐观事务模型，在高并发执行 Update 语句对同一条记录更新时，不同事务拿的版本值可能是相同的，由于不同事务只有在提交时，才会检查冲突，而不是像 Oracle，MySQL,PG那样，使用锁机制来实现对一记录的串行化更改。【解决办法】spring开发框架下，对事务的管理是使用注解式的，无法捕获到TiDB commit时的返回状态。因此需要将spring注解式事务改成编程式事务，并对commit状态进行捕获，根据状态来决定是重试机制，具体步骤：1.利用redis 实现分布式锁,执行SQL2.捕获事务commit状态，并判断更新成功还是失败：失败：影响行数为0 | 影响行数为1 & commit时出现异常成功：影响行数为1 & commit时无异常3未来规划未来规划 保险 银行 证券 互联网 多副本架构 大数据分析应用 基于容器的部署与应用 源码学习 工具开发 贡献社区丰 应用场景丰 部署架构技术提升Q &A
