TiDB 适用场景 不适用场景 及其被替代的产品

TiDB 适用场景：
1.强一致性分布式事务： 
  可以把 TiDB 想象成一个单机的 RDBMS，ACID 事务可以在多节点间进行，无需担心一致性问题。 TiDB 对业务
没有任何侵入性，是传统的数据库中间件、数据库分库分表等优雅的替换方案。
 重点解决 MySQL 的单机性能和容量无法线性和灵活扩展的问题.

2.数据归档库：
  若存储不足的时候可以水平扩展机器，TiDB的存储量大，归档的时候可以无需考虑磁盘空间。
  配合TiDB的工具(syncer\mydumper\loader 和TIDB DM)可实现自动归档，当然也无需要考虑源库的操作。
  顺序写入的场景：日志写入、数据审计、财务流水

3.MySQL单库超过亿行级别的表较多，否则量级达不到性能不如MySQL。至少是5000万行级别以上的。

4.业务爆发式增长，有高并发，业务量增长较快。
 
5.OLAP：
 TiDB 本身的SQL对OLAP支持有限制，需要结合TiSPark.在TiDB3.0之前不支持view，不支持windows functions，
CTE也不支持，TiDB自身对OLAP查询有限。由于TiDB优先OLTP，借鉴Google的 spanner，
对批量INSERT、UPDATE、DELETE操作单次限制在30万行，需要手动修改参数支持DML大批量操作。
  
6.MySQL+MyCAT 这种分库分表的数据合并：
  MySQL+MyCAT的可支撑单表10亿级别的业务，但是需要配置MyCAT等数据库中间件,比较繁琐。
  由于TiDB自身就支持自动分片的功能，可以替换MySQL+MyCAT这种方案。
7.异地多中心、auto-Failover保证数据库高可用:
  TiDB 使用多副本进行数据存储，并依赖业界最先进的 Raft 多数派选举算法确保数据 100% 强一致性和高可用。 副本
可跨地域部署在的不同的数据中心，主副本故障时自动切换，无需人工介入，自动保障业务的连续性，实现真正意义上
的异地多活。不过在实际部署异地多活的时候还是需要考虑网络传输等因素.
8.数据量大时,水平弹性扩展:
 分布式的 TiDB 可随着你的数据增长而无缝地水平扩展，只需要通过增加更多的机器来满足业务增长需要，应用层可以
不用关心存储的容量和吞吐。 TiDB 根据存储、网络、距离等因素，动态进行负载均衡调整，以保证更优的读写性能。

TiDB 不适用场景：
1.MySQL单表存储数据在亿级别以下的时候，MySQL+MyCAT方案性能要比TiDB高。
2.资金预算紧张的情况下，运行一个TiDB集群至少需要6台高配SSD硬盘的主机(建议支持NVME协议)
 随着时间的推移和硬件的发展，硬件成本会降低。
3.TiDB on cloud
  虽然有TiDB operator 项目，但是截至2019年3月还不稳定和性能不足，不推荐运行在生产的kubernetes集群。
 尚在PoC阶段。但是Cloud DB 是大势所趋。
4.要求100%不修改源代码迁移应用从MySQL迁移到TiDB。
这个主要是TiDB目前对MySQL的函数和功能的兼容性不足导致的。预期TiDB 3.0会兼容MySQL8.0版本大部分功能。

TiDB 不足的地方：
1.宣称HTAP，对于OLAP支持还需要大力发展 ,一般OLAP是列存计算上有比较大的优势,如何在一个数据库里做到行存和列存共存是需要解决的。
2.采用RocksDB 作为存储引擎，其自身存在写放大缺陷(Write Amplification )
3.由于是兼容MySQL的语法，而不是标准SQL，对一些高频SQL语句(merge、full join等)支持不足
4.TiDB作为OLAP应用的时候，若OLTP和OLAP放置到一起对业务影响还是会较大的，需要做资源限制。尚需TiDB的
开发人员努力优化的，作为宣称的HTAP性能有待商榷和验证。



业界采用的方案：
BAT三家有自己开发的对应的云数据库，国内的TMD(toutiao、meituan\xiaomi、didi)等互联网企业均有使用.

https://pingcap.com/cases-cn/


被替换的产品：
1.TiDB替换掉MySQL+MyCAT
2.TiDB替换掉Hbase
3.TiDB替换掉 
4.替换掉OLTP和OLAP是两套存储和计算的方案

TiDB 畅想：
1.如何提升OLAP的性能？支持列存数据库
2.对于新兴的硬件的支持如GPU加速、FPGA.
3.生产级的TiDB on kubernetes
4.SQL标准的支持而非MySQL的SQL 方言

参考：

https://blog.bcmeng.com/post/tidb-application-htap.html