價格
登入 開始使用
文件 學習
首頁
課程
Metabase 基礎知識
培養您的資料技能
速查表

如何在生產環境中執行 Metabase

如果您是自行託管 Metabase，以下是一些基準和最佳實務。

本文說明 Metabase 的生產就緒設定的外觀，包括伺服器大小調整、最佳實務和要避免的陷阱。本文適用於對自行託管 Metabase 感興趣的人員。如果您希望我們為您執行 Metabase，請註冊免費試用。

Metabase JAR 中的內容

就背景而言，Metabase 是一個 Web 應用程式。其後端以 Clojure 撰寫，前端則以 JavaScript、Typescript 和 Clojurescript 搭配 React 框架撰寫。

預設情況下，整個應用程式是獨立的：後端和提供前端的 Web 伺服器都以相同的套件出貨。該套件是一個 JAR 檔案，可以在安裝 Java 執行階段環境的任何地方執行。

Metabase 也隨附容器映像，其中封裝了 JRE 和 Metabase JAR (您也可以使用 Podman 執行)。

您只需要 JAR 和資料庫

Metabase JAR running in a container, saving its application data in a Postgres database.

若要在生產環境中執行 Metabase，您需要兩件事

  1. Metabase JAR 或容器映像。
  2. 專用的 PostgreSQL 資料庫，用於儲存 Metabase 的應用程式資料庫

您也可以使用 MySQL/MariaDB 來儲存 Metabase 的應用程式資料庫，但我們強烈建議使用 Postgres。

為何您需要使用個別的應用程式資料庫

Metabase 會將其所有實體 (儀表板、問題、帳戶、組態) 儲存在其應用程式資料庫中。

如果您堅持使用預設的檔案型應用程式資料庫，您的資料庫最終將會無法挽回地損毀，而且您必須從頭開始 (在遺失所有工作之後：您的所有問題、儀表板等等)**。

因此，您要避免做的一件事是使用 Metabase JAR 隨附的預設應用程式資料庫。該嵌入式資料庫僅供本機使用。我們將該嵌入式資料庫作為一種贈品，送給只想在其機器上試用 Metabase 的人員。該嵌入式 H2 資料庫也包含一些範例資料，可供人員試用。這並非用於生產環境。

同樣地，如果您在容器中執行 Metabase，每當您的容器被新的版本取代時，您就會遺失所有工作。容器旨在成為暫時性的，因此請勿將您的資料保留在其中。

您可以使用專用的 PostgreSQL 應用程式資料庫來避免所有這些問題。

如果您已經開始使用預設的 H2 資料庫

沒關係。但您應該盡快移轉至生產資料庫。

Metabase 應用程式和資料庫伺服器及其大小調整

我們建議您至少執行兩個執行個體 (理想情況下在相同的網路上)

您想要在相同網路上執行這些執行個體的原因，是為了縮短 Metabase (應用程式) 從儲存其應用程式資料的資料庫取得回應所需的時間。絕大多數的 Metabase 作業都需要呼叫 Metabase 的 API，該 API 會使用應用程式資料庫來擷取有關問題、儀表板、表格中繼資料等的資訊。

Metabase 應用程式伺服器大小

Metabase 至少需要 1 個核心和 1GB 的 RAM 作為基準。除此之外，對於每 20 個同時使用您 Metabase 的人員，Metabase 將需要 1 個 CPU 和 2GB 的 RAM。無論您是以 JAR 或容器映像形式執行 Metabase，這些系統建議都適用。例如，如果您有 40 個同時使用者，您總共需要 3 個 CPU 核心和 5GB 的 RAM。

注意：在 v52 之前，我們建議每 20 個同時使用者僅需 1GB 的記憶體，但我們在新版本中提高了此需求，以確保安全。

Metabase 應用程式資料庫伺服器大小

應用程式資料庫可能是整個架構中最重要的元件：它是單一失敗點，而且應用程式資料庫將查詢傳回 Metabase 應用程式伺服器的速度越快越好。作為起點，請為執行應用程式資料庫的伺服器配置 1 個 CPU 核心和 2GB 的 RAM。一般而言，對於每 40 個同時使用您 Metabase 的人員，PostgreSQL 應用程式資料庫將需要 1 個 CPU 核心和 1 GB 的 RAM。

每個 Metabase 環境都必須有其專用的應用程式資料庫

依環境而言，我們指的是一個或多個 Metabase JAR (或容器映像) 和一個應用程式資料庫。如果您正在執行多個環境，您可以在相同的應用程式資料庫伺服器上為每個環境執行多個應用程式資料庫，但每個環境都必須有其專用的應用程式資料庫。

維護

讓事物順利運作。

Metabase 伺服器維護

您不需要執行任何動作。它應該可以正常運作。

Metabase 應用程式資料庫維護

所有資料庫都需要維護才能獲得最佳效能，PostgreSQL 和 MySQL 也不例外。請遵循 PostgreSQL 的最佳實務進行維護 (https://postgresql.dev.org.tw/docs/current/maintenance.html) (特別是備份

此應用程式資料庫應為

  • 每天備份。
  • 每週執行 Vacuum 和分析。

此外，應定期封存和刪除不再需要的卡片和儀表板。

資料倉儲伺服器維護

資料倉儲的維護取決於您使用的資料倉儲。請參閱資料庫的文件以取得指引。

範例負載測試

在此簡易的負載測試中，Metabase API 在 K6 上達成了下列度量

checks.........................: 100.00% ✓ 237963     ✗ 0
data_received..................: 16 GB   7.1 MB/s
data_sent......................: 119 MB  52 kB/s
http_req_blocked...............: avg=4.19µs  min=559ns  med=3.5µs   max=37.63ms  p(90)=5.9µs   p(95)=7.2µs
http_req_connecting............: avg=211ns   min=0s     med=0s      max=37.55ms  p(90)=0s      p(95)=0s
http_req_duration..............: avg=41ms    min=1.21ms med=20.28ms max=8.1s     p(90)=84.22ms p(95)=125.62ms
 { expected_response:true }...: avg=41ms    min=1.21ms med=20.28ms max=8.1s     p(90)=84.22ms p(95)=125.62ms
http_req_failed................: 0.00%   ✓ 0          ✗ 259596
http_req_receiving.............: avg=12.02ms min=8.64µs med=57.34µs max=778.49ms p(90)=41.43ms p(95)=67.33ms
http_req_sending...............: avg=17.39µs min=3.32µs med=15.13µs max=5.86ms   p(90)=26.11µs p(95)=32.59µs
http_req_tls_handshaking.......: avg=0s      min=0s     med=0s      max=0s       p(90)=0s      p(95)=0s
http_req_waiting...............: avg=28.96ms min=1.18ms med=14.86ms max=8.1s     p(90)=61.91ms p(95)=84.26ms
http_reqs......................: 259596  113.584624/s
iteration_duration.............: avg=18.29s  min=17.6s  med=17.81s  max=29s      p(90)=19.85s  p(95)=20.88s
iterations.....................: 7211    3.155128/s
vus............................: 1       min=1        max=100
vus_max........................: 100     min=100      max=100

就背景而言，測試是以 Metabase v44.7 在具有 16 個核心和 4GB RAM 的伺服器上執行。它已使用環境變數 JAVA_TOOL_OPTIONS: -Xmx3584m -Xms2048m 進行組態設定。應用程式資料庫為 Postgres 15.2 版，具有 2 個核心和 4GB 的 RAM。無 HTTPS。

負載測試無法模擬真實生活的使用情況。通常，人員在您 Metabase 中的活動會產生不同的 API 呼叫模式。您也會有在背景執行的非同步處理序。如果 Metabase 缺乏足夠的 CPU 資源，它會將作業排入佇列。如果佇列溢位，Metabase 可能會當機並嘗試復原。在這種情況下，您需要配置更多核心。

非同步處理序

Metabase 將定期執行非同步處理序，這些處理序將使用 CPU 和 RAM，具體取決於您表格上的表格數量和欄位數量。

這些處理序為

  • 同步
  • 掃描
  • 指紋識別
  • 欄位值
  • 模型快取
  • 問題中繼資料

如果您發現 Metabase 在特定時間段內使用大量 CPU，請檢查記錄檔，以查看 Metabase 是否正在執行任何這些處理序。如果是，您可以排程這些工作在人員未使用您 Metabase 時執行。

Metabase 會將每個工作指派給單一核心。如果您的伺服器有四個核心，Metabase 將執行的非同步處理序最大數量為三個，因為應該有一個核心可用於處理人員的要求 (一個核心應該能夠同時處理大約 10 個使用 Metabase 的人員的要求)。

可觀察性與一些需要注意的度量

Metabase 公開可由 Prometheus 抓取的度量端點。理想情況下，您已設定一些警示，以便在任何這些數字超過其中一個閾值時，您可以採取行動。

Metabase 應用程式

  • API 回應時間
  • CPU：最高 80%-90%
  • RAM：最高 80%

Metabase 應用程式資料庫

  • CPU：最高 90%
  • RAM：最高 80%
  • 磁碟使用量：最高 80%。
  • 磁碟 IOPS：檢查您磁碟的 IOPS 支援。如果您用於執行應用程式資料庫的磁碟超過磁碟聲稱支援的 IOPS，則您的磁碟會將作業排入佇列，這會影響效能。

何時增加連線集區大小

預設情況下，Metabase 的連線集區大小限制為 15 個連線。Metabase 將管理每個連線資料庫的一個集區，包括應用程式資料庫的一個集區，每個集區限制為 15 個連線。

為了處理更多人同時使用您的 Metabase，您可以使用 MB_APPLICATION_DB_MAX_CONNECTION_POOL_SIZE 環境變數來覆寫應用程式資料庫的連線限制。如果您增加此限制，您可能需要為您的應用程式資料庫提供更多 RAM，因此您應該監控您的應用程式資料庫的 RAM 使用量。如果資料庫缺乏可用 RAM，資料庫將會排隊連線，這表示當資料庫等待釋放 RAM 時，有些人會發現 Metabase 沒有回應。

Metabase 在任何給定時間只會使用它需要的連線。但是某些請求可能會佔用許多這些連線。例如，如果有人載入一個包含 20 張卡片的儀表板，Metabase 將使用其 15 個可用連線來檢索結果，並在連線可用時載入剩餘的五張卡片。

使用負載平衡器

A Metabase setup with a load balancer.

一個良好的架構實務是在 Metabase 上方使用負載平衡器，即使您只有一個伺服器在運行，並且您沒有進行任何水平擴展。稍後部署負載平衡器可能更難以實施，而且負載平衡器還可以執行 TLS 終止（又稱加密和解密 HTTP 流量）、WAF（Web 應用程式防火牆）、重新導向和其他常見任務。

請參閱 直接的負載平衡。

日誌

Metabase 會產生您應該保留的應用程式日誌。這些日誌對於除錯和稽核很有用。請查看我們關於 日誌設定 的文件。

如果您還在 Metabase 上方部署了負載平衡器或反向代理，我們建議您將這些日誌儲存到日誌彙集器。這些日誌將幫助您識別模式，並在需要時進行調查。

Metabase over HTTPS

您可以透過 HTTPS 提供 Metabase，而無需使用負載平衡器或反向代理。

請注意，如果您使用同一台伺服器來運行 Metabase 和 TLS 終止（又稱 HTTPS），Metabase 將會損失寶貴的 CPU 資源，這些資源會花費在加密/解密流量上。因此您可能想要使用負載平衡器。

要避免的陷阱

從他人的經驗中學習。

我們建議您避免使用聲稱可以自動擴展的服務

根據我們的經驗，許多聲稱可以自動擴展的服務，嗯，並不是那麼神奇。我們反而建議您設置一些可觀察性指標，監控它們，並根據這些觀察結果進行您需要的擴展變更，因為您的 Metabase 使用量會隨著公司的成長而成長。

避免使用在不使用時關閉伺服器的服務

如果您必須使用自動擴展服務，請避免任何在不使用時定期關閉伺服器的服務。

原因有兩個

  1. 非同步處理程序。Metabase 運行一些非同步處理程序，例如取得表格的元數據、刷新模型或取得篩選值。如果這些處理程序無法運行，人們將看不到 Metabase 提供的許多功能。
  2. 啟動時間 下一個登入您應用程式的第一批人將會遭受巨大的效能損失，因為伺服器將必須從完全冷啟動開始運轉。

在其他雲端供應商上運行的問題

請注意：許多雲端服務供應商將在共用基礎架構上託管您。在這種情況下，租戶共用 CPU 的存取權。多租戶伺服器租金可能更便宜，並且可以提供不錯的效能，前提是您的 CPU 使用率保持在 100% 以下。如果您的 Metabase 伺服器在一段時間內使用 100% 的 CPU，供應商可能會限制您分配的 CPU 的效能，並且您的效能將會顯著降低。在共用基礎架構中，磁碟 IOPS 也可能發生相同的限制。

升級到 Metabase 的新主要版本

通常，我們不會在次要版本之間（例如，從 1.51.1 到 1.51.2）對應用程式資料庫的結構描述進行任何變更，因此您可以在次要版本之間升級和降級而不會出現問題。

當升級到主要版本時（例如，從 1.50.9 到 1.51.3），您應該預期會有停機時間，因為 Metabase 可能需要處理應用程式資料庫的結構描述變更。結構描述變更需要多長時間取決於您的應用程式資料庫的大小。

下一步：在 Metabase 中管理人員

如何從管理數十名用戶到數千名用戶。

下一篇文章