TiDB数据库在金融核心系统的应用

1、TiDB数据库在金融核心系统的引入及应用目 录分布式数据库TiDB的引入TiDB应用实战 未来规划1分布式数据库TiDB的引入TiDB引入POC:基于2.0版本010206050403功能与架构SQL特性备份与恢复应用场景测试基准测试配置与管理TiDB 功能与架构ItemTiDB事务隔离级别SI组件/架构分为TiDB server,pdserver,Tikv server,需要分 别部署接口协议mysql客户端mysql数据库字符集UTF8MB4存储kvRocksDBRocksDB最小单位region复制协议raft应用场景OLTP,OLAP服务支持国内，社区TiDB SQL特性ItemTyp

2、eTiDBrow valueUNSIGNED INTCommon ExtensionSET, ENUMMySQL, PostgreSQL ExtensionConstraintsCheckStandardTransactionsForeign KeyStandardSAVEPOINTIndexesMultiple indexes per queryCommon ExtensionFull-text indexesCommon Extensionschema changesIndex renamesStandardCHANGE/MODIFY COLUMNStandardStatementsUPS

3、ERTPostgreSQL, MSSQL ExtensionClausesRETURNINGCommon ExtensionTiDB SQL特性ItemTypeTiDB说明Table ExpressionsTable and View referencesStandardRoadmap 支持table partitionStandardRoadmap 支持Value Expressions and Boolean FormulasMatching using POSIX regular expressionsCommon ExtensionPermissionsroleStandardRoad

4、map支持MiscellaneousCommon Table ExpressionsCommon ExtensionRoadmap支持Stored ProceduresCommon ExtensionfunctionAggregate functionCommon ExtensionPartialEncryption /decryption andCompression functionmysql Extensionwindow functionpostgreSQL, MSSQL,oralceExtensionRoadmap支持json ,jsonbPartial配置与管理测试TypeDMLT

5、iDB说明schema 对象查看数据库，表等对象大小在线添加列是否锁表TiDB DDL自动提交且不成回滚，不锁表不支持事 务在线更改列名是否锁表TiDB语法上支持，功能上暂不支持列重命名表重命名统计信息查看，收集与管理会话管理kill DML 场景1：普通 selectkill DML 场景2begin;mit事务当开启事务t1（insert 语句）后，另一个会话查不 到t1 的相关会话，这个时候如果另起一个窗口发 起一个查询 s1 select count(*) 这时查询一直在exec 状态，在发起一个cancel s1,发现cancel 不了，查询query 信息还是executing 状

6、态，如果 commit/rollback t1, s1 结束，提示已被cancelkill DDL集群管理节点添加节点删除SQL 优化器RBOCBO备份与恢复DB工具功能备份、恢 复方式是否开源说明TiDBmydumper/loader备份/还原全备，增备是1.数据导出：数据库总大小：150G 导出时间：1分钟，导出设置：（线程16，chunk64M）导出格式：sql,多个sql文件导出数据大小：64G2.恢复：备份数据文件大小：64G 表个数：32表数据库量：1.05千万Loader 并发数：64恢复时间：1h:44m: 21sTiDB-Binlog数据同步: 同步TiDB 集群数据到其 他

7、数据库实时备份和恢复: 备份TiDB 集群数 据，同时可以用于TiDB 集群故障时恢复是syncer从mysql 到tidb 增量同步数据,是TiDB-Lightning全量数据高速导入到 TiDB 集群的工 具，支持 mydumper 或 CSV 输出格式的数据源恢复所有数 据是2.1 版本后才发布基准测试基本信息：TiDB 版本：2.0.0测试工具：Sysbench 版本：1.0.12 并发数：1200基础数据：32个表/1千万 环境信息：主机cpuprocessorMemoryDisk主机1Intel(R) Xeon(R) CPU E5-2640 v4 2.40GHz24c251Gssd

8、主机2Intel(R) Xeon(R) CPU E5-2640 v4 2.40GHz24c251Gssd主机3Intel(R) Xeon(R) CPU E5-2640 v4 2.40GHz24c251Gssd测试架构：Host 1Ti KVTi KVTi KVLoad Bal ancerHapr oxyTi DBappPDPDPDTi KV集群Raf tTi DB集群Raf tPD集群Raf tRaf tHost 3Ti DBTi DB 压力测试架构（一）集群部分图例说明:主机组件存储节点数据同步Host 2 DC1Ti DB基准测试单条SQL性能备注1：模拟分析排名函数 Oracle/Pos

9、tgresql: SELECT id, k, c, rank() OVER (PARTITION BY k ORDER BY k) AS rn FROMsbtest1 ORDER BY k, 4 LIMIT 20 offset 2000;TiDBselect 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,

10、4 limit 20 offset 2000;DML测试数 据量TiDB执行时 间（s）说明select count(*)1千万2与oracle 相近insert1千万1001insert into select from1百万na事务太大，报错transaction is too large to commitdelete1百万naTiDB在delete时报错transaction is too large to commitdelete15w10update10万9.4update tbtest3 set k=1 where 1=1;分页查询1千万1.55SELECT id, k, c F

11、ROM test.sbtest1 LIMIT 20 OFFSET 200000;模拟分析函数 排名1千万19.27备注1基准测试sysbench测试350030002500200015001000500050000400003000020000100000109017025033041049057065073081089097010501130tpsqpsThreadsTiDB read onlytidb_qpstidb_tps1000800600400200005000100001500020000109017025033041049057065073081089097010501130tp

12、sqpsThreadsTiDB read writetidb_qpstidb_tps基准压力测试sysbench测试1200010000800060004000200001070130190250310370430490550610670730790850910970103010901150tps/qpsThreadsTiDB update indextidb_tpstidb_qps7000060000500004000030000200001000001070130190250310370430490550610670730790850910970103010901150tps/qpsthr

13、eadsTidb point selecttidb_tpstidb_qps基准压力测试sysbench测试050001000015000200001070130190250310370430490550610670730790850910970103010901150TPS/qpsThreadsTiDB update non indextidb_tpstidb_qps500004000030000200001000001070130190250310370430490550610670730790850910970103010901150tps/qpsThreadsTiDB deletetid

14、b_tpstidb_qps基准压力测试sysbench测试1400012000100008000600040002000010509013017021025029033037041045049053057061065069073077081085089093097010101050109011301170tidb inserttidb_tpstidb_qps应用场景测试产险xxxx查询分析场景测试基表信息(8个表)表名rowsxxxxx_mode399xxxxx_price_oper139,198xxxxx_dept_price4,457,797xxxxx_fits145,594xxxxx_s

15、eries1,415Xxxxx_facturer222xxxxx_category1,902xxxxx_brand228Select c1 c2,c3, c4,c5,c6 (select .from xxxxx1_ p1 where ) a1,(select count(0) from xxxxx2_ cs， xxxxx3_ dp) a2,.(此处省去16个select) from xxxxx_branda,xxxxx_manufacturerb,xxxxx_seriesc, xxxxx_category_series dWhereSQL应用场景测试DB时间优化后备注oracle134.8sn

16、/aTiDB49分35秒34S执行时间超过10分钟（默认值），报gc life time 小于事 务，需要更改这个值才可以执行完，优化点：从TiDB引擎底层优化执行计划小结010206050403功能与架构TiDB事务隔级别为SI ,支持Spark 生态,支持动态扩容，跨数据中 心部署SQL特性兼容mysql语法，2.0版本不支持窗口函数，分区表，视图，trigger等备份与恢复备份恢复工具均为开源，支持多 线程备份恢复，当前版本不支持 物理备份，loader 恢复时间偏长配置与管理支持在线DDL，2.0只支持串行的DDL,在优化器上支持CBO ，可以 支持复杂的SQL基准测试TiDB在单条S

17、QL的性能较好， 高并发场景下，性能较稳定， 但DML事务大小有限制。应用场景测试支持标量子查询，能支持非常复 杂的查询，查询引擎可朔性强2TiDB应用实战平安财神节活“暖宝保”业务活动背景业务需求压力测试遇到的问题0102030401 活动背景平 安 “ 财 神 节 ” 活 动 ： “财神节”是中国平安综合性年度线上金融狂欢节。2019年平安集团“财神节”活动于2019年1月8日正式启动， 涉及寿险，产险，银行，养老险，健康险，普惠，证券，基金，健 康互联，陆金所，壹钱包，互娱，不动产等多个领域，活动参与的BU数量，与推广的力度是历年之最。中国平安108财神节成绩单：“1.08单日成交额超过

18、1000亿” 单日交易额破千亿背后：几百个后台数据库实例的运维保障。平安财神节活“暖宝保”应用场景02 业务需求活动时间 : 2019年1月8日业务类别：以微服务的方式对接所有的个财个意互联网出单，包括移动app端、各种合作 伙伴对接出单业务场景 : 秒杀、红包雨性能要求：需要支持高并发、低延迟，高响应（可能会存在短时间的高峰），高可用，预估TPS:1000次 insert/s 、4000次 select/s 、 2250次 update/s ，TPS 延迟200ms系统级别：产险一类出单系统数据增长：一年存储量10TB，后续增长预估按照一年10TB增加，数据需在DB中保存25年， 预计需在D

19、B中保存2050TB的应用数据注：业务中保单价格低至19.9 元，且是互联网应用，业务反馈TPS存在不确定 性，可能远远大于以上评估值！DBA眼中的业务需求01并发量高，响应时间快，低延迟数据库存储的容量大，同时 需支持TP，AP业务业务 需求02数据库特性03?数据库TPS需求存在不确定性，数据 库层要求能按需求快速弹性 扩容数据库画像Type数据库弹性扩容TPAPSQLoracleNYYPostgreSQLNYYMySQLNYNSQLserverNYYMysql +中间件YYNNoSQLMongodbYYNHbaseYYN分布式数据库TiDBYYY时序数据库InfluxDBYN/AY内存缓

20、存RedisYN/AN/A内存数据库TimestenNYY图数据库Neo4jYYNMPPYellowBrickNYY使用TiDB挑战时间紧迫2018年12月17日2019年1月7日，20天时间内完成开 发测试到生产上线，时间短，风险大开发零使用经验现有开发大都是基 于传统oracle保险 业务，对于TiDB没 有使用经验并发量与扩容互联网业务并发需 求前期不可完全需 求，前期不能很好 的以实际压力进行 测试，与资源准备DB运维管理TiDB还处于生产落 地阶段，一类系统 尚未使用过TiDB, 没有大规模应用运 维经验03 压力测试测试工具：jmeterTiDB 数据库版本：2.0.10业务场景：

21、jmeter 直连DB,测试保单读写应用场景DB主机环境信息组件节点数分布机器说明TiDB3host1,host2,host3TiDB节点与PD节点布在其中的3台 机器上PD3host1,host2,host3Tikv315host1,host2,.,host91T/TikV节点，Tikv节点数据从3个节 点一直增加到15节点主机cpumemdiskhost124c384GSSDhost224c384GSSD24c384GSSDhost924c384GSSDTiDB节点信息：Host 1Ti KVTi KVTi KVNgi nxTi DBappPDPDPDTi KV集群Raf tTi DB集群

22、Raf tPD集群Raf tRaf tHost NTi DBTi DB 压力测试架构（一）集群部分图例说明: 主机组件存储节点数据同步Host 2 DC1Ti DB03 压力测试jmeter 直连DB,测试写保单场景（单条数据commit,实际为7个insert 为写一个保单）：客户端节 点数单个节点 写入/读 取数据量总数据量单个客 户端并 发数总并发个 数TPSTPS增长 率(同比 )TPS增长率(环 比)Transaction Avg(平均耗 时)Transaction Min(最小耗 时)Transaction Max(最大耗 时)transation 平均响 应时间环 比提升tran

23、sation 平均响 应时间同 比提升tidb实例 个数tikv实例 个数总耗时（s）总耗时（min）2100000020000005001000116484464173113717100:28:372100000020000005001000130912.46%12.46%74975193911.26%33915200:25:292100000020000005001000154132.39%17.72%63348317715.49%36915200:25:292100000020000005001000182056.36%18.11%53553287311.26%25.00%36.61%1

24、5.48%3910110:18:212100000020000005001000186660.31% 2.5327%2.62%315073100:17:5341000000400000050020002547118.81%36.50%7706141918.77% -47.79%315252900:42:090.00%50.00%100.00%150.00%0100020003000331515TPS69TiKV节点数TPS与TiKV节点数增加关系TPSTPS增长率(同比)TPS增长率(环比)60.00%40.00%20.00%0.00%-20.00%-40.00%-6

25、0.00%300025002000150010005000331515TPS/TPS平均响应时间69TiKV节点个数TPS及TPS响应时间与tikv关系TPStransation 平均响应时间环比提升Transaction Avgtransation 平均响应时间同比提升03 压力测试12SQL type节点数单个节点写入/读取数据 量总数据量单个并发数总并发个数TPS总和TPS增长率Transaction Min(ms)Transaction Max(ms)Transaction Avg(ms)transation平均响应时 间提升比tidb实例 个数tikv实例 个数insert31000

26、00030000005001500935713895159233read327419285822578563009002552517333333insert4100000040000005002000115023.06%1104006172133read229939475838789430060016954117013533insert458750623429455002000172349.84%463269113034.34%36read211306166226039673006001665919043536insert4100000040000005002000225030.57%5332

27、5787395.31%39read2221999034439580530060025004111472339insert4100000040000005002000272020.89%41311871717.87%312read215605068311013530060023418143625312insert41000000400000050020002528-7.06%4123107697.25%315read2447537168950743230060030979121715315jmeter 直连DB,测试写保单与查保单场景（单条数据commit,实际为7个insert 为一个保单，其

28、 中insert 与read 为同一个批次测试场景）：03 压力测试250.00%200.00%150.00%100.00%50.00%0.00%-50.00%300025002000150010005000331215TPS69tikv 节点数读写保单场景写保单tps与tikv节点关系TPS总和TPS同比增长率TPS环比增长率0.40.2030002500200015001000500033691215TPStikv节点数写保单tps延迟与tikv节点关系TPS总和transaction平均响应同比提升Transaction Avg (ms)transaction平均响应

29、环比提升jmeter 直连DB,测试读写保单中写保单场景：9SQL type节点数单个节点写入/读取数据 量总数据量单个并发数总并发个数TPS总和TPS同比增 长率TPS环比增 长率Transaction Min (ms)Transaction Max(ms)Transaction Avg(ms)transaction平均响应 同比提升transaction平均响应 环比提升tidb实例 个数tikv实例 个数insert3100000030000005001500935713895159233insert4100000040000005002000115023.06%23.06%110400

30、6172133insert45875062342455002000172349.84%84.40%463269113034.34%34.34%36insert4100000040000005002000225030.57%140.76%53325787395.31%49.27%39insert4100000040000005002000272020.89%191.06%41311871717.87%58.34%312insert41000000400000050020002528-7.06%170.51%4123107697.25%55.32%315调整Jmeter 中的事务控制开关autoc

31、ommit 为false,并在insert 最后添加commit,经测 试，4个节点，每个节点写50万数据，总的TPS为2000，时间响应时间为35ms以下， 下面是其中一个节点的监控情况：03 压力测试03 压力测试压力测试小结在select中即point select，TiDB的吞吐比较好；TiDB吞吐在insert场景下随着节点数的增加，TPS也会相应的增加，每增加3个节点TPS可提升12%20%左右，同时在相同TiKV节点数下，TPS与响应时间，此消彼长；弹性扩容业务中一个保单需要同时写7个表，7个表同时commit 比单表commit TPS 高,相同TPS 场景下延迟更小；批量提交

32、性能尤佳因在测试时没有预热数据（表为空表），对空表写入前几分钟，响应时间会比较大，约58分钟后响应时间趋于稳定。在前几分 钟内响应时间大，是因为每个表初始化完都是一个region,大量insert进来后需要进行分裂，消耗时间比较大；初始化region分裂耗时长由于Raftstore 还是单线程，测试中从监控指标看到CPU达到瓶颈是raftrestore线程；Raftstore cpu高问题TiKV中一个节点的写入性能变慢会影响到整个集群的TPS与响应时间。TiKV 性能中的“木桶原理”上线改善措施优化表的定义与索引表定义：不使用自增长列（自增长的rowid）作为主键，避免大量 INSERT 时

33、把数据集中写 入单个 Region，造成写入热点；索引：使用有实际含义的列作为主键，同时减少表不必要的索引，以加快写入的速度；对表的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;表默认时间列改成由业务传具体值

34、对于写入表中的时间列，由业务逻辑传值进来，不依赖数据库取时间，减少PD TSO分配03 正式上线后的配置组件分布与主机配置情况Service节点数说明TiDB8TiDB组件PD3PD组件TiKV51Tikv组件Pump5Binglog 生成组件Drainer2解析Bin logNode_export25主机IO,CPU，Memery 等监控Blockbock_export25网络监控组件Grafana1可视化展示Pushgateway1接收 Client Push 上来的数据Prometheus1监控数据存储Host25物理主机03 正式上线后的配置Ti DB生产环境PDPDPDPumpBi

35、nl ogTi KVTi KVTi KVTi DBTi DBDr ai nerSQLTi DB同城环境Ti KVTi KVTi KVTi DB Bi nl ogTi DBTi DBTi DBTi DBPDPDPDTi DBDr ai nerPB文件Ti DB生产环境生产架构04 遇到的问题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(1

36、1) DEFAULT NULL,col2 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_d0:5010:tidb $mysql -h $IP -P $port -u root -D test ERROR 1298 (HY000): unknown or incorrect time zone: CST tidbhost1:t0tidb_d0:5010:tidb $【重启tiDB实例报错】2019/02