每个 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 查询的一部分。其余部分与前面示例中讨论的内容类似。