[[427886]]

本節介紹數據在 Snuba 中的組織方式以及面向用戶的數據如何映射到底層數據庫(如： Clickhouse)。

Snuba 數據模型橫向分為邏輯模型(logical model)和物理模型(physical model)。邏輯數據模型是 Snuba 客戶端通過 Snuba 查詢語言可見的。此模型中的元素可能會也可能不會 1:1 映射到數據庫中的表。相反，物理模型將 1:1 映射到數據庫概念(如表和視圖)。

這種劃分背后的原因是，它允許 Snuba 通過邏輯數據模型公開一個穩定的接口，并在內部執行復雜的映射，對不同的表(物理模型的一部分)執行查詢，以一種對 client 透明的方式提高性能。

本節的其余部分概述了組成兩個模型的概念以及它們如何相互連接。

下面描述的主要概念是數據集(dataset)、實體(entity)和存儲(storage)。

數據集

Dataset 是 Snuba 數據的命名空間。它提供了自己的 schema，并且在邏輯模型和物理模型方面都獨立于其他數據集。

數據集的示例是 discover(發現)、outcomes(結果)、sessions(會話)。他們之間沒有任何關系。

數據集可以看作是定義其抽象數據模型及其具體數據模型的組件的容器，如下所述。

實體和實體類型

Snuba 向客戶端公開的邏輯數據模型的基本塊(fundamental block)是實體。在邏輯模型中，實體表示抽象概念(如 transaction 或 error)的實例。在實踐中，Entity 對應于數據庫表中的一行。Entity Type 是實體的類(如 Errors 或 Transactions)。

邏輯數據模型由一組 Entity Types 及其 relationships 組成。

每個 Entity Type 都有一個 schema，該模式由具有相關抽象數據類型的字段列表定義。 Dataset 的所有 Entity Types(可以有多個)的 schema 組成了對 Snuba client 可見的邏輯數據模型，Snuba 查詢根據該模型進行驗證。不應該暴露較低級別的概念。

Entity Types 明確包含在 Dataset 中。一個 Entity Type 不能出現在多個數據集中。

實體類型之間的關系

數據集中的實體類型在邏輯上是相關的。支持兩種類型的關系：

• 實體集關系(Entity Set Relationship)。這模仿了外鍵。這種關系旨在允許實體類型之間的連接。目前它只支持一對一和一對多的關系。
• 繼承關系(Inheritance Relationship)。這模仿了名義上的子類型(subtyping)。一組實體類型可以共享一個父實體類型。子類型從父類型繼承 schema。從語義上講，父實體類型必須表示其類型從其繼承的所有實體的聯合。還必須能夠查詢父實體類型。這不能僅僅是一種邏輯關系。

實體類型和一致性

Entity Type 是 Snuba 可以提供一些強大的數據一致性保證的最大單元。具體來說，可以查詢期望 Serializable Consistency(可序列化的一致性) 的實體類型。這不會擴展到跨越多個實體類型的任何查詢，在這種情況下，我們最多將具有最終的一致性。

這也會對訂閱查詢(Subscription queries)產生影響。這些一次只能對一種實體類型起作用，否則，它們將需要實體類型之間的一致性，而我們不支持這種一致性。

請注意!

準確地說，一致性單位(取決于 Entity Type)甚至可以更小，并且取決于數據攝取主題(data ingestion topics)的分區方式(例如 project_id)，實體類型是 Snuba 允許的最大值。

存儲

Storage 表示并定義 Dataset 的物理數據模型。每個 Storage 表示在物理數據庫概念中具體化，如表或具體化視圖。因此，每個存儲都有一個由字段及其類型定義的 schema，該字段反映了 storage 映射到的 DB table/view 的物理模式，并且能夠提供生成 DDL 語句的所有詳細信息，以在數據庫上構建表。

Storage 能夠將上面討論的邏輯模型中的邏輯概念映射到數據庫的物理概念，因此每個 Storage 都需要與一個 Entity Type 相關聯。具體來說：

• 每個 Entity Type 必須由至少一個 Readable Storage(我們可以在其上運行查詢的 Storage)支持，但可以由多個 Storage(例如預聚合物化視圖pre-aggregate materialized view)支持。每個 Entity Type 的多個 Storage 旨在允許查詢優化。
• 每個 Entity Type 必須由一個且僅一個用于攝取數據和填充數據庫表的 Writable Storage 支持。
• 每個 Storage 僅支持一種 Entity Type。

示例

本節提供了一些示例，說明 Snuba data model 如何表示一些現實世界模型。

這些案例研究不一定反映當前的 Sentry production model，也不一定是同一部署的一部分。它們必須被視為孤立的例子。

單一實體數據集

這看起來像 Sentry 使用的 Outcomes 數據集。這實際上并沒有反映截至 2020 年 4 月的 Outcomes。盡管設計 Outcomes 應該朝著這個方向發展。

該 Dataset 只有一種 Entity Type，代表數據集攝取的單個 Outcome。查詢 raw Outcome 非常緩慢，所以我們有兩個 Storage。一個是反映我們攝取的數據的 Raw storage 和一個計算每小時聚合的 materialized view，查詢效率更高。Query Planner 將根據查詢是否可以在聚合數據上執行來選擇 storage。

多個實體類型數據集

此數據集的典型示例是 Discover 數據集。

這具有三種 Entity Type。Errors、Transactions 并且它們都繼承自 Events。這些形成了邏輯數據模型，因此查詢 Events Entity Type 給出了 Transactions 和 Errors 的聯合，但它只允許查詢中存在兩者之間的公共字段。

出于性能原因，Errors Entity Type 由兩個 Storage 支持。一個是用于攝取數據的主要 Errors Storage，另一個是read only view(只讀視圖)，在查詢時對 Clickhosue 的負載較少，但提供較低的一致性保證。 Transactions 只有一個 storage，并且有一個 Merge Table 來為 Events 提供服務(本質上是兩個表聯合的視圖)。

連接實體類型

這是一個簡單的數據集示例，其中包含可以在查詢中連接在一起的多個實體類型。

GroupedMessage 和 GroupAssingee 可以是帶有 Errors 的 left join 查詢的一部分。其余部分與前面示例中討論的內容類似。