让仪表板运行更快
如何让仪表板加载更快。
关于仪表板性能，主要有四种方法可以加快仪表板加载速度：
- 请求更少的数据.
- 缓存问题答案.
- 组织数据以预测常见问题.
- 提出高效的问题。
以下是关于如何加快仪表板加载速度的一些通用指南。本指南的大部分内容将集中在第三点，即如何组织数据以预测数据将用于回答的最常见问题。
关于过早优化是万恶之源的常见警告同样适用。我们的建议假定您已经探索数据一段时间，并从数据产生的洞察中获得了实质性收益。只有到那时，您才应该问：“如何让这个仪表板加载得更快？”
请求更少的数据
这一点几乎太显而易见以至于经常被忽视，但它应该是首先要考虑的地方。您真的需要正在查询的数据吗？即使您确实需要所有这些数据，您多久需要一次？
您可以通过限制查询的数据来节省大量时间，例如在仪表板上添加默认筛选器。尤其要注意跨越时间和空间的数据：您真的需要每天查看过去一个季度的数据吗？或者您真的需要每个国家/地区的每笔交易吗？
即使您**确实**需要这些信息，您每天都需要它吗？您能否将该问题转移到另一个通常只每周或每月审查一次的仪表板？
在探索数据集时，我们应该对所有数据保持开放态度，但一旦我们确定了组织需要做出的决策类型以及我们需要哪些数据来支持这些决策，我们就应该毫不留情地排除那些不能显著改善我们分析的数据。
缓存问题答案
如果数据已加载，您无需等待。管理员可以设置 Metabase 来缓存查询结果，这将存储问题的答案。如果您有一组仪表板，每个人在早上打开电脑时都会运行，请提前运行该仪表板，仪表板中的问题将使用保存的结果进行后续运行，以便在几秒钟内加载。人们可以选择刷新数据，但通常这是不必要的，因为大多数情况下人们只需要查看前一天及以前的数据。
管理员可以在**管理员面板**的**性能**选项卡中配置缓存规则。您可以选择将缓存保留数小时，使用固定计划使缓存失效，或使用查询的平均执行时间来确定缓存结果的时长。
在专业版和企业版计划中，您还可以设置特定于单个仪表板和问题的缓存策略。
您可以使用 Metabase 的使用情况分析来确定人们通常何时运行各种查询，然后使用Metabase 的 API 创建脚本，以编程方式提前运行这些查询（从而缓存其结果）。这样，当人们登录并导航到他们的仪表板时，结果会在几秒钟内加载。即使不采取额外的“预热”步骤，当第一个人加载慢速查询时，它也会为您的其他人缓存。
组织数据以预测常见问题
您可以做的下一个最好的事情是以一种预测将要提出的问题的方式组织数据，这将使您的数据库更容易检索数据。
除下面的最后一部分外，所有内容都假定您正在使用传统的关系型数据库，如 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 本质上是子查询，并且每次都会计算。它们可能会被缓存，但不会存储在数据库中。
然而，物化视图将消耗您数据库中的资源，并且您必须手动更新视图 (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，它是一个查询引擎，可以与各种不同的数据存储配对，包括Amazon S3。
当您开始使用 Metabase 时，无需过多担心底层数据存储。但随着您的数据增长以及 Metabase 采用率的提高，请留意可能需要考虑使用数据仓库的指标。例如，Redshift 可以查询 PB 级数据，并扩展到查询 Amazon S3 中的历史数据。而 Snowflake 允许您根据组织的发展动态扩展计算资源。
进一步阅读
有关提高性能的更多技巧，请查阅我们关于Metabase 扩展和SQL 查询最佳实践的文章。
如果您改善了组织中的仪表板性能，您可以在我们的论坛上分享您的技巧。
下一步：大规模部署 Metabase
大规模部署 Metabase 以支持更多人员和数据库的最佳实践。