برای پشتیبانی از داشبورد یکپارچه‌سازی مداوم که مقیاس‌پذیر، با عملکرد بالا، و انعطاف‌پذیر باشد، باید زیرینه «داشبورد VTS» با درک قوی از عملکرد پایگاه داده به‌دقت طراحی شود. Google Cloud Datastore پایگاه داده NoSQL است که ضمانت‌های تراکنشی ACID و سازگاری نهایی و همچنین سازگاری قوی در گروه‌های نهاد ارائه می‌دهد. بااین‌حال، ساختار آن با SQLdatabases (و حتی Cloud Bigtable) بسیار متفاوت است؛ به‌جای جدول، ردیف، و سلول، انواع، نهادها، و دارایی‌ها وجود دارد.
بخش‌های زیر ساختار داده و الگوهای پُرسمان را برای ایجاد یک پس‌زمینه مؤثر برای سرویس وب «داشبورد VTS» شرح می‌دهند.
نهاد
نهادهای زیر خلاصه‌ها و منابع را از اجرای آزمایش VTS ذخیره می‌کنند:
- نهاد آزمایشی. فراداده‌های مربوط به اجرای آزمایشی یک آزمون خاص را ذخیره می‌کند. کلید آن نام آزمایش است و دارایی‌های آن شامل تعداد خرابی، تعداد قبولی، و فهرست خرابی‌های مورد آزمایش از زمانی است که کارهای هشدار آن را به‌روزرسانی می‌کنند.
- Test Run Entity (نهاد اجرای آزمایشی). حاوی فراداده‌های حاصل از اجرای آزمایشی خاص است. باید مُهر زمان شروع و پایان آزمایش، شناسه ساخت آزمایش، تعداد موارد آزمایش موفق و ناموفق، نوع اجرا (مثلاً پیش‌از ارسال، پس‌از ارسال، یا محلی)، فهرستی از پیوندهای گزارش، نام ماشین میزبان، و تعداد خلاصه پوشش را ذخیره کند.
- نهاد اطلاعات دستگاه. شامل جزئیاتی درباره دستگاه‌های استفاده‌شده درطول اجرای آزمایشی است. این اطلاعات شامل شناسه ساخت دستگاه، نام محصول، هدف ساخت، شاخه، و اطلاعات ABI است. این مورد به‌صورت جداگانه از نهاد اجرای آزمایشی ذخیره می‌شود تا از اجرای آزمایشی چنددستگاهی به‌صورت یک به چند پشتیبانی کند.
- Profiling Point Run Entity (نهاد اجرای نقطه نمایه‌سازی). داده‌های جمع‌آوری‌شده را برای یک نقطه نمایه‌سازی خاص در یک اجرای آزمایشی خلاصه می‌کند. این فایل برچسب‌های محور، نام نقطه نمایه‌سازی، مقادیر، نوع، و حالت رگرسیون داده‌های نمایه‌سازی را توصیف می‌کند.
- نهاد تحت پوشش. داده‌های پوشش جمع‌آوری‌شده برای یک فایل را شرح می‌دهد. این فایل حاوی اطلاعات پروژه Git، مسیر فایل، و فهرست تعداد پوشش‌ها در هر خط از فایل منبع است.
- نهاد اجرای چارچوب تست. نتیجه یک مورد آزمایشی خاص از اجرای آزمایشی را شرح می‌دهد، ازجمله نام مورد آزمایشی و نتیجه آن.
- نهاد موارد دلخواه کاربر. هر اشتراک کاربر می‌تواند در نهادی که حاوی ارجاع به آزمایش و شناسه کاربر تولیدشده از سرویس کاربر App Engine است نشان داده شود. این امر امکان پُرسمان دوطرفه کارآمد را فراهم می‌کند (یعنی برای همه کاربرانی که در آزمایشی مشترک شده‌اند و برای همه آزمایش‌هایی که کاربری به آن‌ها علاقه نشان داده است).
گروه‌بندی نهاد
هر پیمانه آزمایشی نشان‌دهنده ریشه یک گروه نهاد است. نهادهای اجرای آزمایشی هم فرزندان این گروه و هم والدین نهادهای دستگاه، نهادهای نقطه نمایه‌سازی، و نهادهای پوشش مربوط به آزمون و اجرای آزمایشی اجدادی مربوطه هستند.
نکته کلیدی: هنگام طراحی روابط نسبی، باید بین نیاز به ارائه سازوکارهای پُرسمان مؤثر و یکپارچه و محدودیت‌های اعمال‌شده توسط پایگاه داده تعادل برقرار کنید.
مزايا
الزام سازگاری تضمین می‌کند که عملیات‌های آینده تا زمانی که تراکنش انجام نشود، تأثیرات آن را نخواهند دید و تراکنش‌های گذشته برای عملیات‌های فعلی قابل‌مشاهده هستند. در Cloud Datastore، گروه‌بندی موجودیت‌ها جزایری از سازگاری قوی خواندن و نوشتن در گروه ایجاد می‌کند که در این مورد، همه اجراهای آزمایشی و داده‌های مربوط به یک ماژول آزمایشی است. این کار مزایای زیر را به‌همراه دارد:
- خواندن و به‌روزرسانی وضعیت واحد آزمایشی توسط کارهای هشدار را می‌توان به‌عنوان اتمی درنظر گرفت
- نمای ثابت تضمینی از نتایج مورد آزمون در واحدهای آزمون
- پرسش سریع‌تر در درخت‌های تبار
محدودیت‌ها
نوشتن در گروه نهاد با سرعتی بیشتر از یک نهاد در ثانیه توصیه نمی‌شود زیرا ممکن است برخی‌از نوشتن‌ها رد شوند. تا زمانی که کارهای هشدار و بارگذاری با سرعتی بیشتر از یک نوشتن در ثانیه انجام نشود، ساختار مستحکم است و سازگاری قوی را تضمین می‌کند.
درنهایت، سقف یک نوشتن در هر واحد آزمایشی در هر ثانیه منطقی است زیرا اجرای آزمایشی معمولاً حداقل یک دقیقه طول می‌کشد، ازجمله سربار چارچوب VTS؛ مگر اینکه آزمایشی به‌طور مداوم به‌طور هم‌زمان در بیش‌از ۶۰ میزبان مختلف اجرا شود، در این‌صورت نمی‌تواند گلوگاه نوشتن وجود داشته باشد. با توجه به اینکه هر واحد بخشی از یک طرح آزمایشی است که اغلب بیشتر از یک ساعت طول می‌کشد، این امر حتی بعیدتر می‌شود. اگر میزبان‌ها آزمایش‌ها را به‌طور هم‌زمان اجرا کنند، ناهنجاری‌ها به‌راحتی قابل‌مدیریت هستند، زیرا این کار باعث ایجاد انفجارهای کوتاه نوشتاری در میزبان‌های یکسان می‌شود (برای مثال، با شناسایی خطاهای نوشتاری و تلاش مجدد).
ملاحظات مقیاس‌بندی
اجرای آزمایشی لزوماً نباید آزمایش را به‌عنوان والد خود داشته باشد (مثلاً می‌تواند کلید دیگری را بگیرد و نام آزمایش و زمان شروع آزمایش را به‌عنوان ویژگی داشته باشد)؛ بااین‌حال، این کار سازگاری قوی را با سازگاری نهایی مبادله می‌کند. برای مثال، کار هشدار ممکن است نمای لحظه‌ای سازگاری از جدیدترین اجراهای آزمایشی در یک واحد آزمایشی نبیند، که به این معنی است که وضعیت کلی ممکن است نمایانگر توالی کاملاً دقیقی از اجراهای آزمایشی نباشد. این امر ممکن است بر نمایش اجراهای آزمایشی در یک واحد آزمایشی نیز تأثیر بگذارد، که ممکن است لزوماً یک نمای ثابت از توالی اجرا نباشد. درنهایت، نماگرفت سازگار خواهد بود، اما هیچ تضمینی وجود ندارد که جدیدترین داده‌ها سازگار باشند.
چارچوب‌های تست
یکی دیگر از گلوگاه‌های احتمالی، آزمایش‌های بزرگ با چارچوب‌های تست متعدد است. دو محدودیت عملیاتی عبارتند از حداکثر توان عملیاتی نوشتن در یک گروه نهاد به‌میزان یک مورد در ثانیه، به‌همراه حداکثر اندازه تراکنش ۵۰۰ نهاد.
یکی از رویکردها این است که مورد آزمایشی را مشخص کنید که اجرای آزمایشی به‌عنوان جد دارد (مشابه با نحوه ذخیره داده‌های پوشش، داده‌های نمایه‌بندی، و اطلاعات دستگاه):
اگرچه این رویکرد اتمی بودن و سازگاری را ارائه می‌دهد، اما محدودیت‌های شدیدی بر آزمایش‌ها تحمیل می‌کند: اگر تراکنشی به ۵۰۰ نهاد محدود شود، در این صورت آزمایش نمی‌تواند بیش‌از ۴۹۸ مورد آزمایشی داشته باشد (با فرض اینکه داده‌های پوشش یا نمایه‌سازی وجود نداشته باشد). اگر آزمایشی از این مقدار فراتر رود، یک تراکنش نمی‌تواند همه نتایج مورد آزمون را به‌طور هم‌زمان بنویسد، و تقسیم موارد آزمون به تراکنش‌های جداگانه می‌تواند از حداکثر توان عملیاتی نوشتاری گروه نهاد یک تکرار در ثانیه فراتر رود. ازآنجایی‌که این راه‌حل بدون فدا کردن عملکرد به‌خوبی مقیاس‌بندی نمی‌شود، توصیه نمی‌شود.
بااین‌حال، به‌جای ذخیره نتایج مورد آزمون به‌عنوان فرزندان اجرای آزمون، موردهای آزمون می‌توانند به‌طور مستقل ذخیره شوند و کلیدهای آن‌ها به اجرای آزمون ارائه شود (اجرای آزمون حاوی فهرستی از شناسه‌های نهادهای موردهای آزمون است):
در نگاه اول، ممکن است این امر نقض ضمانت سازگاری قوی به‌نظر برسد. بااین‌حال، اگر مشتری نهاد اجرای آزمایشی و فهرست شناسه‌های مورد آزمایشی داشته باشد، نیازی به ساختن پُرسمان ندارد؛ درعوض می‌تواند مستقیماً موارد آزمایشی را براساس شناسه‌هایشان دریافت کند که همیشه سازگاری آن تضمین‌شده است. این رویکرد محدودیت تعداد موارد آزمایشی را که یک اجرای آزمایشی می‌تواند داشته باشد تا حد زیادی کاهش می‌دهد و درعین‌حال بدون تهدید نوشتن بیش‌ازحد در یک گروه نهاد، سازگاری قوی‌ای به‌دست می‌آورد.
الگوهای دسترسی به داده‌ها
«داشبورد VTS» از الگوهای دسترسی به داده‌های زیر استفاده می‌کند:
- موارد دلخواه کاربر. می‌تواند بااستفاده از فیلتر برابری در موجودیت‌های موارد دلخواه کاربر که شیء خاص «کاربر App Engine» را به‌عنوان ویژگی دارند، پُرسمان شود.
- فهرستگان آزمایشی. پُرسمان ساده نهادهای آزمایشی. برای کاهش پهنای باند برای پرداز کردن صفحه اصلی، می‌توان از پیش‌بینی در تعداد موارد موفق و ناموفق استفاده کرد تا فهرست بالقوه طولانی شناسه‌های مورد آزمون ناموفق و دیگر فراداده‌های مورد استفاده در کارهای هشداردهنده حذف شود.
- اجراهای آزمایشی. پرسش زدن برای نهادهای اجرای آزمایشی نیازمند مرتب‌سازی براساس کلید (مهر زمان) و فیلتر کردن احتمالی براساس دارایی‌های اجرای آزمایشی مثل شناسه ساخت، تعداد موفقیت‌ها، و غیره است. با اجرای پُرسمان جد با کلید نهاد آزمایشی، خواندن به‌شدت سازگار است. در این مرحله، همه نتایج چارچوب تست را می‌توان بااستفاده از فهرست شناسه‌های ذخیره‌شده در ویژگی اجرای تست بازیابی کرد؛ همچنین تضمین می‌شود که این نتیجه به‌دلیل ماهیت عملیات دریافت پایگاه داده، کاملاً سازگار باشد.
- داده‌های نمایه‌سازی و پوشش. پرسش برای داده‌های نمایه‌سازی یا پوشش مرتبط با یک آزمایش می‌تواند بدون بازیابی هرگونه داده اجرای آزمایش دیگر (مثل داده‌های نمایه‌سازی/پوشش دیگر، داده‌های مورد آزمایش، و غیره) انجام شود. پُرسمان جد بااستفاده از کلیدهای نهاد «آزمایش آزمایشی» و «اجرای آزمایشی» همه نقاط نمایه‌سازی ضبط‌شده درطول اجرای آزمایشی را بازیابی می‌کند؛ با فیلتر کردن براساس نام نقطه نمایه‌سازی یا نام فایل، می‌توان یک نهاد نمایه‌سازی یا پوشش را بازیابی کرد. به‌دلیل ماهیت پُرسمان‌های جد، این عملیات به‌شدت سازگار است.
برای جزئیات مربوط به واسط کاربر و نماگرفت‌های این الگوهای داده در عمل، به واسط کاربر داشبورد VTS مراجعه کنید.