TiDB学习笔记02-场景案例综述

1 TiDB 产品核心价值点和主打场景

HTAP 的定义：Hybrid Transactional/Analytical Processing，混合事务分析处理

数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。

TiDB 典型应用场景
● 海量数据高并发OLTP系统
　　○ 不再分库分表，不再使用妥协的数据库中间件，业务不再受制于基础架构
● 海量数据高性能实时分析
　　○ 兼容MySQL，大数据量下比MySQL 快1~2 个数量级的融合OLTP 和OLAP 的HTAP 数据库
● 多源高吞吐汇总与实时计算
　　○ 多源（数十至数百异构数据源）高吞吐（数十万QPS）汇聚写入AD-Hoc 准实时查询
● 实时数仓
　　○ 通过TiSpark 无缝连接Spark，无需ETL，提供实时的大规模复杂OLAP 分析查询能力。
● 金融级别多数据中心多活
　　○ 故障自动恢复、无需人工介入的真正意义上的高可用
● 云数据库（DBaaS）
　　○ 同Kubernetes、Docker等容器技术完美整合，自动调度有状态的服务

1.1 常用术语

(1)高可用

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是集群化，或者叫冗余：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。

(2)高并发

高并发(High Concurrency)通常是指通过设计保证系统能够同时并行处理很多请求。通俗来讲，高并发是指在同一个时间点，有很多用户同时的访问同一 API 接口或者 Url 地址。它经常会发生在有大活跃用户量，用户高聚集的业务场景中。

1.2 OLTP 场景

(1)OLTP 场景

● 场景特点
　　○ 高频SQL
　　○ 数据量中等
　　○ 相应延迟低
　　○ 读多写少
● 关注点
　　○ 高可用
　　○ 故障自动修复
　　○ 在线变更schema
　　○ 多点写入

(2)金融OLTP 场景
● 场景特点
　　○ 数据一致性
　　○ 事务一致性
　　○ 业务连续性
● 关注点
　　○ 传统OLTP 所有点
　　○ 强一致性
　　○ 高并发、高性能
　　○ 故障容错性
　　○ 跨地域多活、容灾故障自动修复

(3)分库分表集群
● 待解决的问题
　　○ 扩展=拆分，拆分必然侵入
业务
　　○ 业务需要改造SQL
　　○ 多维度的查询困难
　　○ 二次拆分困难
　　○ 很难实现分布式事务
　　○ 同时维护多份schema

(4)TiDB 对比中间件

从某种角度上讲，Tidb是一种大号的Mysql。、

(5)OLTP 场景的TiDB 方案

TiDB 场景优势
　　○ 数据一致性保证
　　○ 在线DDL
　　○ 支持多点写入
　　○ 自动故障检测、选主、转移
　　○ 计算存储分离，快速扩容读优点
● TiDB 场景劣势
　　○ 网络交互多，导致延迟增大
　　○ 读写共用leader
　　○ 有机器硬件要求（万兆网+ SSD）

(6)OLTP 场景的TiDB 方案

● 强一致性多副本技术
　　○ region 拆分一致性
　　○ 数据迁移一致性
　　○ 灵活控制副本位置
　　○ 网络、节点故障容错
● 线性横向扩展
　　○ 存储空间
　　○ 计算能力
● 分布式事务
● 多数据中心多活（表级别多点写入）

1.3 典型案例平安财神节活动“暖宝保”案例

活动业务场景- 暖宝保的业务特点：
● 参与门槛低：暖宝保这个业务保费价格低至19.9
● 推广力度很大：以微服务的方式对接如平安健康、好福利、平安银行、陆金所等所有APP端
● 典型的互联网活动形式：如秒杀、红包雨，所以对数据库的要求是高并发、低延迟、高响应、高可用，

容量规划：
● 2-5 年在线数据存储量预计达到20~50 TB

项目挑战：
● 时间紧迫：2018年12月17日~2019年1月7日，20天时间内完成开发测试到生产上线，时间短，风险大
● 开发零使用经验：现有开发大都是基于传统Oracle 保险业务，对于TiDB 没有使用经验
● 并发量与扩容：互联网业务并发需求前期不可完全需求，前期不能很好的以实际压力进行测试，与资源准备

2 HTAP 场景

中台业务场景
● 业务需求
　　○ 我们数据孤岛很痛
　　○ 我们分片多维度查询很痛
　　○ 我们需要静态数据Join 动态数据
　　○ 我们需要完整SQL 语义、支持复杂SQL
　　○ 我们需要便于增量更新、索引维护
　　○ 我们需要便于从binlog实时同步
● TiDB 非常适合中台场景
　　○ 协议兼容，轻松同步MySQL 生产库
　　○ 透明无障碍的跨分片查询
　　○ 数据实时落地
　　○ 海量存储允许多数据源汇聚
　　○ 备库-中台分析二合一