本节引见数据在 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，该形式由具备相关形象数据类型的字段列表定义。>

该>

这具备三种 Entity Type。Errors、Transactions 并且它们都承袭自 Events。这些构成了逻辑数据模型，因此查问 EventsEntity Type 给出了 Transactions 和 Errors 的联结，但它只准许查问中存在两者之间的公共字段。

出于性能要素，Errors Entity Type 由两个 Storage 支持。一个是用于摄取数据的关键 Errors Storage，另一个是readonly view(只读视图)，在查问时对 Clickhosue 的负载较少，但提供较低的分歧性保障。 Transactions 只要一个storage，并且有一个 Merge Table 来为 Events 提供服务(实质上是两个表联结的视图)。

衔接实体类型

这是一个便捷的数据集示例，其中蕴含可以在查问中衔接在一同的多个实体类型。

GroupedMessage 和 GroupAssingee 可以是带有 Errors 的 left join查问的一局部。其他局部与前面示例中讨论的内容相似。