加快仪表板速度
如何让您的仪表板加载更快。
在仪表板性能方面，基本上有四种方法可以使仪表板加载更快
- 请求更少的数据.
- 缓存问题的答案.
- 组织数据以预测常见问题.
- 提出高效的问题。
以下是一些关于如何加快仪表板加载速度的通用指南。本指南的大部分内容将侧重于第三点，或者您如何组织数据以预测数据将用于回答的最常见问题。
关于过早优化是万恶之源的常见警告适用。我们的建议假设您已经探索您的数据一段时间，并且正在从数据产生的洞察力中获得实质性好处。只有到那时，您才应该问，“如何让这个仪表板加载更快？”
请求更少的数据
这一点几乎太明显以至于经常被忽视，但它应该是开始的第一步。您真的需要您正在查询的数据吗？即使您确实需要所有这些数据，您多久需要一次？
您可以通过限制您查询的数据来节省大量时间，例如通过包含添加仪表板上的默认过滤器。特别注意跨越时间和空间的数据：您真的需要每天查看过去一个季度的数据吗？或者您真的需要每个国家/地区的每笔交易吗？
即使您确实需要知道这些信息，您每天都需要吗？您可以将该问题重新定位到另一个通常仅每周或每月查看的仪表板吗？
当我们在探索数据集时，我们应该对所有数据持开放态度，但是一旦我们确定了我们的组织需要做出的决策类型——以及我们需要告知这些决策的数据——我们就应该无情地排除那些不能显着改善我们分析的数据。
缓存问题的答案
如果数据已加载，您无需等待数据。管理员可以设置 Metabase 来缓存查询结果，这将存储问题的答案。如果您有一组每个人在早上第一次打开电脑时都会运行的仪表板，请提前运行该仪表板，该仪表板中的问题将使用已保存的结果进行后续运行，并在几秒钟内加载。人们可以选择刷新数据，但通常这是不必要的，因为大多数情况下，人们只需要查看前一天及之前的数据。
管理员可以在管理面板的性能选项卡中配置缓存规则。您可以选择将缓存保留几个小时，使用设定的计划使缓存失效，或使用查询的平均执行时间来确定缓存其结果的时间。
在Pro 和企业版套餐中，您还可以设置特定于单个仪表板和问题的缓存策略。
您可以使用 Metabase 的使用情况分析来确定人们通常何时运行各种问题，然后使用 Metabase 的 API 创建脚本以编程方式提前运行这些问题（从而缓存其结果）。这样，当人们登录并导航到他们的仪表板时，结果会在几秒钟内加载。即使不采取额外的“预热”步骤，当您的第一个人加载该慢速查询时，它也会为您的其他人缓存。
组织数据以预测常见问题
您可以做的下一个最好的事情是以一种可以预测将被提出的问题的方式组织您的数据，这将使您的数据库更容易检索该数据。
除了下面最后一部分之外的所有内容都假设您正在使用传统的关联式数据库，如 PostgreSQL 或 MySQL。最后一部分是关于迁移到完全不同类型的数据库，该数据库专门针对处理分析进行了调整，并且应该是您的最后手段，尤其是对于初创公司而言。
索引频繁查询的列
向数据库添加索引可以显着提高查询性能。但正如索引书中的所有内容没有意义一样，索引确实会产生一些开销，因此应有策略地使用它们。
如何有策略地使用索引？找到您查询最多的表，以及这些表中查询最频繁的列。您可以查阅您的个人数据库以获取此元数据。例如，PostgreSQL 通过其 pg_stat_statements 模块提供有关查询数量和性能的元数据。
请记住做一些简单的工作，询问您的 Metabase 用户哪些问题和仪表板对他们很重要，以及他们是否也遇到任何“缓慢”。最常需要索引的字段要么是基于时间的，要么是基于 ID 的——想想事件数据上的时间戳，或者类别数据上的 ID。
或者，在Pro 和企业版套餐上，您可以使用 Metabase 的使用情况分析，这使得很容易查看谁在运行哪些查询、频率以及这些查询返回记录所花费的时间。
一旦您确定了要索引的表和列，请查阅您的数据库文档以了解如何设置索引（例如，这是 PostgreSQL 中的索引）。
索引很容易设置（和删除）。以下是 CREATE INDEX 语句的基本格式
CREATE INDEX index_name ON table_name (column_name)
例如
CREATE INDEX orders_id_index ON orders (id)
进行索引实验，看看如何提高查询性能。如果您的用户经常在单个表上使用多个过滤器，请研究使用复合索引。
复制您的数据库
如果您正在使用数据库来处理操作（例如，应用程序交易，如下单、更新个人资料信息等）以及分析（例如，用于支持 Metabase 仪表板的查询），请考虑创建该生产数据库的副本，以用作仅用于分析的数据库。将 Metabase 连接到该副本，每晚更新副本，并让您的分析师进行查询。分析师的长时间运行的查询不会干扰您的生产数据库的日常操作，反之亦然。
除了加快仪表板速度之外，保留用于数据分析的副本数据库是避免可能长时间运行的分析查询影响您的生产环境的良好做法。
反规范化数据
在某些情况下，反规范化某些表（即将多个表合并为一个具有更多列的更大表）可能是有意义的。您最终将存储一些冗余数据（例如，每次用户下单时都包含用户信息），但分析师不必连接多个表即可获得他们需要回答问题的数据。
物化视图：创建新表来存储查询结果
使用 物化视图，您将原始的、反规范化的数据保留在他们的表中，并创建新表（通常在非工作时间）来存储查询结果，这些查询结果以一种可以预测分析师将提出的问题的方式组合来自多个表的数据。
例如，您可能会将订单和产品信息存储在不同的表中。您可以每晚创建（或更新）一个物化视图，该视图组合了这两个表中查询最频繁的列，并将该物化视图连接到您在 Metabase 中的问题。如果您将数据库用于生产和分析，除了消除组合该数据所需的连接过程之外，您的查询不必与这些表上的生产读取和写入竞争。
物化视图和公用表表达式（CTE，有时称为视图）之间的区别在于，物化视图将其结果存储在数据库中（因此可以被索引）。CTE 本质上是子查询，并且每次都会计算。它们可能会被缓存，但不会存储在数据库中。
但是，物化视图会消耗数据库中的资源，并且您必须手动更新视图（refresh materialized view [name]）。
提前使用汇总表聚合数据
这里的想法是使用物化视图——甚至是一组单独的表——来创建汇总表，以最大限度地减少计算。假设您有数百万行的表，并且您想要聚合多个列中的数据。您可以基于一个或多个表的聚合创建物化视图，这将执行初始（耗时）计算。与其让仪表板查询并在一天中多次计算原始数据，不如创建查询该汇总表的问题以获取前一天晚上计算的数据。
例如，您可以有一个包含所有订单表的订单表，以及一个每晚更新并存储汇总和其他聚合数据（例如，每周、每月等的订单总额）的订单汇总表。如果有人想要查看用于计算该聚合的各个订单，您可以使用自定义目标将用户链接到确实查询原始数据的问题或仪表板。
从 JSON 中提取数据并将键插入列中
我们经常看到组织将 JSON 对象存储在像 MySQL 或 PostgreSQL 这样的关系数据库的单个列中。通常，这些组织正在存储来自事件分析软件（如 Segment 或 Amplitude）的 JSON 有效负载。
尽管某些数据库可以索引 JSON（例如，PostgreSQL 可以索引 JSON 二进制文件），但即使您只对对象中的单个键值对感兴趣，您仍然必须每次都抓取完整的 JSON 对象。相反，请考虑从这些 JSON 对象中提取每个字段并将这些键映射到表中的列。
考虑针对分析优化的数据库
如果您已完成上述所有操作，并且您的仪表板加载时间的长度仍然干扰您及时做出决策的能力，您应该考虑使用专门为处理分析查询而构建的数据库。这些数据库称为在线分析处理 (OLAP) 数据库（有时称为数据仓库）。
像 PostgreSQL 和 MySQL 这样的传统关系数据库专为事务处理而设计，并且被归类为在线事务处理 (OLTP) 数据库。这些数据库更适合用作操作数据库，例如存储 Web 或移动应用程序的数据。它们非常擅长处理以下场景：有人向您的网站提交了一条经过深思熟虑、切题且绝非煽动性的评论，您的应用程序向您的后端触发 POST 请求，后端将评论和元数据路由到您的数据库以进行存储。OLTP 数据库可以处理大量并发事务，如评论帖子、购物车结账、个人资料生物更新等。
OLAP 和 OLTP 系统之间的主要区别在于，OLAP 数据库优化了分析查询，例如对大量数据进行求和、聚合和其他分析操作，以及批量导入（通过 ETL），而 OLTP 数据库必须平衡来自数据库的大量读取与其他事务类型：小插入、更新和删除。
OLAP 通常使用列式存储。传统的 (OLTP) 关系数据库按行存储数据，而使用列式存储的数据库（毫不奇怪）按列存储数据。当读取数据时，这种列式存储策略为 OLAP 数据库提供了优势，因为查询不必筛选不相关的行。这些数据库中的数据通常以 事实表和维度表的形式组织，其中（通常是巨大的）事实表存储事件。每个事件都包含属性列表和对维度表的外键引用，维度表包含有关这些事件的信息：谁参与了、发生了什么、产品信息等等。
Metabase 支持多个流行的数据仓库：Google BigQuery、Amazon Redshift、Snowflake 和 Apache Druid（专门从事实时分析）。Metabase 还支持 Presto，Presto 是一个查询引擎，可以与各种不同的数据存储配对，包括 Amazon S3。
当您开始使用 Metabase 时，不必过于担心底层数据存储。但是随着您的数据增长，以及 Metabase 的采用率提高，请留意可能需要调查使用数据仓库的指标。例如，Redshift 可以查询 PB 级数据，并扩展到查询 Amazon S3 中的历史数据。而 Snowflake 允许您随着组织的发展动态扩展计算资源。
延伸阅读
有关提高性能的更多技巧，请查看我们关于扩展 Metabase 和 SQL 查询最佳实践的文章。
如果您改进了组织的仪表盘性能，可以在我们的论坛上分享您的技巧。
下一步：Metabase 的规模化
扩展 Metabase 以支持更多用户和数据库的最佳实践。