為了支援可擴展、高效能且靈活的持續整合儀表板，必須在對資料庫功能有深入了解的情況下仔細設計 VTS 儀表板後端。 Google Cloud Datastore是一個 NoSQL 資料庫，提供交易 ACID 保證和最終一致性以及實體群組內的強一致性。然而，其結構與 SQL 資料庫（甚至 Cloud Bigtable）有很大不同；取代表格、行和儲存格的是類型、實體和屬性。
以下部分概述了為 VTS Dashboard Web 服務建立有效後端的資料結構和查詢模式。
實體
以下實體儲存 VTS 測試運行的摘要和資源：
- 測試實體。儲存有關特定測試的測試運行的元資料。它的鍵是測試名稱，其屬性包括失敗計數、通過計數以及警報作業更新時的測試案例損壞清單。
- 測試運行實體。包含特定測試運行的元資料。它必須儲存測試開始和結束時間戳記、測試建置 ID、通過和失敗測試案例的數量、運行類型（例如預先提交、後提交或本機）、日誌連結清單、主機機器名稱和覆蓋率摘要計數。
- 設備資訊實體。包含有關測試運行期間使用的設備的詳細資訊。它包括設備建置 ID、產品名稱、建置目標、分支和 ABI 資訊。它與測試運行實體分開存儲，以支援以一對多方式運行多設備測試。
- 分析點運行實體。總結測試運行中為特定分析點收集的數據。它描述了分析資料的軸標籤、分析點名稱、值、類型和迴歸模式。
- 覆蓋實體。描述為一個文件收集的覆蓋率資料。它包含 Git 項目資訊、檔案路徑以及來源檔案中每行的覆蓋計數清單。
- 測試用例運行實體。描述測試運行中特定測試案例的結果，包括測試案例名稱及其結果。
- 用戶收藏夾實體。每個使用者訂閱都可以用一個實體來表示，該實體包含對測試的引用以及從 App Engine 使用者服務產生的使用者 ID。這允許高效的雙向查詢（即針對訂閱測試的所有用戶以及用戶喜愛的所有測試）。
實體分組
每個測試模組代表一個實體組的根。測試運行實體既是該組的子級，也是設備實體、分析點實體以及與相應測試和測試運行祖先相關的覆蓋實體的父級。
關鍵點：設計祖先關係時，必須在提供有效且一致的查詢機制的需求與資料庫強制執行的限制之間取得平衡。
好處
一致性要求確保未來的操作在事務提交之前不會看到該事務的影響，並且過去的事務對當前的操作是可見的。在 Cloud Datastore 中，實體分組會在群組內建立具有強讀寫一致性的孤島，在本例中是與測試模組相關的所有測試運行和資料。這具有以下優點：
- 透過警報作業讀取和更新測試模組狀態可以視為原子操作
- 確保測試模組內測試案例結果的一致性
- 在祖先樹中更快查詢
限制
不建議以高於每秒一個實體的速率寫入實體群組，因為某些寫入可能會被拒絕。只要警報作業和上傳的速度不超過每秒一次寫入，結構就是堅固的並保證強一致性。
最終，每個測試模組每秒一次寫入的上限是合理的，因為測試運行通常至少需要一分鐘，包括 VTS 框架的開銷；除非測試始終在 60 多個不同主機上同時執行，否則不會出現寫入瓶頸。鑑於每個模組都是測試計劃的一部分，而測試計劃通常需要超過一小時，因此這種情況變得更加不可能。如果主機同時執行測試，導致對相同主機進行短時間的寫入（例如，透過擷取寫入錯誤並重試），則可以輕鬆處理異常情況。
擴展考慮因素
測試運行不一定需要將測試作為其父級（例如，它可以採用其他一些鍵並具有測試名稱、測試開始時間作為屬性）；然而，這將以強一致性換取最終一致性。例如，警報作業可能看不到測試模組內最近測試運行的相互一致的快照，這意味著全局狀態可能無法描述測試運行序列的完全準確的表示。這也可能影響單一測試模組內測試運行的顯示，這可能不一定是運行序列的一致快照。最終快照將是一致的，但不能保證最新的數據將是一致的。
測試用例
另一個潛在的瓶頸是包含許多測試案例的大型測試。兩個操作約束是實體群組內每秒一個的最大寫入吞吐量，以及 500 個實體的最大交易大小。
一種方法是指定一個以測試運行作為祖先的測試案例（類似於覆蓋率數據、分析數據和設備資訊的儲存方式）：
雖然這種方法提供了原子性和一致性，但它對測試施加了很強的限制：如果交易僅限於 500 個實體，則測試不能超過 498 個測試案例（假設沒有覆蓋或分析資料）。如果測試超過此值，則單一交易無法一次寫入所有測試案例結果，並且將測試案例劃分為單獨的交易可能會超過每秒一次迭代的最大實體群組寫入吞吐量。由於此解決方案在不犧牲效能的情況下無法很好地擴展，因此不建議使用。
但是，不是將測試案例結果儲存為測試運行的子級，而是可以獨立儲存測試案例並將其密鑰提供給測試運行（測試運行包含其測試案例實體的標識符清單）：
乍一看，這似乎破壞了強一致性保證。但是，如果客戶端有一個測試運行實體和一個測試案例標識符列表，則不需要建構查詢；相反，它可以直接透過標識符獲取測試案例，這始終保證一致。這種方法極大地減輕了對測試運行可能具有的測試案例數量的限制，同時獲得了強一致性，而不會威脅到實體組內的過度寫入。
資料存取模式
VTS 儀表板使用以下資料存取模式：
- 用戶最愛。可以透過對具有特定 App Engine 使用者物件作為屬性的使用者收藏實體使用相等過濾器來進行查詢。
- 測試上市。測試實體的簡單查詢。為了減少渲染主頁的頻寬，可以對通過和失敗計數使用投影，以便省略可能很長的失敗測試案例 ID 清單以及警報作業使用的其他元資料。
- 試運行。查詢測試運行實體需要對鍵（時間戳）進行排序，並可能對測試運行屬性（例如建置 ID、傳遞計數等）進行過濾。透過使用測試實體鍵執行祖先查詢，讀取將具有強一致性。此時，可以使用測試運行屬性中儲存的 ID 清單來檢索所有測試案例結果；由於資料儲存獲取操作的性質，這也保證是高度一致的結果。
- 分析和覆蓋數據。可以在不檢索任何其他測試運行資料（例如其他分析/覆蓋資料、測試案例資料等）的情況下完成與測試相關聯的分析或覆蓋資料的查詢。使用 test test 和 test run 實體鍵的祖先查詢將檢索測試運行期間記錄的所有分析點；透過也對分析點名稱或檔案名稱進行過濾，可以檢索單一分析或覆寫實體。根據祖先查詢的性質，此操作是強一致的。
有關這些實際資料模式的 UI 和螢幕截圖的詳細信息，請參閱VTS 儀表板 UI 。