VTS 儀表板數據庫

為了支持可擴展、高性能和靈活的持續集成儀表板,VTS 儀表板後端必須經過精心設計,並對數據庫功能有深入的了解。 Google Cloud Datastore是一個 NoSQL 數據庫,它提供事務性 ACID 保證和最終一致性以及實體組內的強一致性。但是,結構與 SQL 數據庫(甚至 Cloud Bigtable)有很大不同;除了表格、行和單元格之外,還有種類、實體和屬性。

以下部分概述了用於為 VTS Dashboard Web 服務創建有效後端的數據結構和查詢模式。

實體

以下實體存儲來自 VTS 測試運行的摘要和資源:

  • 測試實體。存儲有關特定測試的測試運行的元數據。它的鍵是測試名稱,它的屬性包括失敗計數、通過計數和從警報作業更新時的測試用例中斷列表。
  • 測試運行實體。包含來自特定測試運行的元數據。它必須存儲測試開始和結束時間戳、測試構建 ID、通過和失敗測試用例的數量、運行類型(例如預提交、提交後或本地)、日誌鏈接列表、主機機器名稱和覆蓋率摘要計數。
  • 設備信息實體。包含有關測試運行期間使用的設備的詳細信息。它包括設備構建 ID、產品名稱、構建目標、分支和 ABI 信息。這與測試運行實體分開存儲,以支持以一對多方式運行的多設備測試。
  • 分析點運行實體。匯總為測試運行中的特定分析點收集的數據。它描述了分析數據的軸標籤、分析點名稱、值、類型和回歸模式。
  • 覆蓋實體。描述為一個文件收集的覆蓋率數據。它包含 Git 項目信息、文件路徑和源文件中每行的覆蓋計數列表。
  • 測試用例運行實體。描述測試運行中特定測試用例的結果,包括測試用例名稱及其結果。
  • 用戶收藏夾實體。每個用戶訂閱都可以表示為一個實體,其中包含對測試的引用和從 App Engine 用戶服務生成的用戶 ID。這允許有效的雙向查詢(即,對於訂閱測試的所有用戶和用戶喜愛的所有測試)。

實體分組

每個測試模塊代表一個實體組的根。測試運行實體既是該組的子級,又是與各自的測試和測試運行祖先相關的設備實體、分析點實體和覆蓋實體的父級。

圖 1 。測試實體祖先。

關鍵點:在設計祖先關係時,您必須平衡提供有效且一致的查詢機制的需求與數據庫強制執行的限制。

好處

一致性要求確保未來的操作在提交之前不會看到事務的影響,並且過去的事務對當前的操作是可見的。在 Cloud Datastore 中,實體分組在組內創建了強讀寫一致性的孤島,在本例中是與測試模塊相關的所有測試運行和數據。這提供了以下好處:

  • 通過警報作業讀取和更新測試模塊狀態可以被視為原子
  • 保證測試模塊內測試用例結果的一致視圖
  • 在祖先樹中更快地查詢

限制

不建議以超過每秒一個實體的速度寫入實體組,因為某些寫入可能會被拒絕。只要警報作業和上傳的速度不超過每秒一次寫入的速度,結構就很穩固並保證了強一致性。

最終,每個測試模塊每秒寫入一次的上限是合理的,因為測試運行通常需要至少一分鐘,包括 VTS 框架的開銷;除非在 60 多個不同的主機上持續同時執行測試,否則不會出現寫入瓶頸。鑑於每個模塊都是測試計劃的一部分,通常需要超過一個小時,這變得更加不可能。如果主機同時運行測試,則可以輕鬆處理異常,從而導致對同一主機的短暫寫入突發(例如,通過捕獲寫入錯誤並重試)。

縮放注意事項

測試運行不一定需要將測試作為其父項(例如,它可以採用其他鍵並具有測試名稱、測試開始時間作為屬性);但是,這將以強一致性換取最終一致性。例如,警報作業可能看不到測試模塊內最近測試運行的相互一致的快照,這意味著全局狀態可能無法完全準確地描述測試運行序列的表示。這也可能會影響單個測試模塊中測試運行的顯示,這可能不一定是運行序列的一致快照。最終快照將是一致的,但不能保證最新數據是一致的。

測試用例

另一個潛在的瓶頸是包含許多測試用例的大型測試。兩個操作限制是實體組內每秒一個的寫入吞吐量最大值,以及 500 個實體的最大事務大小。

一種方法是指定一個將測試運行作為祖先的測試用例(類似於覆蓋數據、分析數據和設備信息的存儲方式):

圖 2 。測試用例源自測試運行(不推薦)。

雖然這種方法提供了原子性和一致性,但它對測試施加了很大的限制:如果一個事務被限制為 500 個實體,那麼一個測試可以有不超過 498 個測試用例(假設沒有覆蓋或分析數據)。如果測試超過了這個值,那麼單個事務就不能一次寫入所有測試用例結果,並且將測試用例分成單獨的事務可能會超過每秒一次迭代的最大實體組寫入吞吐量。由於此解決方案在不犧牲性能的情況下無法很好地擴展,因此不推薦。

但是,不是將測試用例結果存儲為測試運行的子項,而是可以獨立存儲測試用例並將它們的鍵提供給測試運行(測試運行包含其測試用例實體的標識符列表):

圖 3 。獨立存儲的測試用例(推薦)。

乍一看,這似乎破壞了強一致性保證。但是,如果客戶端有一個測試運行實體和一個測試用例標識符列表,它就不需要構造查詢;相反,它可以通過標識符直接獲取測試用例,始終保證一致。這種方法極大地緩解了對測試運行可能具有的測試用例數量的限制,同時獲得了強一致性,而不會威脅到實體組內的過度寫入。

數據訪問模式

VTS 儀表板使用以下數據訪問模式:

  • 用戶最愛。可以通過對具有特定 App Engine User 對像作為屬性的用戶收藏實體使用相等過濾器來查詢。
  • 測試上市。測試實體的簡單查詢。為了減少呈現主頁的帶寬,可以在通過和失敗計數上使用投影,以省略可能很長的失敗測試用例 ID 列表和警報作業使用的其他元數據。
  • 試運行。查詢測試運行實體需要對鍵(時間戳)進行排序,並可能對測試運行屬性(例如構建 ID、通過次數等)進行過濾。通過使用測試實體鍵執行祖先查詢,讀取是高度一致的。此時,可以使用存儲在測試運行屬性中的 ID 列表檢索所有測試用例結果;由於數據存儲區獲取操作的性質,這也保證了高度一致的結果。
  • 分析和覆蓋數據。查詢與測試關聯的分析或覆蓋數據可以在不檢索任何其他測試運行數據(例如其他分析/覆蓋數據、測試用例數據等)的情況下完成。使用測試測試和測試運行實體鍵的祖先查詢將檢索在測試運行期間記錄的所有分析點;通過還過濾分析點名稱或文件名,可以檢索單個分析或覆蓋實體。根據祖先查詢的性質,此操作是強一致的。

有關這些數據模式的 UI 和屏幕截圖的詳細信息,請參閱VTS Dashboard UI