我本身是一名云原生运维工程师，日常工作更多围绕 Kubernetes、容器、网络、存储、监控以及各类云原生组件展开。过去虽然也接触过数据库相关工作，但更多集中在安装部署、监控、备份恢复、故障处理等基础运维操作，对于数据库内部原理并没有进行过特别系统的学习。
此外，我也接触过 Doris、ClickHouse 等 MPP 数据库，因此对于分布式存储、数据分片、副本、高可用、MPP 查询等概念并不完全陌生。但真正体系化学习 TiDB 之后，我发现 TiDB 将分布式数据库、云原生、事务、存储、计算等多个领域很好地结合到了一起，对我原有的技术知识体系也是一次很好的补充
一、为什么选择 TiDB？
选择 TiDB，一方面是因为它和我目前的技术方向有比较高的契合度。（大家都是GO写的嘛：）
作为一名云原生运维工程师，我平时接触的很多系统都在向分布式、容器化、平台化方向发展，而数据库作为应用系统最核心的基础设施之一，也正在经历类似的变化。
传统数据库虽然已经可以很好的满足需求，但是业务规模和应用形态的变化，数据库也面临者容量性能水平扩展等调整，但是由于习惯了传统数据库一致性和数据的正确性等，分布式场景下也需要解决类似的问题，这样数据库上云就更容易一些。
TiDB 本身就是一个面向分布式场景设计的数据库系统，其架构中包含 TiDB、TiKV、PD 等多个组件，同时结合了 Raft、副本机制、分布式事务、Region 调度、TSO 等技术。这些内容与我之前学习 Kubernetes、etcd、分布式系统时接触到的一些知识有很多共通之处。
二、学习 TiDB 的意义
对我来说，学习 TiDB 最大的意义并不仅仅是会使用一个新的数据库，而是帮助自己补齐数据库和分布式系统方面的知识体系。
过去做云原生运维时，我更多关注的是容器或者应用层面的问题，但是在很多实际故障中，问题并不会只停留在容器或操作系统或者应用这一层。
例如应用出现响应缓慢，可能进一步涉及应用连接数据库，读写数据库，数据存储等问题。
如果只掌握基础设施层面的知识，那么很多时候只能判断“资源没有问题”，却无法继续向数据库内部深入分析。
通过学习 TiDB，可以进一步理解SQL执行、优化器，TiDB如何读写KV，KV如何管理Region，Raft机制，PD调度等等。
这些知识不仅仅适用于 TiDB，很多核心概念，例如 Raft、MVCC、LSM-Tree、分布式事务、存算分离、MPP、SQL Optimizer，本身就是分布式数据库领域的通用知识。
因此，我认为学习 TiDB 实际上也是一个非常好的分布式数据库学习入口。
三、学习 TiDB 的体验和收获
目前完成 PCTA 学习之后，我最大的感受之一，就是 TiDB 的学习生态比较完善。
对于刚开始接触 TiDB 的人来说，可以比较容易找到从入门到深入的学习路径，有很多官方资料和学习视频，社区活跃度也比较高，相比单纯阅读数据库原理书籍，这种学习方式对运维工程师来说更加友好。
因为很多知识都可以通过“理论 + 实验”的方式进行验证，例如学习 TiDB 架构时，可以自己搭建一个 TiDB 集群，再进一步通过日志、监控、SQL 执行计划以及各类管理命令观察系统行为。
这种学习方式比较符合运维工程师的习惯，不仅要知道是什么，还希望知道系统真正运行起来以后，到底发生了什么？
另外，在学习 TiDB 的过程中，我也逐渐发现，过去接触 Doris、ClickHouse 的经验能够帮助理解 TiDB 中的一些设计，TiDB 和 Doris、ClickHouse 的定位并不完全相同。Doris、ClickHouse 更多面向分析场景，而 TiDB 更强调分布式关系型数据库能力以及 HTAP。
目前通过 PCTA，我认为自己已经建立起了一个比较基础的 TiDB 知识框架，但距离真正深入理解还有很长的距离。
接下来我计划继续准备 PCTP，并把学习重点逐渐从“知道 TiDB 有哪些组件”转向“理解这些组件为什么这样设计”。
同时，我也希望进一步学习 Talent Plan。相比认证考试，Talent Plan 更偏向底层原理和工程实践，我认为这对真正理解 TiDB 会非常有帮助。
四、所在行业 TiDB 的适用场景
从我接触的企业 IT 和云原生运维场景来看，适应场景有：
1.数据持续增长量大，点查和报表分析兼顾的业务
2.信创要求的业务（主要是这个场景，哈哈）