写点什么

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

  • 2023-10-13
    北京
  • 本文字数:2864 字

    阅读完需:约 9 分钟

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


用户头像

TiDB 社区官网:https://tidb.net/ 2021-12-15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB x Catalyst丨秒级洞悉数据价值,TiDB 帮助“客户成功 SaaS 厂商”提升用户体验_TiDB 社区干货传送门_InfoQ写作社区