仪表板优化

如何使您的仪表板加载更快。

说到仪表板性能方面，基本上有四种方法可以让仪表板更快地加载：

要求更少的数据.
缓存问题答案.
组织数据以预测常见问题.
提出有效的问题。

下面是一些关于如何获得仪表板加载速度更快。本指南的大部分内容将集中在第三个要点上，或者您如何组织数据来预测数据将用于回答的最常见问题。

关于过早优化是万恶之源的常见警告。我们的建议假设您已经研究了一段时间的数据，并且从数据产生的洞察力中获得了实质性的好处。只有这样，您才应该问，“如何让这个仪表板加载更快？”

要求更少的数据

这一点太明显了，常常被忽视，但它应该是第一个开始的地方。你真的需要你正在查询的数据吗？即使你确实需要这些数据，你多久需要一次？

只需限制查询的数据，例如添加仪表板上的默认筛选器。尤其要注意跨越时间和空间的数据：你真的需要每天查看上一季度的数据吗？或者你真的需要每个国家的每笔交易？

即使你做需要知道这些信息，你每天都需要吗？你能把这个问题转移到另一个通常只每周或每月审查的仪表板上吗？

当我们探索我们的数据集时，我们应该对我们的所有数据开放，但是一旦我们确定了我们的组织需要做出的决策以及我们需要为这些决策提供信息的数据，我们就应该毫不留情地排除那些对我们的分析没有显著改善的数据。

缓存问题答案

如果数据已经加载，则不需要等待。管理员可以将Metabase设置为缓存查询结果，它将存储问题的答案。如果你有一套仪表板，每个人在早上第一件事打开电脑时都会运行，那么提前运行仪表板，仪表板中的问题将使用保存的结果在几秒钟内加载后续运行。人们可以选择刷新数据，但通常这是不必要的，因为大多数情况下人们只需要查看前一天和之前的数据。

可以在中配置缓存设置的管理面板。通过这些设置，您可以配置要缓存的最短查询持续时间（因此您只缓存长时间运行的查询）、缓存生存时间（TTL）乘数（以指定缓存应保留多长时间）和最大缓存项大小（以便您可以设置缓存数据量的上限）。

你可以使用Metabase的审计工具要确定人们通常何时运行各种问题，然后使用Metabase的API提前以编程方式运行这些问题（从而缓存它们的结果）。这样，当用户登录并导航到他们的仪表板时，结果将在几秒钟内加载。即使不采取额外的“预热”步骤，当第一个人加载这个缓慢的查询时，它也会被缓存以供其他人使用。

组织数据以预测常见问题

您可以做的下一件最好的事情是以这样一种方式组织您的数据，这样它就可以预测将要提出的问题，这将使您的数据库更容易地检索这些数据。

索引经常查询的列.
复制数据库.
非规范化数据.
物化视图：创建新表来存储查询结果.
用汇总表提前汇总数据.
从JSON中提取数据并将其键插入列中.
考虑一个特定于分析的数据库.

除了最后一节之外，其他部分都假设您使用的是传统的关系数据库，如PostgreSQL或MySQL。最后一节是关于移动到一个完全不同的数据库类型，专门为处理分析而优化，这应该是你最后的手段，尤其是对于初创企业。

索引经常查询的列

向数据库添加索引可以显著提高查询性能。但是，正如索引书中的所有内容没有意义一样，索引也会产生一些开销，因此应该从战略上加以利用。

如何战略性地使用索引？查找查询最多的表，以及最常查询的表柱在那些桌子上。你可以参考你的个人数据库来得到这个元数据例如，PostgreSQL通过其 pg_stat_statements 模块。

记住要做一些简单的工作，询问你的Metabase用户哪些问题和仪表板对他们来说是重要的，以及他们是否也遇到了任何“慢”。最经常需要索引的字段要么是基于时间的或基于id的事件数据的思考时间戳，要么是分类数据上的id。

或者，在商业版本，您可以使用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本质上是子查询，每次都要计算。它们可以被缓存，但不存储在数据库中。

然而，物化视图将消耗数据库中的资源，您必须手动更新视图(刷新物化视图[名称]).

用汇总表提前汇总数据

这里的想法是使用物化视图甚至是一组单独的表来创建汇总表使计算量最小化。假设您有一个包含一百万行的表，并且您希望在多个列中聚合数据。您可以基于聚合一个或多个表的集合，它将执行初始（耗时）计算。您不必在一天中多次进行仪表板查询并计算原始数据，而是可以创建问题来查询汇总表以获得前一天晚上计算的数据。

例如，您可以有一个包含所有orders表的orders表，以及一个order summary表，该表每夜更新一次并存储汇总数据和其他聚合数据，例如每周、每月的订单总数等。如果某人想查看用于计算该聚合的单个订单，可以使用自定义目的地将用户链接到做查询原始数据。

从JSON中提取数据并将其键插入列中

我们经常看到组织在关系数据库（如MySQL或PostgreSQL）的一列中存储JSON对象。通常，这些组织存储来自事件分析软件的JSON有效负载，比如分段，或振幅.

尽管有些数据库可以索引JSON（例如，PostgreSQL可以索引JSON二进制文件），但是每次仍然必须获取完整的JSON对象，即使您只对对象中的单个键值对感兴趣。相反，考虑从这些JSON对象中提取每个字段，并将这些键映射到表中的列。

考虑一个为分析而优化的数据库

如果您已经完成了上述所有操作，并且仪表板加载时间的长度仍然影响您及时做出决策的能力，那么您应该考虑使用专门为部署分析查询而构建的数据库。这些数据库称为联机分析处理（OLAP）数据库（有时称为数据仓库).

传统的关系型数据库如PostgreSQL和MySQL是为事务处理而设计的，它们被分类为联机事务处理（OLTP）数据库。这些数据库更适合用作操作数据库，例如为web或移动应用程序存储数据。他们非常擅长处理以下场景：有人向你的网站提交一个深思熟虑的、密切相关的、一点也不煽动性的评论，你的应用程序向你的后端发出一个POST请求，然后将评论和元数据路由到你的数据库进行存储。OLTP数据库可以处理大量并发事务，如评论帖子、购物车签出、概要文件bio更新等。

OLAP和OLTP系统之间的主要区别在于OLAP数据库优化分析查询，如对大量数据的求和、聚合和其他分析操作，以及批量导入（通过ETL工具)，而OLTP数据库必须平衡来自数据库的大的读取和其他事务类型：小的插入、更新和删除。

OLAP通常使用列存储。而传统的（OLTP）关系数据库按行存储数据，而使用列存储的数据库（毫不奇怪）按列存储数据。这种列式存储策略使OLAP数据库在读取数据时具有优势，因为查询不必筛选不相关的行。这些数据库中的数据通常组织在事实和维度表，带有（通常是大量的）包含事件的事实表。每个事件都包含属性和外键对维度表的引用，其中包含有关这些事件的信息：涉及的人员、发生了什么、产品信息等等。