大规模 Metabase
扩展 Metabase 以支持更多用户和数据库的最佳实践。
Metabase 是一款可扩展、久经考验的软件，成千上万家公司使用它来交付高质量的自助服务分析。它通过水平扩展支持高可用性，并且开箱即用非常高效：一台具有 4 GB 内存的单核机器可以将 Metabase 扩展到数百名用户。
本文提供了关于如何随着用户数量和数据源的增加，保持 Metabase 在生产环境中平稳运行的高级指导和最佳实践。每个数据系统都不同，因此我们只能在较高层面讨论扩展策略，但您应该能够将这些策略转化为您特定的环境和使用情况。
影响 Metabase 性能和可用性的因素
Metabase 在垂直和水平方向上都具有良好的可扩展性，但它只是您数据仓库的一个组件，系统的整体性能将取决于系统的组成和您的使用模式。影响您使用 Metabase 体验的主要因素包括
- 连接到 Metabase 的数据库数量。
- 每个数据库中的表数量。
- 您的数据仓库的效率。
- 仪表盘中问题的数量。
例如，如果一个问题需要运行一个查询，而您的数据库需要 30 分钟才能完成，那么您运行多少个 Metabase 实例都无关紧要：这仍然需要 30 分钟。解决方案是重新评估您对该数据的需求（您真的每次都需要所有这些信息吗？）或者找到提高数据库性能的方法，例如重新组织、索引或缓存您的数据。
数据库和表的数量也会影响客户端性能，但仅在您管理数百个数据库和/或数千个表的大规模情况下，因为元数据本身可能需要大量查询。为了即使在这种规模下也能保持性能流畅，您可以管理 Metabase 何时与您连接的数据库同步其元数据。
现在让我们确保您的 Metabase 应用程序已充分调整以进行扩展。
垂直扩展
垂直扩展是蛮力方法。为 Metabase 提供更多的内核和内存，它将有更多的资源可用于完成其工作。如果您遇到与应用程序本身相关的性能问题（即，与数据库的广度和规模无关），则在更强大的机器上运行 Metabase 可以提高性能。
对于每 20 个并发用户，大致需要 1 个 CPU 内核和 1GB 的 RAM
Metabase 开箱即用已经非常高效。首先，对于单用户或小型团队来说，具有 2 GB 内存的单核机器应该绰绰有余。
何时添加更多内存和内核：如果您看到您的服务器持续使用超过其当前资源（内存或计算）的 80%。
Metabase 应用程序数据库对于任何操作都应在一秒钟内响应（不包括 Metabase 连接到的数据仓库的响应时间）。
具有 4-8 GB 内存的机器应该可以处理数百个用户，如果需要，您可以增加内核数量和 GB 内存。
虽然添加更多内核和内存可能有效，但通常最好使用水平扩展来支持更多用户。原因是每个 Metabase 实例中都内置了数据库连接限制，以防止实例请求过多而压垮您的数据仓库。您可以增加实例可用的连接数，但我们仍然建议使用多个实例。
水平扩展（首选）
水平扩展不是增加运行 Metabase 的服务器的大小，而是涉及启动更多服务器（每个服务器都运行 Metabase），并将这些服务器连接到同一个应用程序数据库。这样，您可以结合负载均衡器运行 Metabase 的多个实例，以将流量定向到这些实例。Metabase 已设置为开箱即用的水平扩展，因此您无需任何特殊配置即可运行 Metabase 的多个实例。当 Metabase 服务器连接到现有的应用程序数据库时，它会将其自身识别为集群的一部分。
水平扩展的主要用例是提高可靠性（又名“高可用性”），但水平扩展也可以提高多用户性能。当负载均衡时，高流量、CPU 绑定的 Metabase 实例在某些流量被定向到其他实例时，性能会更好（更快），因为 CPU 负载将分布在多台机器上。
Metabase 附带本地 H2 数据库来存储您的应用程序数据（您的所有问题、仪表盘、日志和其他 Metabase 数据），但在生产环境中运行时，您应该升级到关系数据库，例如在单独服务器上运行的 PostgreSQL。实际上，在水平扩展时，您必须使用在单独服务器上运行的关系数据库来存储您的应用程序数据。这样，Metabase 的所有实例都可以共享一个公共数据库。我们建议所有生产实例都在单独的服务器上使用外部数据库，即使您只运行一个 Metabase 实例，因此外部数据库不是水平扩展的额外成本。
Metabase 使用外部应用程序数据库来存储用户会话数据，因此人们不必担心在某个或所有 Metabase 实例宕机时丢失已保存的工作，并且管理员不必处理配置粘性会话以确保人们连接到正确的 Metabase 实例。负载均衡器会将人们路由到可用的实例，以便他们可以继续工作。
利用基于时间的水平扩展
一些客户根据一天中的时间调整 Metabase 实例的数量。例如，一些公司会在早上启动 Metabase 的多个实例，以处理人们登录并运行其早间仪表盘时的流量突增，然后在下午（或晚上或周末）关闭这些实例，以节省云支出。
对于 Kubernetes 或 Google Cloud Platform 等环境，您需要参考每个系统各自的文档来设置类似的自动扩展规则。
简单的负载均衡
负载均衡器将流量定向到多个 Metabase 实例，以确保每个请求都能获得最快的响应。如果 Metabase 的一个实例暂时宕机，负载均衡器会将请求路由到另一个可用的实例。
使用 Metabase 设置负载均衡器非常简单。Metabase 的 API 公开了一个健康检查端点，/api/health，负载均衡器可以调用该端点来确定 Metabase 实例是否启动并响应请求。如果实例运行状况良好，则端点将返回 HTTP 状态代码 200 OK。否则，负载均衡器将知道将请求路由到另一个实例。
数据仓库调优
构建数据仓库超出了本文的范围，但您应该知道，您在 Metabase 中的查询速度将仅与数据库返回数据的速度一样快。如果您的问题需要大量数据，并且数据库需要很长时间才能检索，那么无论 Metabase 有多快，这些查询时间都会影响您的体验。
以下是一些可以提高数据仓库性能的方法
- 以预测人们将要提出的问题的方式来构建数据。 确定您的使用模式，并以使其易于返回组织中常见问题的结果的方式存储数据。编写 ETL 以创建新表，这些表将来自多个来源的常用查询数据汇集在一起。
- 调整您的数据库。 阅读数据库的文档，了解如何通过索引、缓存和其他优化措施来提高其性能。
- 过滤您的数据。鼓励人们在提问时过滤数据。他们还应该利用 Metabase 的数据探索工具（包括记录预览），以便他们只查询与他们试图回答的问题相关的数据。
- 决定是使用数据库还是数据仓库。 人们通常开始使用 Metabase 时会使用事务性数据库，如 MySQL 或 PostgreSQL。虽然这些数据库的可扩展性非常好，但它们通常没有针对 Metabase 将使用的分析查询类型进行优化。一旦达到一定规模，像
sum或max这样的操作可能会减慢速度。随着分析应用普及率的增长，您可能会发现需要探索专门的数据仓库，如 Amazon Redshift、Google BigQuery 或 Snowflake。
Metabase 应用程序最佳实践
以下是一些充分利用 Metabase 应用程序的策略
- 仅请求您需要的数据.
- 使用托管的关系型数据库来存储您的 Metabase 应用程序数据.
- 缓存您的查询.
- 查找瓶颈.
- 增加应用程序数据库的最大连接数.
- 增加到每个数据库的最大连接数.
- 仅在需要时与数据库同步.
- 升级到最新版本的 Metabase.
- 保持您的浏览器为最新版本.
仅请求您需要的数据
如果人们运行大量返回大量记录的查询，那么 Metabase 速度快也没用：用户获取数据的速度将仅与您的数据仓库返回请求记录的速度一样快。有时人们在仪表板上做得过火：当加载具有（例如）50 个问题的仪表板时，它会发送 50 个同时请求来请求数据。根据数据库的大小，可能需要相当长的时间才能返回这些记录。
但这并非全部。Metabase 不会仅仅因为您在仪表板中放置更多问题而变慢。如果您的查询没有提取大量数据，或者您的数据仓库可以在一秒钟内返回结果，那么 50 个问题将很快加载。
但总的来说，鼓励人们保持仪表板的重点突出。仪表板旨在讲述关于您数据的故事，而您只需几个问题（甚至一个问题）就可以讲述一个好的故事。利用 Metabase 的数据探索工具来了解您的数据（例如预览表格中记录的能力），以便您可以精确地找到回答问题所需的记录。
因此，请确保每个问题都是完成仪表板所必需的，并且在跨时间和空间查询数据时要格外注意，因为您可以通过将问题限制在较短的时间跨度或较小的区域来过滤掉大量不必要的数据。
使用托管的关系型数据库来存储您的 Metabase 应用程序数据
应用程序数据库存储与 Metabase 应用程序相关的所有问题、仪表板、集合、权限和其他数据。您可以使用关系型数据库（如 PostgreSQL 或 MySQL）来管理您的应用程序数据库，但我们建议使用托管解决方案，如 AWS RDS。RDS 将自动执行备份，并使您可以轻松地在扩展时调整存储和计算，从而减少您需要担心的一件事。
缓存您的查询
您可以配置缓存以存储最近提出的问题的结果，以便无需重新计算。Metabase 将向人们显示结果的时间戳，如果他们想重新运行查询，他们可以手动刷新问题的结果。缓存适用于不经常更新的结果。
查找瓶颈
Pro 和 Enterprise 计划提供 使用情况分析，供您监控应用程序的使用情况和性能。例如，您可以查看正在提出的问题数量、提问者以及问题运行所需的时间，这可以帮助识别任何需要注意的瓶颈。
增加应用程序数据库的最大连接数
Metabase 应用程序数据库的默认连接数由 MB_APPLICATION_DB_MAX_CONNECTION_POOL_SIZE 环境变量指定，目前默认设置为 15。如果您的使用量经常消耗所有这些连接，则可以通过增加最大连接数来提高性能。或者，您可以通过水平扩展来增加连接数（例如，如果您添加一个额外的 Metabase 实例，您实际上向应用程序数据库添加了额外的 15 个连接）。
您可以通过查看日志来检查连接数，并查找类似 ... App DB connections: 12/15 的行。在该示例中，Metabase 正在使用 15 个可用应用程序数据库连接中的 12 个。
增加到每个数据库的最大连接数
同样，单个 Metabase 实例到每个数据库的默认最大连接数为 15。每个数据库都是 15 个，因此如果您已将 Metabase 连接到两个数据库，您将最多有 30 个连接。
您可以通过更改 MB_JDBC_DATA_WAREHOUSE_MAX_CONNECTION_POOL_SIZE 环境变量来增加到每个数据库的最大连接数。与上面的应用程序数据库连接一样，您也可以通过水平扩展来增加连接数。每个额外的 Metabase 实例将使最大连接数增加 15 个（或您设置的任何最大值）。要了解更多信息，请参阅我们的关于环境变量的文档。
仅在需要时与数据库同步
默认情况下，Metabase 每小时执行一次轻量级同步。同步不会复制您的任何数据。Metabase 只是检查以确保其应用程序数据库中维护的表、列和行列表与数据库中的表、列和行保持同步。
您可以设置这些同步的时间和频率。对于大型数据库，您可以考虑限制 Metabase 执行同步的次数，并将这些同步限制在非高峰时段，特别是如果您不经常向数据库添加新表。
升级到最新版本的 Metabase
如果您尚未升级，我们建议您升级到最新的 Metabase 版本，以获得最新的性能改进。
通过 HTTP/2 上的 HTTPS 提供 Metabase 服务
通过 HTTP/2 上的 HTTPS 提供 Metabase 实例可以提高性能，因为 HTTP/1.1 上的浏览器可以将连接限制为每个域大约 6 个并发连接，而 HTTP/2 在单个连接上进行多路复用。更多可用连接无法解决数据库速度慢或 Metabase 实例线程耗尽的问题，但您至少会知道您的浏览器没有限制您的连接。
保持您的浏览器为最新版本
Metabase 是一个 Web 应用程序，可以从最新版本的浏览器中受益，如 Firefox、Chrome、Edge 和 Safari。
支持的部署方式
有很多方法可以设置 Metabase；我们最喜欢的一些包括
- AWS Elastic Beanstalk：查看我们在 Elastic Beanstalk 上设置 Metabase 的指南。我们使用 Elastic Beanstalk 来托管我们的内部 Metabase 应用程序。
- Docker：请参阅在 Docker 上运行 Metabase。
Google Cloud Platform、Microsoft Azure、Digital Ocean 和其他云提供商为托管您的 Metabase 应用程序提供了其他绝佳的替代方案。
托管 Metabase
如果您不想处理 Metabase 应用程序的维护和管理，Metabase 提供了托管解决方案。您仍然需要确保您的数据源性能良好，但您不再需要管理 Metabase 应用程序的运行。
获取帮助
如果您仍有疑问，很可能有人已经问过相同的问题。查看 Metabase 讨论论坛 并搜索您的问题。如果您找不到解决方案，请提交您自己的问题。
下一步：使用 Metabase API
Metabase API 简介。