大規模 Metabase
將 Metabase 擴展以支援更多人員和資料庫的最佳實務。
Metabase 是一款可擴展、久經考驗的軟體，數以萬計的公司使用它來提供高品質的自助式分析。它透過水平擴展支援高可用性，並且開箱即用就非常有效率：配備 4 GB RAM 的單核心機器可以將 Metabase 擴展到數百名使用者。
本文提供關於如何在生產環境中保持 Metabase 順暢運作的高階指南和最佳實務，隨著使用者和資料來源的數量增加。每個資料系統都不同，因此我們只能在高階層級討論擴展策略，但您應該能夠將這些策略轉換為您的特定環境和使用方式。
影響 Metabase 效能和可用性的因素
Metabase 在垂直和水平方向上都能良好擴展，但它只是您的資料倉儲的一個組件，而系統的整體效能將取決於系統的組成和您的使用模式。影響您使用 Metabase 體驗的主要因素包括
- 連接到 Metabase 的資料庫數量。
- 每個資料庫中的表格數量。
- 您的資料倉儲的效率。
- 儀表板中問題的數量。
例如，如果問題需要執行資料庫需要 30 分鐘才能完成的查詢，那麼您執行多少個 Metabase 執行個體都無關緊要：這就只是需要 30 分鐘。解決方案是重新評估您對該資料的需求（您真的每次都需要所有資訊嗎？），或者尋找方法來改善資料庫的效能，例如重新組織、索引或快取您的資料。
資料庫和表格的數量也可能影響用戶端效能，但僅限於您管理數百個資料庫和/或數千個表格的大規模情況，因為中繼資料本身可能需要查詢大量內容。為了即使在這個規模下也能保持效能順暢，您可以管理 Metabase 何時與您連線的資料庫同步其元資料。
現在，讓我們確保您的 Metabase 應用程式已良好調整以進行擴展。
垂直擴展
垂直擴展是蠻力方法。為 Metabase 提供更多核心和記憶體，它將有更多資源可用於執行其工作。如果您遇到與應用程式本身相關的效能問題（即，與資料庫的廣度和規模無關），在更強大的機器上執行 Metabase 可以提高效能。
每 20 個並行使用者，大約需要 1 個 CPU 核心和 1GB 的 RAM
Metabase 開箱即用就已經非常有效率。首先，配備 2 GB RAM 的單核心機器對於單獨使用者或小型團隊來說應該綽綽有餘。
何時新增更多記憶體和核心：如果您看到伺服器持續使用超過目前資源（記憶體或運算）的 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 的資料探索工具（包括記錄預覽），以便他們僅查詢與他們嘗試回答的問題相關的資料。
- 決定是否使用資料庫或資料倉儲。 人們通常從使用交易資料庫（如 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 將向人們顯示結果的時間戳記，如果他們想要重新執行查詢，他們可以手動重新整理問題的結果。快取適用於不常更新的結果。
尋找瓶頸
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 簡介。