共计 3222 个字符，预计需要花费 9 分钟才能阅读完成。
导读
Catalyst 是一家总部位于纽约的 SaaS 守业公司，它提供了一个直观且灵便的客户胜利平台（Custom Success Platform），可帮忙客户胜利团队汇聚客户数据，洞悉客户健康状况，推动客户留存和业务增长。目前 Catalyst 已实现了 B 轮融资。
本文为“寰球极限场景与翻新场景应用 TiDB 的最佳实际”专题第三篇，分享 TiDB 如何为 Catalyst 升高了保护老本并提供更好的客户体验。
业务特点
Catalyst 整合了来自包含 Salesforce、Mixpanel、PostgreSQL 等不同起源的海量数据，并将其纳入 Catalyst 生态系统中进行解决、剖析并生成可参考执行的数据洞察。
Catalyst 次要解决三种类型的数据：事务型数据、只读数据和时序数据。
- 事务型数据次要包含外部创立的笔记和工作，以及从 Salesforce、Zendesk 和其余平台收集的内部数据。
- 只读型数据次要是指从 Jira 和 Zendesk 等平台收集的工单数据。
- 时序型数据是 Catalyst 最重要和最辣手的数据类型之一。能解决这一类型的数据，也是 Catalyst 团队数据库选型的重要需要之一。
以前的数据架构及其瓶颈
Catalyst 最后应用 PostgreSQL 来解决从内部收集的所有数据。然而，随着其业务的增长和数据源的迅速扩充，PostgreSQL 无奈跟上其需要。Catalyst 最后试图通过将数据存储为 JSON 文档来补救这一缺点，但查问性能受到了重大影响。
随后，该团队转向了 pre-caching 计划。他们采纳 Elasticsearch 来存储后果，以便更快地响应客户的查问。然而，因为 Elasticsearch 不反对 SQL 格调的 JOIN，Catalyst 必须在将所有内容存储在 Elasticsearch 之前进行预计算。随着存储数据量减少，老本也急剧回升。
为了解决这些问题并拓展业务增长，Catalyst 团队决定从新设计整个数据处理和存储系统。他们也是这个时候发现了新一代分布式关系型数据库 TiDB。
数据层重构
Catalyst 的新架构分为五个数据层：数据摄取层、数据湖层、Spark 层、数据服务层和 Web 应用层。原始数据通过摄取层进入，并持续进入数据湖层。Spark 层组合数据对象，执行预计算，确保数据有意义。数据服务层存储所有预处理过数据以供客户查问。因为间接影响用户体验，数据服务层对 Catalyst 来是最重要的，也成为 Catalyst 对新数据栈迫切需要的中央。数据服务层以下的各层不须要是实时的。然而，在数据服务层，Catalyst 须要亚秒级的提早，以便客户可能迅速取得后果。
新技术栈的必备能力
为了服务一直增长的客户，Catalyst 迫切需要一个具备以下个性的数据库：
反对 混合事务型和剖析型工作负载。Catalyst 必须处理事务型和只读数据，以及时序数据。他们须要的解决方案，无论是繁多的数据库还是一个数据库组合，必须可能同时解决交易型和剖析型工作负载。
疾速响应。新的数据库解决方案必须比 Catalyst 以前的解决方案更灵便，特地是在查问速度和用户界面性能方面。它必须在几秒钟内对查问作出反应，并具备较低的更新延时。
解决简单和高度定制的数据。Catalyst 的客户能够在 Catalyst 平台外部以及 Salesforce 和 Zendesk 等数据源平台上自定义许多设置，包含查问、数据转换和关系。与许多自定义字段集成的自定义对象的组合可能相当简单。新的解决方案必须可能解决这种状况。
高可用。Catalyst 须要对他们的客户作出麻利的反馈。维持零碎运行是 Catalyst 的首要任务。一旦 Catalyst 宕机，客户往往几十秒内就会投诉。因而，新的数据库解决方案必须是高度可用的，以帮忙 Catalyst 轻松应答任何可能的零碎事变。
程度扩展性。可扩展性是另一个必须具备的条件。Catalyst 解决的数据量十分大，而且数据量还会不断扩大。数据库解决方案必须易于扩大到微小的规模。
数据强一致性。数据一致性是另一个要求。但思考到有如此多的数据处理在流中进行，要在整个零碎中保持数据强一致性是十分艰难的。因而 Catalyst 能够承受最终一致性（Eventual Consistency）。
TiDB 在性能测试中怀才不遇
Catalyst 在抉择新的数据库时十分审慎；他们调研了 TiDB 和另外两种抉择：Aurora 与 AWS Timestream 联合，以及 YugaByte 与 AWS Timestream 联合的计划。这些选项是联机事务处理（OLTP）数据库和时序数据库的组合。
为了测试这三个候选解决方案，Catalyst 采纳来自外部 Salesforce 和 Jira 实例的大型实在数据集作为负载，通过间断并行的形式运行分组查问。查问响应速度是最重要的评估规范之一。
TiDB 对典型查问和聚合查问的响应工夫都在几秒钟之内，比其余候选解决方案快得多。同时，TiDB 对时序聚合查问的体现也足够灵便麻利，7 秒内返回后果。下表总结了一些要害的测试后果。
查问的类型有：
- 典型查问：客户最感兴趣的查问。
- 聚合查问：次要是基于简单 JOIN 的计算。
- 时序聚合查问：Catalyst 没有在 Aurora 和 Yugabyte 解决方案上测试时序聚合查问，因为工夫无限，而且 TiDB 的性能对他们来说曾经足够印象粗浅。
| 查问速度 (s) | |||
|---|---|---|---|
| 要害指标 | Aurora & AWS Timestream | YugaByte & AWS Timestream | TiDB |
| 代表查问 | ~30 | ~3 | |
| 聚合查问 | ~120 | ~2 | |
| 时序聚合查问 | 未测试 | ~7 |
要害测试后果
为什么抉择 TiDB？
查问响应快
依据查问类型的不同，TiDB 的响应工夫比其竞争对手快 10 到 60 倍。这是 Catalyst 抉择 TiDB 的最重要起因。
完满反对在线 DDL
TiDB 反对在线数据定义语言（DDL）操作，且不会影响在线业务。TiDB 提供无忧的模式变动，并容许 Catalyst 更快地增加或删除索引，特地是对于大表。当他们遇到慢查问并须要疾速增加索引以进步性能时，这尤其有用。通过在线模式变更，Catalyst 毋庸停下在线业务或预留长时间的保护窗口。
HTAP 混合负载数据库
TiDB 是一个混合事务和剖析解决的（HTAP）数据库。在 Catalyst 评估的三个候选项中，TiDB 是惟一一个技术栈能够同时解决对象数据和时序数据的数据库。这不仅十分高效，而且还为 Catalyst 节俭了大量的工夫、精力和金钱。
程度扩展性
TiDB 具备高度的程度扩展性。这完满地满足了 Catalyst 应答不断扩大的数据量的业务需要。TiDB 还反对计算和存储资源拆散，这使得 Catalyst 能够独自扩大这两种资源，也有助于管制老本。
疾速的容灾复原
TiDB 应用 Raft 共识算法来确保数据的高度可用性和平安复制。TiKV 是 TiDB 的存储服务器，数据在 TiKV 节点之间进行冗余复制，并搁置在不同的可用区域，以避免机器或数据中心故障。这确保了 Catalyst 的零碎失常运行工夫。此外，TiDB 提供了多种劫难复原计划的抉择，每一种计划都实用于不同的场景，老本灵便。
全面的托管服务
Catalyst 有一个小的 DevOps 团队，所以他们须要一个齐全托管的数据库解决方案，以加重团队的累赘并管制老本。TiDB 的全托管服务 TiDB Cloud 满足了这一需要。
云中立
Catalyst 的服务采取跨云部署的形式以保障其业务的灵活性：一些工作负载在谷歌云平台（GCP）上运行，一些在亚马逊（AWS）上运行。因而，他们须要一个反对多云部署的云数据库解决方案。TiDB Cloud 正是这样的解决方案。
总结
Catalyst 之前次要应用 PostgreSQL 来解决客户数据，但零碎很快遇到了瓶颈。他们从新设计了数据架构，并引入新的数据库来为客户提供数据。通过采纳 TiDB, Catalyst 可能提供更好的客户体验，包含更快的查问响应、更有弹性的零碎、更弱小的数据存储、解决和剖析能力。Catalyst 还升高了它们的整体保护老本。
