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 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 生态
○ 向下衔接大数据生态圈
标签：02,场景,综述,业务,实时,OLTP,TiDB,一致性 来源： https://www.cnblogs.com/luckyplj/p/15150761.html