Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

VTS儀表板數據庫

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

以下各節概述了為VTS儀表板Web服務創建有效後端的數據結構和查詢模式。

實體

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

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

實體分組

每個測試模塊代表一個實體組的根。試運行實體既是該組的子級,又是與各個測試和試運行祖先相關的設備實體,配置點實體和coverage實體的父代。

圖1 。測試實體的祖先。

關鍵點:設計血統關係時,必須在提供有效且一致的查詢機制的需求與數據庫所施加的限制之間取得平衡。

好處

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

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

局限性

建議不要以每秒超過一個實體的速率寫入實體組,因為某些寫入可能會被拒絕。只要警報作業和上載的發生速度不超過每秒一次寫入的速度,該結構便會牢固並保證強大的一致性。

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

縮放注意事項

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

測試用例

另一個潛在的瓶頸是具有許多測試用例的大型測試。這兩個操作約束是每秒1個實體組內的最大寫入吞吐量,以及500個實體的最大事務大小。

一種方法是指定一個測試用例作為祖先運行(類似於如何存儲coverage數據,配置文件數據和設備信息):

圖2 。測試用例來自“測試運行”(不推薦)。

儘管此方法提供了原子性和一致性,但它對測試施加了嚴格的限制:如果一個事務限於500個實體,則一個測試最多只能有498個測試用例(假設沒有覆蓋或分析數據)。如果測試超出此範圍,則單個事務無法一次寫入所有測試用例結果,並且將測試用例劃分為單獨的事務可能會超過每秒一次迭代的最大實體組寫入吞吐量。由於此解決方案在不犧牲性能的情況下無法很好地擴展,因此不建議使用。

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

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

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

數據訪問方式

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

  • 用戶收藏夾 。可以通過對具有特定App Engine用戶對像作為屬性的用戶收藏夾實體使用相等過濾器來查詢。
  • 測試清單 。簡單查詢測試實體。為了減少顯示主頁的帶寬,可以在通過和失敗計數上使用投影,以便省略潛在的冗長的失敗測試用例ID和警報作業使用的其他元數據列表。
  • 測試運行 。查詢測試運行實體需要對鍵(時間戳)進行排序,並可能對測試運行屬性(例如,構建ID,傳遞計數等)進行過濾。通過使用測試實體鍵執行祖先查詢,讀取將保持高度一致。此時,可以使用存儲在測試運行屬性中的ID列表來檢索所有測試用例結果。通過數據存儲區get操作的性質,也可以保證這是非常一致的結果。
  • 分析和覆蓋數據 。可以查詢與測試關聯的配置文件或覆蓋率數據,而無需獲取任何其他測試運行數據(例如其他配置文件/覆蓋率數據,測試用例數據等)。使用測試測試和測試運行實體鍵的祖先查詢將檢索在測試運行期間記錄的所有性能分析點;通過還篩選配置文件名稱或文件名,可以檢索單個配置文件或coverage實體。根據祖先查詢的性質,此操作是高度一致的。

有關UI的詳細信息以及這些數據模式的屏幕截圖,請參閱VTS儀表板UI