TiDB功能
TiDB的核心功能包括弹性水平可伸缩性，具有ACID保证的分布式事务，高可用性以及实时事务数据的实时分析。让我们来看看这些功能背后的平台架构。TiDB平台具有以下组件：
TiDB：与Go兼容的无状态SQL层，内置于Go。
TiKV：一个分布式事务键值存储，用Rust构建。（TiKV最近成为云原生计算基金会项目。）
TiSpark：一个Apache Spark插件，连接到TiKV或专门的柱状存储引擎（我们正在努力...继续关注）。
放置驱动程序（PD）：由Etcd提供支持的元数据集群，用于管理和计划TiKV。
TiKV是基础层。这是所有数据被保留，自动分区为较小的块（我们称之为“区域”），并通过执行Raft共识协议自动复制并强烈一致的地方。使用PD，Placement Driver，TiKV可以跨节点，数据中心和地理位置复制数据。它还可以在热点形成时动态删除它们，并拆分或合并区域以提高性能和存储使用率。我们在TiKV中实现基于范围的分片，而不是基于散列的分片，因为我们的目标从一开始就是支持功能齐全的关系数据库。因此，TiKV支持各种类型的扫描操作 - 表扫描，索引扫描等。
TiDB中的无状态SQL层可以处理100％的联机事务处理（OLTP）工作负载和80％的常见，临时，联机分析处理（OLAP）工作负载。这个无状态SQL层展示了定期的性能改进（参见我们最新的TPC-H基准测试），利用TiKV的分布式特性，通过协处理器层执行并行处理，同时将部分查询推送到不同的TiKV节点。
对于更复杂的OLAP工作负载，例如用于培训机器学习模型或实时商业智能收集的迭代分析，第二个无状态SQL层-TiSpark-报告职责，也直接从TiKV绘制数据。TiDB说MySQL，TiSpark暴露了Spark SQL。
TiDB平台架构
TiDB架构
您可能已经注意到，整个TiDB平台都是模块化的 - 所有组件都是独立的代码库，并且松散耦合。您可以将整个TiDB平台部署为一个完整的软件包（大多数用户都可以），或者根据您的需要将其部分部署。这种模块化架构为用户提供了最大的灵活性，并符合云原生架构的标准。根据CNCF的官方定义，云原生技术是“能够实现弹性，可管理和可观察的松耦合系统”。
作为TiDB用户，您可以扩展无状态SQL服务器或TiSpark层（即您的计算资源），或者独立于扩展TiKV（即您的存储容量），允许您充分利用您正在消耗的资源以适应您的工作负载。您几乎可以将TiDB无状态SQL服务器视为位于TiKV之上的微服务，TiKV是一个持久保存数据的有状态应用程序。这种设计使隔离错误更容易，滚动升级和维护更快，破坏性更小。
对这些TiDB优势的权衡是部署和监控的一些额外的复杂性 - 只需要跟踪更多的部分。然而，随着Kubernetes的兴起和CoreOS开创的运营商模式，部署和管理TiDB简单，直接，并且越来越自动化。Kubernetes的开源TiDB运算符允许您在任何云环境（公共，私有或混合）中部署，扩展，升级和维护TiDB。TiDB默认安装Prometheus和Grafana，因此监控“开箱即用”。（请参阅我们的TiDB操作员教程。）
最终，技术资产的灵活可扩展性对于业务成功至关重要。这是成为下一个Facebook和下一个Friendster之间的区别。TiDB模块化和Kubernetes编排允许您为数据库服务带来灵活的可伸缩性。
最后，让我们看一下TiDB的三个主要用例：MySQL可伸缩性，HTAP实时分析和统一数据存储。
监控TiDB部署的示例Grafana仪表板
TiDB用例：MySQL可伸缩性
因为TiDB说MySQL - 它兼容MySQL线程协议和MyDumper和MyLoader等MySQL生态系统工具 - 它非常适合那些无法扩展的MySQL用户。需要明确的是，TiDB不是MySQL的替代品; 相反，它补充了MySQL。MySQL作为单实例数据库仍然是一个很好的选择，因此如果您的数据大小或工作量很小，请坚持使用MySQL。但如果您对这些问题感到头疼：
考虑如何复制，迁移或扩展数据库以获得额外容量
寻找优化现有存储容量的方法
关注慢查询性能
研究中间件扩展解决方案或实施手动分片策略
然后，现在是开始考虑使用像TiDB这样的分布式SQL数据库的合适时机，它可以为您解决所有这些问题。MySQL分片解决方案的缺点是Mobike是世界上最大的无码头自行车共享平台之一，它采用了TiDB（阅读Mobike案例研究）。Mobike在200个城市运营着900万辆智能自行车，为2亿用户提供服务，因此不难想象其团队在MySQL方面遇到的扩展瓶颈。Mobike通过部署TiDB和MySQL以及PingCAP的企业工具套件（包括Syncer）来解决其对弹性可扩展性的需求，后者自动将MySQL主服务器与TiDB集群同步。
TiDB与其他MySQL兼容数据库之间的关键区别是TiDB的分布式架构。MySQL是一项已有23年历史的技术，从未打算用作分布式系统。例如，与TiDB不同，MySQL无法生成查询计划，将部分查询同时压入多台计算机以进行并行处理。TiDB的SQL解析器，基于成本的优化器和协处理器层是从头开始构建的，以利用分布式数据库的计算资源和并行性，因此MySQL用户可以拥有更多的功能。
TiDB用例：HTAP实时分析
HTAP（混合交易和分析处理）是由Gartner在2014年创造的一个术语，描述了一种打破事务和分析数据工作负载之间隔离墙的数据库架构。目标是为企业提供实时分析，从而实现实时决策。其他行业分析公司已经为这种架构提出了自己的术语-451 Research的“ HOAP ”（混合操作分析处理），Forrester的“ Translytical ”和IDC的“ ATP ”（分析事务处理）。
正如我们所讨论的那样，TiDB通过解耦其计算层和存储层，并使用不同的无状态SQL引擎（TiDB和TiSpark）来完成不同的分析任务，从而打破了OLTP和OLAP之间的隔阂。两个引擎都连接到同一个持久性数据存储（TiKV），使得实时分析和决策成为系统的自然产品。繁琐的ETL过程被最小化，“t + 1”延迟不再只是生活的一部分，并且TiDB内部的数据可以比以前更有创造性地使用。
Yiguo.com是一个为500万用户提供服务的大型新鲜农产品交付平台，它在TiDB上运行Apache Spark（阅读Yiguo.com案例研究）以加速复杂查询。通过从SQL Server升级其基础架构并利用TiDB加强其现有的MySQL部署，Yiguo.com可以在中国最大的网上购物日光棍节那天全天候以高性能运行复杂的连接，以获得洞察力并实时做出决策。
TiDB用例：统一数据存储
作为分布式模块化HTAP数据库，TiDB旨在横向和灵活地扩展计算和存储容量，以适应不同的工作负载，同时还可作为“单一事实来源”。通过在键值之上提供可扩展的SQL服务在商店中，TiDB旨在显着降低与维护基础架构堆栈中的数据管理层相关的人力和技术成本。
对于世界上最大的食品配送平台之一Ele.me来说，统一数据存储是采用TiDB和TiKV的关键原因之一（阅读Ele.me案例研究））。以前，Ele.me的数据分散在许多不同的数据库中--MongoDB，MySQL，Cassandra，Redis。最终，由于运营和维护成本增加，这种临时堆栈变得难以维持。现在，来自大约2.6亿用户的Ele.me的80％实时流量由单个TiKV部署提供服务。这个TiKV集群横跨四个数据中心，每个数据中心都有100多个节点，可存储数十TB的数据 - 始终可用，始终可用。