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

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

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

เอนทิตี

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

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

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

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

รูปที่ 1 ทดสอบลำดับชั้นของเอนทิตี

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

สิทธิประโยชน์

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

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

ข้อจำกัด

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

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

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

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

กรอบการทดสอบ

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

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

รูปที่ 2 เฟรมเวิร์กการทดสอบจะมาจากการดำเนินการทดสอบ (ไม่แนะนำ)

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

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

รูปที่ 3 เก็บเคสทดสอบแยกต่างหาก (แนะนำ)

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

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

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

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

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