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

原创
06/12 19:43
阅读数 89

总部位于纽约的 Catalyst 是一家 SaaS 创业公司,已完成 B 轮融资。它提供了一个直观且灵活的客户成功平台(Custom Success Platform),可帮助客户成功团队汇聚客户数据,洞悉客户健康状况,推动客户留存和业务增长。

业务特点

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 还降低了它们的整体维护成本。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部