數據庫容量規劃

已發表: 2016-06-21

注意：這篇文章的靈感來自 Julia Evans 最近關於容量規劃的文章。

關係型數據庫管理系統

首先，讓我們建立一些基本規則。 是的……這篇文章是為我們這些使用 MySQL 的人準備的，一次只有一個 writer 和 2 個或更多只讀副本。 我將在這裡討論的很多內容都以不同的方式適用於或根本不適用於多寫入器集群數據存儲，儘管這些也有自己的一套妥協和警告。 所以……你的里程肯定會有所不同。

但是，無論您是使用自託管的物理主機還是在 AWS 中，您都可以使用類似魔術的預留實例和近乎即時的配置，這篇博文都將適用。 處於“雲”中不會妨礙您了解基礎設施的能力和限制，也不會免除您對團隊和客戶的責任。

分片

在我之前的一篇文章中，我已經對此進行了大量介紹，我主要關注的是功能分片或水平分片的好處。 是的，這是一個絕對的先決條件，因為您用於訪問數據庫層的內容將決定您必須擴展多少靈活性。

如果您是一家全新的公司，您可能在第一天就不需要功能分片，但是，如果您希望（我懷疑您確實這樣做）成長，請不要使用不允許您拆分的開源 ORM您的數據以功能為基礎。 如果您也沒有在一個模式中使用所有關係數據來創建公司，那麼您將獲得獎勵積分。

能夠拆分讀取和寫入

這是您需要能夠做到的事情，但不一定作為一成不變的規則強制執行。 在某些用例中，需要很快讀取寫入內容，並且對延遲/最終一致性等內容的容忍度很低。 這些是可以的，但是在相同的應用程序中，您還將有可以容忍更長的最終一致性時間跨度的讀取場景。 當此類讀取量很大時，您是否真的希望該捲髮送給您的單個作者（如果不是真的需要）？ 幫自己一個忙，並確保在你成長的日子裡，你可以控制代碼中讀取或寫入 IP 的使用。

現在進入實際容量規劃的思考過程……數據庫集群跟不上，我該怎麼辦？

確定係統瓶頸

  • 您是否在寫入或讀取方面遇到瓶頸？
  • 問題是否表現為高 CPU？
  • 它是否顯示為 IO 容量？
  • 在沒有明確的讀取查詢罪魁禍首的情況下，副本是否會變得越來越滯後？
  • 是鎖嗎？
  • 我怎麼知道它是什麼？

這些中的每一個都可以單獨成為一個帖子。 我要說明的一點是，您必須熟悉您的系統和數據庫特定指標，才能找出瓶頸所在。

你需要一個基線

始終確保您至少有幾週前可用於可視化的基本系統指標。 許多工具都提供了這一點（Cacti、Munin、Graphite……等）。 一旦您知道您最受約束的系統指標，您需要建立基線和峰值。 否則，確定您當前的問題是來自新應用程序的錯誤還是實際增長將比您想要的更容易出錯。

然而，基本的服務器指標只能做到這一點——在某些時候你會發現你還需要基於上下文的指標。 查詢性能和應用程序端感知性能將告訴您應用程序對查詢的響應時間。 有許多工具可以進行這種上下文重跟踪。 有些是開源的，如 Anemometer 和商業工具，如 Vivid Cortex（我們在 SendGrid 使用這些工具。請參閱我們在這裡討論它。）即使只是從應用程序的角度跟踪這些指標並將它們作為 statsd 指標拋出它們將是一個很好的第一步。 但是，您必須儘早習慣這樣一個事實，即您的應用程序所感知的就是您的客戶所感知的。 你必須先找到一個知道的方法。

了解您的業務的流量模式

您是一家在特定工作日（例如營銷）容易受到極端高峰影響的企業嗎？ 您是否定期發布遊戲，例如游戲，使您的流量增加三倍或四倍？ 這類問題將決定您應該保留多少預留空間，或者您是否需要投資於彈性增長。

確定原始流量數量與使用容量的比率

這只是對“如果我們不進行代碼優化，有多少電子郵件/銷售/在線用戶/隨便什麼”的答案，我們可以使用我們現在擁有的數據庫實例來提供服務嗎？

理想情況下，這是一個特定的值，使規劃一年增長的數學成為一個簡單的數學方程式。 但是生活從來都不是理想的，這個價值會隨著季節或完全外部的快樂因素而變化，比如簽約一個新的主要客戶。 在早期的初創公司中，這個數字是一個移動速度更快的目標，但隨著公司從早期過渡到具有更可預測的業務增長模式的更成熟的業務，它應該會穩定下來。

我真的需要購買更多機器嗎？

您需要找到一種方法來確定這是否是真正的容量——我需要拆分寫入以支持更多的並發寫入負載或添加更多的只讀副本。 基於代碼的性能瓶頸（最近部署的這個新查詢確實可以將其結果緩存在更便宜的東西中，而不是像數據庫一樣擊敗）。

你是怎樣做的？ 您需要熟悉您的查詢。 最重要的一步是 innotop、slow log 和 Percona Toolkit 的 pt-query-digest 的組合。 您可以通過將數據庫日誌傳送到中央位置並自動執行摘要部分來自動執行此操作。

但這也不是全部，如果您將其閾值降低太多，慢速日誌會佔用大量性能。 如果您可以接受較少選擇性的採樣，您將需要檢測應用程序和數據存儲之間的整個對話。 在開源領域，您可以像 tcpdump 一樣基本，也可以使用 Datadog、New Relic 或 VividCortex 等託管產品。

打個電話

容量規劃可以是 90% 的科學和 10% 的藝術，但那 10% 不應該意味著我們不應該盡可能多地為圖片而努力。 作為工程師，我們有時會專注於缺失的 10%，而沒有意識到如果我們完成了工作，那 90% 可以讓我們更好地了解堆棧的健康狀況，更有效地利用我們的時間優化性能和規劃容量謹慎增加，最終為我們的產品帶來更好的投資回報。