本节介绍的数据是 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 部分查询。其余部分类似于上述示例中讨论的内容。