Catalyst 是一家總部位于紐約的 SaaS 創(chuàng)業(yè)公司，它提供了一個直觀且靈活的客戶成功平臺（Custom Success Platform），可幫助客戶成功團隊匯聚客戶數據，洞悉客戶健康狀況，推動客戶留存和業(yè)務增長。目前 Catalyst 已完成了 B 輪融資。

業(yè)務特點

Catalyst 整合了來自包括 Salesforce、Mixpanel、 PostgreSQL 等不同來源的海量數據，并將其納入 Catalyst 生態(tài)系統(tǒng)中進行處理、分析并生成可參考執(zhí)行的數據洞察。

(相關資料圖)

Catalyst 主要處理三種類型的數據：事務型數據、只讀數據和時序數據。

事務型數據主要包括內部創(chuàng)建的筆記和任務，以及從 Salesforce、Zendesk 和其他平臺收集的外部數據。

只讀型數據主要是指從 Jira 和 Zendesk 等平臺收集的工單數據。

時序型數據是 Catalyst 最重要和最棘手的數據類型之一。能處理這一類型的數據，也是 Catalyst 團隊數據庫選型的重要需求之一。

以前的數據架構及其瓶頸

Catalyst 最初使用 PostgreSQL 來處理從外部收集的所有數據。然而，隨著其業(yè)務的增長和數據源的迅速擴大，PostgreSQL 無法跟上其需求。Catalyst 最初試圖通過將數據存儲為 JSON 文檔來彌補這一缺陷，但查詢性能受到了嚴重影響。

隨后，該團隊轉向了 pre-caching 方案。他們采用 Elasticsearch 來存儲結果，以便更快地響應客戶的查詢。然而，由于 Elasticsearch 不支持 SQL 風格的 JOIN， Catalyst 必須在將所有內容存儲在 Elasticsearch 之前進行預計算。隨著存儲數據量增加，成本也急劇上升。

為了解決這些問題并拓展業(yè)務增長，Catalyst 團隊決定重新設計整個數據處理和存儲系統(tǒng)。他們也是這個時候發(fā)現(xiàn)了新一代分布式關系型數據庫 TiDB。

數據層重構

Catalyst 的新架構分為五個數據層：數據攝取層、數據湖層、Spark 層、數據服務層和 Web 應用層。原始數據通過攝取層進入，并繼續(xù)進入數據湖層。Spark 層組合數據對象，執(zhí)行預計算，確保數據有意義。數據服務層存儲所有預處理過數據以供客戶查詢。因為直接影響用戶體驗，數據服務層對 Catalyst 來是最重要的，也成為 Catalyst 對新數據棧迫切需求的地方。數據服務層以下的各層不需要是實時的。然而，在數據服務層，Catalyst 需要亞秒級的延遲，以便客戶能夠迅速獲得結果。

新技術棧的必備能力

為了服務不斷增長的客戶，Catalyst 迫切需要一個具備以下特性的數據庫：

支持混合事務型和分析型工作負載。Catalyst 必須處理事務型和只讀數據，以及時序數據。他們需要的解決方案，無論是單一的數據庫還是一個數據庫組合，必須能夠同時處理交易型和分析型工作負載。

快速響應。新的數據庫解決方案必須比 Catalyst 以前的解決方案更靈活，特別是在查詢速度和用戶界面性能方面。它必須在幾秒鐘內對查詢作出反應，并具有較低的更新延時。

處理復雜和高度定制的數據。Catalyst 的客戶可以在 Catalyst 平臺內部以及 Salesforce 和 Zendesk 等數據源平臺上自定義許多設置，包括查詢、數據轉換和關系。與許多自定義字段集成的自定義對象的組合可能相當復雜。新的解決方案必須能夠處理這種情況。

高可用。Catalyst 需要對他們的客戶作出敏捷的反應。維持系統(tǒng)運行是 Catalyst 的首要任務。一旦 Catalyst 宕機，客戶往往幾十秒內就會投訴。因此，新的數據庫解決方案必須是高度可用的，以幫助 Catalyst 輕松應對任何可能的系統(tǒng)事故。

水平擴展性。可擴展性是另一個必須具備的條件。Catalyst 處理的數據量非常大，而且數據量還會不斷擴大。數據庫解決方案必須易于擴展到巨大的規(guī)模。

數據強一致性。數據一致性是另一個要求。但考慮到有如此多的數據處理在流中進行，要在整個系統(tǒng)中保持數據強一致性是非常困難的。因此 Catalyst 可以接受最終一致性 （Eventual Consistency）。

TiDB 在性能測試中脫穎而出

Catalyst 在選擇新的數據庫時非常謹慎；他們調研了 TiDB 和另外兩種選擇： Aurora 與 AWS Timestream 結合，以及 YugaByte 與 AWS Timestream 結合的方案。這些選項是聯(lián)機事務處理（OLTP）數據庫和時序數據庫的組合。

為了測試這三個候選解決方案，Catalyst 采用來自內部 Salesforce 和 Jira 實例的大型真實數據集作為負載，通過連續(xù)并行的方式運行分組查詢。查詢響應速度是最重要的評估標準之一。

TiDB 對典型查詢和聚合查詢的響應時間都在幾秒鐘之內，比其他候選解決方案快得多。同時，TiDB 對時序聚合查詢的表現(xiàn)也足夠靈活敏捷，7 秒內返回結果。下表總結了一些關鍵的測試結果。

查詢的類型有：

典型查詢：客戶最感興趣的查詢。

聚合查詢：主要是基于復雜 JOIN 的計算。

時序聚合查詢： Catalyst 沒有在 Aurora 和 Yugabyte 解決方案上測試時序聚合查詢，因為時間有限，而且 TiDB 的性能對他們來說已經足夠印象深刻。

關鍵測試結果

為什么選擇 TiDB？

查詢響應快

根據查詢類型的不同，TiDB 的響應時間比其競爭對手快 10 到 60 倍。這是 Catalyst 選擇 TiDB 的最重要原因。

完美支持在線 DDL

TiDB 支持在線數據定義語言（DDL）操作，且不會影響在線業(yè)務。TiDB 提供無憂的模式變化，并允許 Catalyst 更快地添加或刪除索引，特別是對于大表。當他們遇到慢查詢并需要快速添加索引以提高性能時，這尤其有用。通過在線模式變更，Catalyst 無須停下在線業(yè)務或預留長時間的維護窗口。

HTAP 混合負載數據庫

TiDB 是一個混合事務和分析處理的（HTAP）數據庫。在 Catalyst 評估的三個候選項中，TiDB 是唯一一個技術棧可以同時處理對象數據和時序數據的數據庫。這不僅非常高效，而且還為 Catalyst 節(jié)省了大量的時間、精力和金錢。

水平擴展性

TiDB 具有高度的水平擴展性。這完美地滿足了 Catalyst 應對不斷擴大的數據量的業(yè)務需求。TiDB 還支持計算和存儲資源分離，這使得 Catalyst 可以單獨擴展這兩種資源，也有助于控制成本。

快速的容災恢復

TiDB 使用 Raft 共識算法來確保數據的高度可用性和安全復制。TiKV 是 TiDB 的存儲服務器，數據在 TiKV 節(jié)點之間進行冗余復制，并放置在不同的可用區(qū)域，以防止機器或數據中心故障。這確保了 Catalyst 的系統(tǒng)正常運行時間。此外，TiDB 提供了多種災難恢復方案的選擇，每一種方案都適用于不同的場景，成本靈活。

全面的托管服務

Catalyst 有一個小的 DevOps 團隊，所以他們需要一個完全托管的數據庫解決方案，以減輕團隊的負擔并控制成本。TiDB 的全托管服務 TiDB Cloud 滿足了這一需求。

云中立

Catalyst 的服務采取跨云部署的方式以保證其業(yè)務的靈活性：一些工作負載在谷歌云平臺（GCP）上運行，一些在亞馬遜（AWS）上運行。因此，他們需要一個支持多云部署的云數據庫解決方案。TiDB Cloud 正是這樣的解決方案。

總結

Catalyst 之前主要使用 PostgreSQL 來處理客戶數據，但系統(tǒng)很快遇到了瓶頸。他們重新設計了數據架構，并引入新的數據庫來為客戶提供數據。通過采用 TiDB, Catalyst 能夠提供更好的客戶體驗，包括更快的查詢響應、更有彈性的系統(tǒng)、更強大的數據存儲、處理和分析能力。Catalyst 還降低了它們的整體維護成本。

關鍵詞：