Metabase 规模化
扩展 Metabase 以支持更多用户和数据库的最佳实践。
Metabase 是一款可扩展、久经考验的软件，被数万家公司用于提供高质量的自助式分析。它通过水平扩展支持高可用性，并且开箱即用效率高：一台配备 4 GB 内存的单核机器可以将 Metabase 扩展到数百个用户。
本文提供了关于如何随着用户和数据源数量的增加，使 Metabase 在生产环境中平稳运行的高级指导和最佳实践。每个数据系统都不同，因此我们只能从高层次讨论扩展策略，但您应该能够将这些策略应用于您的特定环境和使用场景。
影响 Metabase 性能和可用性的因素
Metabase 在垂直和水平方向上都能很好地扩展，但它只是您数据仓库的一个组件，您系统的整体性能将取决于您的系统构成和使用模式。影响您使用 Metabase 体验的主要因素包括：
- 连接到 Metabase 的数据库数量。
- 每个数据库中的表数量。
- 数据仓库的效率。
- 仪表盘中的问题数量。
例如，如果一个问题需要运行一个数据库需要 30 分钟才能完成的查询，那么无论您运行多少个 Metabase 实例都没有意义：它仍然需要 30 分钟。解决方案是重新评估您对该数据的需求（您每次都需要所有这些信息吗？）或者寻找方法来提高数据库的性能，例如重新组织、索引或缓存数据。
数据库和表的数量也会影响客户端性能，但这仅限于您管理数百个数据库和/或数千个表的大规模情况，因为元数据本身可能需要大量查询。为了即使在此规模下也能保持平稳性能，您可以管理 Metabase 何时将其元数据与连接的数据库同步。
现在，让我们确保您的 Metabase 应用程序已针对扩展进行了良好调优。
垂直扩展
垂直扩展是一种蛮力方法。为 Metabase 提供更多核心和内存，它将拥有更多可用资源来完成工作。如果您遇到与应用程序本身相关的性能问题（即与数据库的广度和规模无关），在更强大的机器上运行 Metabase 可以提高性能。
每 20 个并发用户，大约需要 1 个 CPU 核心和 1GB 内存
Metabase 开箱即用效率很高。首先，一台配备 2 GB 内存的单核机器对于个人用户或小型团队来说应该绰绰有余。
何时增加更多内存和核心：如果您发现您的服务器持续使用其当前资源（内存或计算）的 80% 以上。
Metabase 应用程序数据库的任何操作都应在不到一秒的时间内响应（不包括 Metabase 连接的数据仓库的响应时间）。
4-8 GB 内存的机器应该能够处理数百个用户，如果需要，您可以增加核心数量和内存大小。
虽然增加更多核心和内存可能有效，但通常最好使用水平扩展来支持更多用户。原因是每个 Metabase 实例都内置了数据库连接限制，以防止实例因请求过多而使您的数据仓库不堪重负。您可以增加实例可用的连接数，但我们仍然建议使用多个实例。
水平扩展（推荐）
水平扩展不是增加运行 Metabase 的服务器的大小，而是启动更多服务器，每个服务器都运行 Metabase，并将其连接到相同的应用程序数据库。这样，您可以将多个 Metabase 实例与负载均衡器结合使用，以将流量引导到这些实例。Metabase 开箱即用支持水平扩展，因此您无需任何特殊配置即可运行多个 Metabase 实例。当 Metabase 服务器连接到现有应用程序数据库时，它会识别自己是集群的一部分。
水平扩展的主要用例是提高可靠性（又称“高可用性”），但水平扩展也可以提高多用户性能。当负载均衡时，高流量、CPU 密集型的 Metabase 实例在部分流量被引导到其他实例时将表现更好（更快），因为 CPU 负载将分布在多台机器上。
Metabase 附带一个本地 H2 数据库来存储您的应用程序数据（您的所有问题、仪表盘、日志和其他 Metabase 数据），但在生产环境中运行 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 的数据探索工具（包括记录预览），以便他们只查询与他们试图回答的问题相关的数据。
- 决定是使用数据库还是数据仓库。 人们通常使用事务型数据库（例如 MySQL 或 PostgreSQL）开始使用 Metabase。虽然这些数据库的扩展性很好，但它们通常没有针对 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 将向用户显示结果的时间戳，如果他们想重新运行查询，可以手动刷新问题结果。缓存适用于不经常更新的结果。
寻找瓶颈
专业版和企业版方案提供使用情况分析，供您监控应用程序的使用情况和性能。例如，您可以查看提出了多少问题、由谁提出以及问题运行了多长时间，这有助于识别需要注意的任何瓶颈。
增加应用数据库的最大连接数
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，以获得最新的性能改进。
通过 HTTPS over HTTP/2 提供 Metabase 服务
通过 HTTPS over HTTP/2 提供 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 简介。