TiDB x Catalyst 丨秒级洞悉数据价值，TiDB 帮助“客户成功 SaaS 厂商”提升用户体验

作者： TiDB 社区小助手原文来源：https://tidb.net/blog/23fdc5f6

导读

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 的性能对他们来说已经足够印象深刻。

为什么选择 TiDB ？

1. 查询响应快

根据查询类型的不同，TiDB 的响应时间比其竞争对手快 10 到 60 倍。这是 Catalyst 选择 TiDB 的最重要原因。

1. 完美支持在线 DDL

TiDB 支持在线数据定义语言（DDL）操作，且不会影响在线业务。TiDB 提供无忧的模式变化，并允许 Catalyst 更快地添加或删除索引，特别是对于大表。当他们遇到慢查询并需要快速添加索引以提高性能时，这尤其有用。通过在线模式变更，Catalyst 无须停下在线业务或预留长时间的维护窗口。

1. HTAP 混合负载数据库

TiDB 是一个混合事务和分析处理的（HTAP）数据库。在 Catalyst 评估的三个候选项中，TiDB 是唯一一个技术栈可以同时处理对象数据和时序数据的数据库。这不仅非常高效，而且还为 Catalyst 节省了大量的时间、精力和金钱。

1. 水平扩展性

TiDB 具有高度的水平扩展性。这完美地满足了 Catalyst 应对不断扩大的数据量的业务需求。TiDB 还支持计算和存储资源分离，这使得 Catalyst 可以单独扩展这两种资源，也有助于控制成本。

1. 快速的容灾恢复

TiDB 使用 Raft 共识算法来确保数据的高度可用性和安全复制。TiKV 是 TiDB 的存储服务器，数据在 TiKV 节点之间进行冗余复制，并放置在不同的可用区域，以防止机器或数据中心故障。这确保了 Catalyst 的系统正常运行时间。此外，TiDB 提供了多种灾难恢复方案的选择，每一种方案都适用于不同的场景，成本灵活。

1. 全面的托管服务

Catalyst 有一个小的 DevOps 团队，所以他们需要一个完全托管的数据库解决方案，以减轻团队的负担并控制成本。TiDB 的全托管服务 TiDB Cloud 满足了这一需求。

1. 云中立

Catalyst 的服务采取跨云部署的方式以保证其业务的灵活性：一些工作负载在谷歌云平台（GCP）上运行，一些在亚马逊（AWS）上运行。因此，他们需要一个支持多云部署的云数据库解决方案。TiDB Cloud 正是这样的解决方案。

总结

Catalyst 之前主要使用 PostgreSQL 来处理客户数据，但系统很快遇到了瓶颈。他们重新设计了数据架构，并引入新的数据库来为客户提供数据。通过采用 TiDB, Catalyst 能够提供更好的客户体验，包括更快的查询响应、更有弹性的系统、更强大的数据存储、处理和分析能力。Catalyst 还降低了它们的整体维护成本。