衡量企業應用數據庫性能的6大指標

【編者按】本文做者是 Omed Habib，在其職業生涯中花費了大量的時間不斷探索一些新方法以提升大型 Web 應用的性能情況。本篇文章中，做者詳細介紹了數據庫的六大性能指標，幫助咱們更好對數據庫性能進行評估和改進。

在前一篇文章中，咱們曾對 SQL 和非 SQL 進行過簡要介紹。本文基於這些主題，經過回顧最重要的六個性能指標，幫助評估企業應用數據庫的健康情況。

具體來講，本文包括如下內容:

• 事務

• 查詢性能

• 用戶和查詢衝突

• 容量

• 配置

• NoSQL 數據庫

一、事務

事務能夠觀察真實用戶的行爲：可以在應用交互時捕獲實時性能。衆所周知，測量事務的性能包括獲取整個事務的響應時間和組成事務的各個部分的響應時間。一般咱們能夠用這些響應時間與知足事務需求的基線對比，來肯定當前事務是否處於正常狀態。

若是你只想衡量應用的某個方面，那麼能夠評估事務的行爲。因此，儘管容器指標可以提供更豐富的信息，而且幫助你決定什麼時候對當前環境進行自動測量，但你的事務就足以肯定應用性能。無需嚮應用程序服務器獲取 CPU 的使用狀況，你更應該關心用戶是否完成了事務，以及該事務是否獲得了優化。

補充一個小知識點，事務是由入口點決定的，經過該入口點能夠啓動事務與應用進行交互。

一旦定義了事務，會在整個應用生態系統中對其性能進行測量，並將每一個事務與基線進行比對。例如，咱們可能會決定當事務的響應時間與基線相比，一旦慢於平均響應時間的兩個標準差是否就應該斷定爲異常，如圖1所示。

圖1-基於基線評估當前事務響應時間

用於評估事務的基線與正在進行的事務活動在時間上是一致的，但事務會由每一個事務執行來完善。例如，當你選定一個基線，在當前事務結束以後，將事務與平均響應時間按天天的小時數和每週的天數進行對比，全部在那段時間內執行的事務都將會被歸入下週的基線中。經過這種機制，應用程序能夠隨時間而變化，而無需每次都重建原始基線；你能夠將其看做是一個隨時間移動的窗口。

總之，事務最能反映用戶體驗的測量方法，因此也是衡量性能情況最重要的指標。

二、查詢性能

最容易檢測到查詢性能是否正常的指標就是查詢自己。由查詢引發的問題可能會致使時間太長而沒法識別所需數據或返回數據。因此不妨在查詢中排查如下問題。

選擇過多冗餘數據

編寫查詢語句來返回適當的數據是遠遠不夠的，極可能你的查詢語句會返回太多列，從而致使選擇行和檢索數據變得異常緩慢。因此，最好是列出所需的列，而不是直接用 SELECT*。當須要在特定字段中查詢時，該計劃可能會肯定一個覆蓋索引從而加快結果返回。覆蓋索引一般會包含查詢中使用的全部字段。這意味着數據庫能夠僅從索引中產生結果，而不須要經過底層表來構建。

另外，列出結果中所需的列不只能夠減小傳輸的數據，還能進一步提升性能。

表之間的低效聯接

聯接會致使數據庫將多組數據帶到內存中進行比較，這會產生多個數據庫讀取和大量 CPU。根據表的索引，聯接還可能須要掃描兩個表的全部行。若是寫很差兩個大型表之間的聯接，就須要對每一個表進行完整掃描，這樣的計算量將會很是大。其餘會拖慢聯接的因素包括聯接列之間存在不一樣的數據類型、須要轉換或加入包含 LIKE 的條件，這樣就會阻止使用索引。另外，還需注意避免使用全外聯接；在恰當的時候使用內部聯接只返回所需數據。

索引過多或過少

若是查詢優化沒有可用的索引時，數據庫會從新掃描表來產生查詢結果，這個過程會生成大量的磁盤輸入/輸出（I/O）。適當的索引能夠減小排序結果的須要。雖然非惟一值的索引在生成結果時，不能像惟一索引那樣方便。若是鍵越大，索引也會變大，並經過它們建立更多的磁盤 I/O。大多數索引是爲了提升數據檢索的性能，但也須要明白索引自己也會影響數據的插入和更新，由於全部相關聯的指標都必須更新。

太多的SQL致使爭用解析資源

任何 SQL 查詢在執行以前都必須被解析，在生成執行計劃以前須要對語法和權限進行檢查。因爲解析很是耗時，數據庫會保存已解析的 SQL 來重複利用，從而減小解析的耗時。由於 WHERE 語句不一樣，因此使用文本值的查詢語句不能被共享。這將致使每一個查詢都會被解析並添加到共享池中，因爲池的空間有限，一些已保存的查詢會被捨棄。當這些查詢再次出現時，則須要從新解析。

三、用戶和查詢衝突

數據庫支持多用戶，但多用戶活動也可能形成衝突。

由慢查詢致使的頁/行鎖定

爲了確保查詢產生精確的結果，數據庫必須鎖定表以防止在運行讀取查詢時再發生其餘的插入和更新行爲。若是報告或查詢至關緩慢，須要修改值的用戶可能須要等待至更新完成。鎖提示能幫助數據庫使用最小破壞性的鎖。從事務數據庫中分離報表也是一種可靠的解決方法。

事務鎖和死鎖

當兩個事務被阻塞時會出現死鎖，由於每個都須要使用被另外一個佔用的資源。當出現一個普通鎖時，事務會被阻塞直到資源被釋放。但卻沒有解決死鎖的方案。數據庫會監控死鎖並選擇終止其中一個事務，釋放資源並容許該事務繼續進行，而另外一個事務則回滾。

批處理操做形成資源爭奪

批處理過程一般會執行批量操做，如大量的數據加載或生成複雜的分析報告。這些操做是資源密集型的，但可能影響在線用戶的訪問應用的性能。針對此問題最好的解決辦法是確保批處理在系統使用率較低時運行，好比晚上，或用單獨的數據庫進行事務處理和分析報告。

四、容量

並非全部的數據庫性能問題都是數據庫問題。有些問題也是硬件不合適形成的。

CPU 不足或 CPU 速度太慢

更多 CPU 能夠分擔服務器負載，進一步提升性能。數據庫的性能不只是數據庫的緣由，還受到服務器上運行其餘進程的影響。所以，對數據庫負載及使用進行審查也是必不可少的。因爲 CPU 的利用率時時在變，在低使用率、平均使用率和峯值使用率的時間段分別檢查該指標能夠更好地評估增長額外的 CPU 資源是否有益。

IOPS 不足的慢磁盤

磁盤性能一般以每秒輸入/輸出操做（IOPS）來計。結合 I/O 大小，該指標能夠衡量每秒的磁盤吞吐量是多少兆。同時，吞吐量也受磁盤的延遲影響，好比須要多久才能完成請求，這些指標主要是針對磁盤存儲技術而言。傳統的硬盤驅動器（HDD）有一個旋轉磁盤，一般比固態硬盤（SSD）或閃存更慢。直到近期，SSD 雖然仍比 HDD 貴，但成本已經降了下來，因此在市場上也更具競爭力。

所有或錯誤配置的磁盤

衆所周知，數據庫會被大量磁盤訪問，因此不正確配置的磁盤可能帶來嚴重的性能缺陷。磁盤應該適當分區，將系統數據目錄和用戶數據日誌分開。高度活躍的表應該區分以免爭用，經過在不一樣磁盤上存放數據庫和索引增長並行放置，但不要將操做系統和數據庫交換空間放置在同一磁盤上。

內存不足

有限或不恰當的物理內存分配會影響數據庫性能。一般咱們認爲可用的內存更多，性能就越好。監控分頁和交換,在多個非繁忙磁盤中創建多頁面空間，進一步確保分頁空間分配足夠知足數據庫要求；每一個數據庫供應商也能夠在這個問題上提供指導。

網速慢

網絡速度會影響到如何快速檢索數據並返回給終端用戶或調用過程。使用寬帶鏈接到遠程數據庫。在某些狀況下，選擇 TCP/IP 協議而不是命名管道可顯著提升數據庫性能。

五、配置

每一個數據庫都需設置大量的配置項。一般狀況下，默認值可能不足以知足數據庫所需的性能。因此，檢查全部的參數設置，包括如下問題。

緩衝區緩存過小

經過將數據存儲在內核內存，緩衝區緩存能夠進一步提升性能同時減小磁盤 I/O。當緩存過小時，緩存中的數據會更頻繁地刷新。若是它再次被請求，就必須從磁盤重讀。除了磁盤讀取緩慢以外，還給 I/O 設備增添了負擔從而成爲瓶頸。除了給緩衝區緩存分配足夠的空間，調優 SQL 查詢能夠幫助其更有效地利用緩衝區緩存。

沒有查詢緩存

查詢緩存會存儲數據庫查詢和結果集。當執行相同的查詢時，數據會在緩存中被迅速檢索，而不須要再次執行查詢。數據會更新失效結果，因此查詢緩存是惟一有效的靜態數據。但在某些狀況下，查詢緩存卻可能成爲性能瓶頸。好比當鎖定爲更新時，巨大的緩存可能致使爭用衝突。

磁盤上臨時表建立致使的 I/O 爭用

在執行特定的查詢操做時，數據庫須要建立臨時表，如執行一個 GROUP BY 子句。若是可能，在內存中建立臨時表。可是，在某些狀況下，在內存中建立臨時表並不可行，好比當數據包含 BLOB 或 TEXT 對象時。在這些狀況下，會在磁盤上建立臨時表。大量的磁盤 I / O 都須要建立臨時表、填充記錄、從表中選擇所需數據並在查詢完成後捨棄。爲了不影響性能，臨時數據庫應該從主數據庫中分離出來。重寫查詢還能夠經過建立派生表來減小對臨時表的需求。使用派生表直接從另外一個 SELECT 語句的結果中選擇，容許將數據加到內存中而不是當前磁盤上。

六、NoSQL 數據庫

NoSQL 的優點在於它處理大數據的能力很是迅速。可是在實際使用中，也應該綜合參考 NoSQL 的缺點，從而決定是否適合你的用例場景。這就是爲何NoSQL一般被理解爲 「不只僅是 SQL」，說明了 NoSQL 並不老是正確的解決方案，也不必徹底取代 SQL，如下分別列舉出五大主要緣由。

挑剔事務

難以保持 NoSQL 條目的一致性。當訪問結構化數據時，它並不能徹底確保同一時間對不一樣表的更改都生效。若是某個過程發生崩潰，表可能會不一致。一致事務的典型表明是複式記帳法。相應的信貸必須平衡每一個借方，反之亦然。若是雙方數據不一致則不能輸入。NoSQL 則可能沒法保證「收支平衡」。

複雜數據庫

NoSQL 的支持者每每以高效代碼、簡單性和 NoSQL 的速度爲傲。當數據庫任務很簡單時，全部這些因素都是優點。但當數據庫變得複雜，NoSQL 會開始分解。此時，SQL 則比 NoSQL 更好地處理複雜需求，由於 SQL 已經成熟，有符合行業標準的接口。而每一個 NoSQL 設置都有一個惟一的接口。

一致聯接

當執行 SQL 的聯接時，因爲系統必須從不一樣的表中提取數據進行鍵對齊，因此有一個巨大的開銷。而 NoSQL 彷佛是一個空想，由於缺少聯接功能。全部的數據都在同一個表的一個地方。當檢索數據時，它會同時提取全部的鍵值對。問題在於這會建立同一數據的多個副本。這些副本也必須更新，而這種狀況下，NoSQL 沒有功能來確保更新。

Schema設計的靈活性

因爲 NoSQL 不須要 schema，因此在某些狀況下也是獨一無二的。在之前的數據庫模型中，程序員必須考慮全部須要的列可以擴展，可以適應每行的數據條目。在 NoSQL 下，條目能夠有多種字符串或者徹底沒有。這種靈活性容許程序員迅速增長數據。可是，也可能存在問題，好比當有多個團體在同一項目上工做時，或者新的開發團隊接手一個項目時。開發人員可以自由地修改數據庫，也可能會不斷實現各類各樣的密鑰對。

資源密集型

NoSQL 數據庫一般比關係數據庫更加資源密集。他們須要更多的 CPU 儲備和 RAM 分配。出於這個緣由，大多數共享主機公司都不提供 NoSQL。你必須註冊一個 VPS 或運行本身的專用服務器。另外一方面，SQL 主要是在服務器上運行。初期的工做都很順利，但隨着數據庫需求的增長，硬件必須擴大。單個大型服務器比多個小型服務器昂貴得多，價格呈指數增加。因此在這種企業計算場景下，使用 NoSQL 更爲划算，例如那些由谷歌和 Facebook 使用的服務器。

七、總結

本文主要介紹了評估數據庫情況時須要考量的六個最主要的因素：

• 事務

• 查詢性能

• 用戶和查詢衝突

• 容量

• 配置

• NoSQL 數據庫

（編譯自：https://dzone.com/articles/top-6-database-performance-metrics-to-monitor-in-e）

OneAPM 爲您提供端到端的 Java 應用性能解決方案，咱們支持全部常見的 Java 框架及應用服務器，助您快速發現系統瓶頸，定位異常根本緣由。分鐘級部署，即刻體驗，Java 監控歷來沒有如此簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客