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 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.2 典型案例平安财神节活动“暖宝保”案例

活动业务场景- 暖宝保的业务特点：
● 参与门槛低：暖宝保这个业务保费价格低至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 生产库
　　○ 透明无障碍的跨分片查询
　　○ 数据实时落地
　　○ 海量存储允许多数据源汇聚
　　○ 备库-中台分析二合一

2.1 分布式计算框架- TiSpark

● 借助TiSpark
○ Spark 是成熟的计算平台
○ 继承Apache Spark 生态
○ 向下衔接大数据生态圈