ฐานข้อมูลแดชบอร์ด VTS

เพื่อสนับสนุนแดชบอร์ดการรวมอย่างต่อเนื่องที่สามารถปรับขนาดได้ มีประสิทธิภาพ และยืดหยุ่น แบ็กเอนด์ VTS Dashboard จะต้องได้รับการออกแบบอย่างระมัดระวังโดยมีความเข้าใจอย่างแข็งแกร่งเกี่ยวกับฟังก์ชันการทำงานของฐานข้อมูล Google Cloud Datastore เป็นฐานข้อมูล NoSQL ที่ให้การรับประกัน ACID ของธุรกรรมและความสอดคล้องในที่สุด รวมถึงความสอดคล้องที่แข็งแกร่งภายในกลุ่มเอนทิตี อย่างไรก็ตาม โครงสร้างแตกต่างจากฐานข้อมูล SQL มาก (และแม้แต่ Cloud Bigtable) แทนที่จะเป็นตาราง แถว และเซลล์ กลับมีชนิด เอนทิตี และคุณสมบัติ

ส่วนต่อไปนี้จะสรุปโครงสร้างข้อมูลและรูปแบบการสืบค้นสำหรับการสร้างแบ็กเอนด์ที่มีประสิทธิภาพสำหรับบริการเว็บ VTS Dashboard

เอนทิตี

เอนทิตีต่อไปนี้จัดเก็บสรุปและทรัพยากรจากการรันการทดสอบ VTS:

• เอนทิตีทดสอบ จัดเก็บข้อมูลเมตาเกี่ยวกับการทดสอบรันของการทดสอบเฉพาะ สิ่งสำคัญคือชื่อการทดสอบและคุณสมบัติประกอบด้วยจำนวนความล้มเหลว จำนวนการส่งผ่าน และรายการการเสียหายของกรณีทดสอบเมื่องานแจ้งเตือนอัปเดต
• ทดสอบการทำงานเอนทิตี มีข้อมูลเมตาจากการรันการทดสอบเฉพาะ จะต้องจัดเก็บการประทับเวลาเริ่มต้นและสิ้นสุดการทดสอบ, ID บิลด์การทดสอบ, จำนวนกรณีทดสอบที่ผ่านและล้มเหลว, ประเภทการทดสอบ (เช่น ก่อนส่ง, หลังส่ง หรือในพื้นที่) รายการลิงก์บันทึก โฮสต์ ชื่อเครื่อง และจำนวนสรุปความครอบคลุม
• เอนทิตีข้อมูลอุปกรณ์ ประกอบด้วยรายละเอียดเกี่ยวกับอุปกรณ์ที่ใช้ระหว่างการทดสอบการทำงาน ประกอบด้วยรหัสบิวด์อุปกรณ์ ชื่อผลิตภัณฑ์ เป้าหมายบิวด์ สาขา และข้อมูล ABI ข้อมูลนี้จะถูกจัดเก็บแยกต่างหากจากเอนทิตีการดำเนินการทดสอบเพื่อรองรับการทดสอบหลายอุปกรณ์ในลักษณะแบบหนึ่งต่อกลุ่ม
• เอนทิตีการเรียกใช้จุดโปรไฟล์ สรุปข้อมูลที่รวบรวมสำหรับจุดโปรไฟล์เฉพาะภายในการทดสอบการทำงาน โดยจะอธิบายป้ายแกน ชื่อจุดโปรไฟล์ ค่า ประเภท และโหมดการถดถอยของข้อมูลโปรไฟล์
• นิติบุคคลความคุ้มครอง อธิบายข้อมูลความครอบคลุมที่รวบรวมไว้สำหรับไฟล์เดียว ประกอบด้วยข้อมูลโปรเจ็กต์ Git เส้นทางไฟล์ และรายการจำนวนความครอบคลุมต่อบรรทัดในไฟล์ต้นฉบับ
• เอนทิตีเรียกใช้กรณีทดสอบ อธิบายผลลัพธ์ของกรณีทดสอบเฉพาะจากการทดสอบ รวมถึงชื่อกรณีทดสอบและผลลัพธ์
• เอนทิตีรายการโปรดของผู้ใช้ การสมัครสมาชิกผู้ใช้แต่ละรายการสามารถแสดงในเอนทิตีที่มีการอ้างอิงถึงการทดสอบและ ID ผู้ใช้ที่สร้างจากบริการผู้ใช้ App Engine ซึ่งช่วยให้สามารถสืบค้นแบบสองทิศทางได้อย่างมีประสิทธิภาพ (เช่น สำหรับผู้ใช้ทั้งหมดที่สมัครรับการทดสอบและสำหรับการทดสอบทั้งหมดที่ผู้ใช้ชื่นชอบ)

การจัดกลุ่มเอนทิตี

แต่ละโมดูลทดสอบแสดงถึงรากของกลุ่มเอนทิตี เอนทิตีการทดสอบการทำงานเป็นทั้งรายการย่อยของกลุ่มนี้และรายการระดับบนสุดสำหรับเอนทิตีอุปกรณ์ เอนทิตีจุดโปรไฟล์ และเอนทิตีความครอบคลุมที่เกี่ยวข้องกับการทดสอบและรันการทดสอบที่เกี่ยวข้อง

รูปที่ 1 . ทดสอบเอนทิตีเอนทิตี

ประเด็นสำคัญ: เมื่อออกแบบความสัมพันธ์ทางบรรพบุรุษ คุณต้องสร้างสมดุลระหว่างความจำเป็นในการจัดหากลไกการสืบค้นที่มีประสิทธิภาพและสม่ำเสมอกับข้อจำกัดที่ฐานข้อมูลบังคับใช้

ประโยชน์

ข้อกำหนดด้านความสอดคล้องช่วยให้แน่ใจว่าการดำเนินงานในอนาคตจะไม่เห็นผลกระทบของธุรกรรมจนกว่าจะกระทำ และธุรกรรมในอดีตจะมองเห็นได้ในการดำเนินงานปัจจุบัน ใน Cloud Datastore การจัดกลุ่มเอนทิตีจะสร้างเกาะที่มีความสอดคล้องในการอ่านและเขียนที่ชัดเจนภายในกลุ่ม ซึ่งในกรณีนี้คือการดำเนินการทดสอบและข้อมูลทั้งหมดที่เกี่ยวข้องกับโมดูลทดสอบ สิ่งนี้ให้ประโยชน์ดังต่อไปนี้:

• การอ่านและการอัพเดตสถานะโมดูลทดสอบตามงานการแจ้งเตือนสามารถถือเป็นอะตอมมิกได้
• รับประกันผลการทดสอบกรณีทดสอบภายในโมดูลการทดสอบที่สอดคล้องกัน
• การสืบค้นภายในแผนผังบรรพบุรุษเร็วขึ้น

ข้อจำกัด

ไม่แนะนำให้เขียนถึงกลุ่มเอนทิตีในอัตราที่เร็วกว่าหนึ่งเอนทิตีต่อวินาที เนื่องจากการเขียนบางรายการอาจถูกปฏิเสธ ตราบใดที่งานแจ้งเตือนและการอัปโหลดไม่เกิดขึ้นในอัตราที่เร็วกว่าหนึ่งการเขียนต่อวินาที โครงสร้างจะมั่นคงและรับประกันความสม่ำเสมอที่แข็งแกร่ง

ท้ายที่สุดแล้ว ขีดจำกัดของการเขียนหนึ่งครั้งต่อโมดูลทดสอบต่อวินาทีนั้นสมเหตุสมผล เนื่องจากโดยปกติแล้วการทดสอบจะใช้เวลาอย่างน้อยหนึ่งนาที รวมทั้งโอเวอร์เฮดของเฟรมเวิร์ก VTS ด้วย เว้นแต่ว่าการทดสอบจะดำเนินการพร้อมกันบนโฮสต์ที่แตกต่างกันมากกว่า 60 แห่ง จะไม่มีปัญหาคอขวดในการเขียน สิ่งนี้ไม่น่าเป็นไปได้มากยิ่งขึ้นเนื่องจากแต่ละโมดูลเป็นส่วนหนึ่งของแผนการทดสอบซึ่งมักจะใช้เวลานานกว่าหนึ่งชั่วโมง ความผิดปกติสามารถจัดการได้อย่างง่ายดายหากโฮสต์ทำการทดสอบในเวลาเดียวกัน ทำให้เกิดการเขียนจำนวนมากไปยังโฮสต์เดียวกันในช่วงเวลาสั้นๆ (เช่น โดยการตรวจจับข้อผิดพลาดในการเขียนแล้วลองอีกครั้ง)

ข้อควรพิจารณาในการปรับขนาด

การทดสอบการทำงานไม่จำเป็นต้องมีการทดสอบเป็นพาเรนต์ (เช่น อาจใช้คีย์อื่นและมีชื่อการทดสอบ เวลาเริ่มต้นการทดสอบเป็นคุณสมบัติ) อย่างไรก็ตาม สิ่งนี้จะแลกเปลี่ยนความสม่ำเสมอที่แข็งแกร่งกับความสม่ำเสมอในที่สุด ตัวอย่างเช่น งานการแจ้งเตือนอาจไม่เห็นสแน็ปช็อตที่สอดคล้องกันของการทดสอบล่าสุดที่ทำงานภายในโมดูลการทดสอบ ซึ่งหมายความว่าสถานะโดยรวมอาจไม่แสดงถึงการแสดงลำดับของการทดสอบที่แม่นยำอย่างสมบูรณ์ นอกจากนี้ยังอาจส่งผลต่อการแสดงการทดสอบการทำงานภายในโมดูลการทดสอบเดียว ซึ่งอาจไม่จำเป็นต้องเป็นภาพรวมของลำดับการทดสอบที่สอดคล้องกัน ในที่สุดสแนปชอตจะสอดคล้องกัน แต่ไม่มีการรับประกันว่าข้อมูลที่ใหม่ที่สุดจะเป็นอย่างไร

กรณีทดสอบ

ปัญหาคอขวดที่อาจเกิดขึ้นอีกประการหนึ่งคือการทดสอบขนาดใหญ่ที่มีกรณีทดสอบจำนวนมาก ข้อจำกัดในการปฏิบัติงานสองประการคือปริมาณงานการเขียนสูงสุดภายในกลุ่มเอนทิตีหนึ่งรายการต่อวินาที พร้อมด้วยขนาดธุรกรรมสูงสุด 500 เอนทิตี

แนวทางหนึ่งคือระบุกรณีทดสอบที่มีการทดสอบรันเป็นบรรพบุรุษ (คล้ายกับวิธีจัดเก็บข้อมูลความครอบคลุม ข้อมูลโปรไฟล์ และข้อมูลอุปกรณ์):

รูปที่ 2 กรณีทดสอบสืบเชื้อสายมาจากการทดสอบการทำงาน (ไม่แนะนำ)

แม้ว่าแนวทางนี้จะนำเสนอความเป็นอะตอมมิกและความสม่ำเสมอ แต่ก็มีข้อจำกัดที่เข้มงวดในการทดสอบ: หากธุรกรรมถูกจำกัดไว้ที่ 500 เอนทิตี การทดสอบจะมีกรณีทดสอบได้ไม่เกิน 498 กรณี (สมมติว่าไม่มีข้อมูลครอบคลุมหรือข้อมูลโปรไฟล์) หากการทดสอบเกินกว่านี้ ธุรกรรมเดียวจะไม่สามารถเขียนผลลัพธ์กรณีทดสอบทั้งหมดในคราวเดียวได้ และการแบ่งกรณีทดสอบออกเป็นธุรกรรมที่แยกจากกันอาจเกินปริมาณการประมวลผลการเขียนกลุ่มเอนทิตีสูงสุดที่ทำซ้ำหนึ่งครั้งต่อวินาที เนื่องจากโซลูชันนี้ไม่สามารถปรับขนาดได้ดีโดยไม่ทำให้ประสิทธิภาพลดลง จึงไม่แนะนำ

อย่างไรก็ตาม แทนที่จะจัดเก็บผลลัพธ์ของกรณีการทดสอบเป็นลูกของการทดสอบ กรณีการทดสอบสามารถจัดเก็บได้อย่างอิสระและคีย์ของการทดสอบจะถูกจัดเตรียมไว้สำหรับการทดสอบ (การทดสอบการทำงานประกอบด้วยรายการตัวระบุสำหรับเอนทิตีของกรณีการทดสอบ):

รูปที่ 3 กรณีทดสอบจัดเก็บแยกกัน (แนะนำ)

เมื่อมองแวบแรก สิ่งนี้อาจดูเหมือนทำลายการรับประกันความสม่ำเสมอที่แข็งแกร่ง อย่างไรก็ตาม หากไคลเอนต์มีเอนทิตีการดำเนินการทดสอบและรายการตัวระบุกรณีทดสอบ ก็ไม่จำเป็นต้องสร้างแบบสอบถาม แต่สามารถรับกรณีทดสอบได้โดยตรงจากตัวระบุ ซึ่งรับประกันว่าจะสอดคล้องกันเสมอ วิธีการนี้ช่วยลดข้อจำกัดเกี่ยวกับจำนวนกรณีทดสอบที่การทดสอบดำเนินการอาจมีได้อย่างมาก ขณะเดียวกันก็ได้รับความสอดคล้องที่แข็งแกร่งโดยไม่คุกคามการเขียนที่มากเกินไปภายในกลุ่มเอนทิตี

รูปแบบการเข้าถึงข้อมูล

VTS Dashboard ใช้รูปแบบการเข้าถึงข้อมูลต่อไปนี้:

• รายการโปรดของผู้ใช้ สามารถสอบถามได้โดยใช้ตัวกรองความเท่าเทียมกันในเอนทิตีรายการโปรดของผู้ใช้ซึ่งมีออบเจ็กต์ผู้ใช้ App Engine เฉพาะเป็นคุณสมบัติ
• ทดสอบรายการ . แบบสอบถามง่าย ๆ ของเอนทิตีทดสอบ เพื่อลดแบนด์วิดท์ในการแสดงผลโฮมเพจ สามารถใช้การฉายภาพในการนับที่ผ่านและล้มเหลว เพื่อที่จะละเว้นรายการ ID กรณีทดสอบที่ล้มเหลวและข้อมูลเมตาอื่น ๆ ที่ใช้โดยงานแจ้งเตือนที่ยาว
• การทดสอบการทำงาน การสืบค้นเอนทิตีการดำเนินการทดสอบจำเป็นต้องมีการเรียงลำดับคีย์ (การประทับเวลา) และการกรองที่เป็นไปได้ในคุณสมบัติการทดสอบรัน เช่น รหัสบิลด์ การนับจำนวนที่ผ่าน ฯลฯ ด้วยการดำเนินการสืบค้นระดับบนด้วยคีย์เอนทิตีทดสอบ การอ่านจะสอดคล้องกันอย่างมาก ณ จุดนี้ ผลลัพธ์กรณีการทดสอบทั้งหมดสามารถดึงข้อมูลได้โดยใช้รายการรหัสที่จัดเก็บไว้ในคุณสมบัติการทดสอบการทำงาน นอกจากนี้ยังรับประกันว่าจะเป็นผลลัพธ์ที่สอดคล้องกันอย่างมากโดยธรรมชาติของการดำเนินการรับข้อมูล
• ข้อมูลโปรไฟล์และความครอบคลุม การสืบค้นข้อมูลโปรไฟล์หรือความครอบคลุมที่เกี่ยวข้องกับการทดสอบสามารถทำได้โดยไม่ต้องเรียกข้อมูลการทดสอบอื่นๆ ด้วย (เช่น ข้อมูลโปรไฟล์/ความครอบคลุมอื่นๆ ข้อมูลกรณีทดสอบ ฯลฯ) การสืบค้นระดับบนสุดโดยใช้คีย์เอนทิตีการทดสอบและการทดสอบการทำงานจะดึงข้อมูลจุดโปรไฟล์ทั้งหมดที่บันทึกไว้ระหว่างการทดสอบการทำงาน ด้วยการกรองชื่อจุดโปรไฟล์หรือชื่อไฟล์ ทำให้สามารถดึงข้อมูลเอนทิตีโปรไฟล์หรือความครอบคลุมเดียวได้ โดยธรรมชาติของการสืบค้นระดับบนสุด การดำเนินการนี้มีความสอดคล้องกันอย่างยิ่ง

สำหรับรายละเอียดเกี่ยวกับ UI และภาพหน้าจอของรูปแบบข้อมูลเหล่านี้ที่ใช้งานจริง โปรดดูที่ VTS Dashboard UI