汽车之家社区于 2005 年上线，作为之家最老的业务之一，十四年来沉淀了亿级帖子、十亿级回复数据，目前每天有千万级 DAU、亿级的访问量，接口日均调用量 10亿+次 。期间经历过架构升级重构、技术栈升级等，但其数据始终存放在SQL Server中，随着数据的不断递增，我们在使用SQL Server 数据库方面遇到了很多瓶颈，以至于我们不得不寻找一个新的数据库替换方案。
二、使用SQL Server遇到的瓶颈
随着业务的不断扩大，汽车之家社区的访问量和发表量不断上涨，遇到的数据库问题也越来越多，下面列举两个必须很快要解决掉的问题：
历史上，之家社区回复库采用了分库分表的设计，用以解决SQL Server单表过大的时候性能下降等问题。时至今日，回复库有100+个库、1000+张表（根据帖子ID分库分表）。这本身并没有问题，代码写好了，数据该写哪里写哪里，该读哪里读哪里。但是随着应用的发展、需求的变化，我们发现在实现某些需求时，分库分表的结构难以满足。我们需要数据逻辑上在一张表里。
近些年来，随着业务加速成长，数据量突飞猛进，而硬盘容量是有限的，每台服务器上能扩展的硬盘数量也是有限的。致使每隔一段时间都要增加更大容量的存储服务器来应对，而且这个事情一开始是很复杂的，涉及到很多关联项目，即便到现在我们轻车熟路了，每次换服务器的时候依然需要关注它，并且大容量数据库服务器价格昂贵。我们需要让扩容对应用来说，无感知。
三、分布式数据库调研3.1 确定方向
在2018年底的时候，公司专门成立了虚拟架构组来调研新的数据来解决之家社区遇到问题，经过各种分析和测试，今年年初确定方向为分布式数据库，一共调研了三款当前比较火的分布式数据库：TiDB(PingCap)、Ignite(ASF-TLP)、CockroachDB。经过无数次测试我们最终选择了TiDB，主要有以下几个原因：
兼容MySQL协议与生态，上手门槛低
跟TiDB官方一直保持比较好的技术沟通
TiDB公司在北京，有问题可以当面解决
TiDB的设计架构更加优秀
官方社区比较活跃，文档丰富
官方的技术人员经常到公司进行交流
下面引用TiDB官方的一段描述：“TiDB 是一款定位于在线事务处理、在线分析处理（ HTAP: Hybrid Transactional/AnalyticalProcessing）的融合型数据库产品，实现了一键水平伸缩，强一致性的多副本数据安全，分布式事务，实时 OLAP 等重要特性。同时兼容 MySQL协议和生态，迁移便捷，运维成本极低。“从中我们不难发现，TiDB切实的解决了我们在应用SQL Server时候的痛点：
水平伸缩：在当前集群内可以随时加节点，更换节点也轻而易举。
海量数据支持：基于其特性以及业内使用的经验，十亿乃至百亿级别的数据量轻松搞定。
高可用：相较SQL Server的主从模式，TiDB使用基于Raft协议，可以实现100%的数据强一致性，并且多数副本可用的情况下，可实现自动故障恢复。
HTAP：TiDB自身就支持一定程度的OLAP场景，更复杂的OLAP分析可以通过 TiSpark 项目来完成。对于更深度的OLAP应用，我们也已经在实践的路上。
3.2 实践出真知
基于以上理论的支持，我们进行了大量的功能测试、性能测试、异常测试、业务接入测试等。
OLTP测试：2000万数据，500并发线程测试，在OLTP场景测试下TiDB的响应时间99%在16ms以内，满足业务需求。且在数据量级越来越大的情况下，TiDB会体现出更大的优势，后续还可以通过添加TiDB/PD/TiKV节点来提高读写性能。
OLAP测试：50G TPC-H测试，TiDB相较MySQL有很大的速度优势。
Query
TiDB(second)
MySql(second)
1
201.89
1285.14
2
30.62
35.78
3
133.73
1789.76
4
31.47
311.68
5
600.01
553.70
6
77.13
298.15
7
78.81
818.32
8
512.43
1542.10
9
309.06
3478.29
10
48.31
595.37
11
37.86
201.42
12
600.01
385.05
13
121.17
648.64
14
68.92
336.48
15
0.01
1080.20
16
90.70
192.12
17
315.73
94.43
18
600.00
308.18
19
94.02
139.46
20
87.58
569.54
21
600.012
1410.61
22
62.07
47.89