از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
پایگاه داده داشبورد VTS
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
برای پشتیبانی از داشبورد یکپارچه‌سازی پیوسته که مقیاس‌پذیر، کارآمد و انعطاف‌پذیر است، باطن داشبورد VTS باید با دقت و با درک قوی از عملکرد پایگاه داده طراحی شود. Google Cloud Datastore یک پایگاه داده NoSQL است که ضمانت‌های ACID تراکنشی و ثبات نهایی و همچنین ثبات قوی در گروه‌های موجود را ارائه می‌دهد. با این حال، ساختار بسیار متفاوت از SQLdatabases (و حتی Cloud Bigtable) است. به جای جداول، ردیف ها و سلول ها انواع، موجودیت ها و ویژگی ها وجود دارد.
بخش های زیر ساختار داده و الگوهای پرس و جو را برای ایجاد یک Backend موثر برای وب سرویس VTS Dashboard تشریح می کند.
نهادها
موجودیت‌های زیر خلاصه‌ها و منابع را از اجرای آزمایشی VTS ذخیره می‌کنند:
- موجودیت آزمایشی ابرداده‌های مربوط به آزمایش‌های آزمایشی خاص را ذخیره می‌کند. کلید آن نام تست است و ویژگی‌های آن شامل تعداد شکست، تعداد قبولی، و لیست شکستگی‌های مورد آزمایش از زمانی که مشاغل هشدار آن را به‌روزرسانی می‌کنند، می‌شود.
- Test Run Entity حاوی متادیتا از اجرای یک آزمایش خاص است. باید مُهرهای زمان شروع و پایان آزمایش، شناسه ساخت آزمایشی، تعداد موارد تست موفق و ناموفق، نوع اجرا (مثلاً پیش ارسال، پس از ارسال، یا محلی)، فهرستی از پیوندهای گزارش، نام دستگاه میزبان، و تعداد خلاصه پوشش را ذخیره کند.
- موجودیت اطلاعات دستگاه حاوی جزئیات مربوط به دستگاه های مورد استفاده در طول اجرای آزمایشی است. این شامل شناسه ساخت دستگاه، نام محصول، هدف ساخت، شاخه و اطلاعات ABI است. این به طور جداگانه از موجودیت اجرای آزمایشی ذخیره می شود تا از اجرای آزمایشی چند دستگاهی به صورت یک به چند پشتیبانی کند.
- نمایه سازی نقطه اجرا موجودیت . داده‌های جمع‌آوری‌شده برای یک نقطه پروفایل خاص را در یک اجرای آزمایشی خلاصه می‌کند. برچسب‌های محور، نام نقطه پروفایل، مقادیر، نوع و حالت رگرسیون داده‌های پروفایل را توصیف می‌کند.
- نهاد پوشش . داده های پوشش جمع آوری شده برای یک فایل را شرح می دهد. این شامل اطلاعات پروژه Git، مسیر فایل، و فهرست تعداد پوشش در هر خط در فایل منبع است.
- Test Case Run Entity . نتیجه یک مورد آزمایشی خاص را از یک آزمایش آزمایشی، از جمله نام مورد آزمایشی و نتیجه آن، توصیف می‌کند.
- موجودیت مورد علاقه کاربر هر اشتراک کاربر را می توان در یک موجودیت حاوی ارجاع به آزمایش و شناسه کاربری ایجاد شده از سرویس کاربر App Engine نشان داد. این امکان پرس و جوی دو جهته کارآمد را فراهم می کند (یعنی برای همه کاربرانی که در یک آزمایش مشترک هستند و برای همه آزمایش های مورد علاقه کاربر).
گروه بندی موجودیت
هر ماژول تست ریشه یک گروه موجودیت را نشان می دهد. نهادهای اجرای آزمایشی هم فرزندان این گروه و هم والدین برای نهادهای دستگاه، نهادهای نقطه نمایه، و نهادهای پوشش مربوط به اجداد آزمایشی و آزمایشی مربوطه هستند.
شکل 1 . نسب موجودیت را آزمایش کنید. نکته کلیدی: هنگام طراحی روابط اجدادی، باید بین نیاز به ارائه مکانیسم‌های پرس‌وجو مؤثر و سازگار در برابر محدودیت‌های اعمال‌شده توسط پایگاه داده تعادل برقرار کنید.
مزایا
الزام سازگاری تضمین می‌کند که عملیات‌های آتی اثرات یک تراکنش را تا زمانی که انجام نشود، نخواهند دید و تراکنش‌های گذشته برای عملیات فعلی قابل مشاهده است. در Cloud Datastore، گروه‌بندی موجودیت، جزیره‌هایی از سازگاری خواندن و نوشتن قوی در گروه ایجاد می‌کند، که در این مورد، همه آزمایش‌ها و داده‌های مربوط به یک ماژول آزمایشی است. این مزایای زیر را ارائه می دهد:
- خواندن و به روز رسانی برای آزمایش وضعیت ماژول توسط مشاغل هشدار را می توان به عنوان اتمی در نظر گرفت
- مشاهده منسجم تضمین شده از نتایج مورد آزمایش در ماژول های آزمون
- پرس و جو سریعتر در درختان اجدادی
محدودیت ها
نوشتن برای یک گروه موجودیت با نرخی سریعتر از یک موجودیت در ثانیه توصیه نمی شود زیرا ممکن است برخی از نوشته ها رد شوند. تا زمانی که کارهای هشدار و آپلود با سرعتی بیشتر از یک نوشتن در ثانیه اتفاق نیفتد، ساختار محکم است و ثبات قوی را تضمین می کند.
در نهایت، سقف یک نوشتن در هر ماژول تست در ثانیه معقول است زیرا اجرای آزمایشی معمولا حداقل یک دقیقه از جمله سربار چارچوب VTS طول می کشد. مگر اینکه یک آزمایش به طور همزمان روی بیش از 60 میزبان مختلف اجرا شود، نمی توان گلوگاه نوشتن وجود داشت. این امر با توجه به اینکه هر ماژول بخشی از یک برنامه آزمایشی است که اغلب بیش از یک ساعت طول می کشد، بعید تر می شود. اگر میزبان‌ها آزمایش‌ها را همزمان اجرا کنند، ناهنجاری‌ها را می‌توان به راحتی کنترل کرد، که باعث می‌شود دوره‌های کوتاهی از نوشتن برای همان میزبان‌ها ایجاد شود (مثلاً با گرفتن خطاهای نوشتن و تلاش مجدد).
ملاحظات مقیاس بندی
یک اجرای آزمایشی لزوماً نیازی به داشتن آزمایش به عنوان والد ندارد (مثلاً می تواند کلید دیگری داشته باشد و نام آزمایش، زمان شروع آزمایش را به عنوان ویژگی داشته باشد). با این حال، این یک ثبات قوی را با ثبات نهایی مبادله خواهد کرد. به عنوان مثال، کار هشدار ممکن است یک عکس فوری متقابل از آخرین آزمایش‌های آزمایشی در یک ماژول آزمایشی مشاهده نکند، به این معنی که وضعیت جهانی ممکن است نمایشی کاملاً دقیق از دنباله اجرای آزمایشی را نشان ندهد. این همچنین ممکن است بر نمایش اجراهای آزمایشی در یک ماژول آزمایشی تأثیر بگذارد، که ممکن است لزوماً یک عکس فوری ثابت از دنباله اجرا نباشد. در نهایت عکس فوری ثابت خواهد بود، اما هیچ تضمینی وجود ندارد که جدیدترین داده ها باشد.
موارد تست
یکی دیگر از گلوگاه های بالقوه آزمایش های بزرگ با موارد آزمایشی زیاد است. دو محدودیت عملیاتی عبارتند از حداکثر توان نوشتن در یک گروه موجودیت یک در ثانیه، همراه با حداکثر اندازه تراکنش 500 موجودیت.
یک رویکرد می تواند مشخص کردن یک مورد آزمایشی باشد که دارای یک آزمایش آزمایشی به عنوان یک اجداد باشد (مشابه نحوه ذخیره داده های پوشش، داده های پروفایل و اطلاعات دستگاه):
شکل 2 . موارد تست از اجرای آزمایشی نزول می کنند (توصیه نمی شود). در حالی که این رویکرد اتمی و سازگاری را ارائه می‌کند، محدودیت‌های شدیدی را بر آزمایش‌ها تحمیل می‌کند: اگر یک تراکنش به 500 موجودیت محدود شود، آن‌وقت یک آزمایش نمی‌تواند بیش از 498 مورد آزمایشی داشته باشد (با فرض اینکه داده‌های پوشش یا پروفایل وجود نداشته باشد). اگر آزمایشی بیش از این باشد، آنگاه یک تراکنش نمی‌تواند همه نتایج آزمایشی را به‌طور همزمان بنویسد، و تقسیم موارد آزمایشی به تراکنش‌های جداگانه می‌تواند از حداکثر توان نوشتن گروه موجودیت یک تکرار در ثانیه بیشتر شود. از آنجایی که این راه حل بدون کاهش عملکرد به خوبی مقیاس نخواهد شد، توصیه نمی شود.
با این حال، به‌جای ذخیره‌سازی نتایج مورد آزمایشی به‌عنوان فرزندان آزمایش، موارد آزمایشی را می‌توان به‌طور مستقل ذخیره کرد و کلیدهای آنها را در اجرای آزمایشی ارائه کرد (یک اجرای آزمایشی حاوی فهرستی از شناسه‌های موجودیت‌های مورد آزمایشی است):
شکل 3 . موارد تست به طور مستقل ذخیره شده است (توصیه می شود). در نگاه اول، ممکن است به نظر برسد که این تضمین قوام قوی را زیر پا می گذارد. با این حال، اگر مشتری یک موجودیت اجرای آزمایشی و لیستی از شناسه‌های مورد آزمایشی داشته باشد، نیازی به ساخت پرس و جو ندارد. در عوض می‌تواند مستقیماً موارد آزمایشی را با شناسه‌های آنها دریافت کند، که همیشه ثابت است. این رویکرد محدودیت تعداد موارد آزمایشی را که ممکن است یک اجرای آزمایشی ممکن است داشته باشد، کاهش می دهد، در حالی که ثبات قوی را بدون تهدید نوشتن بیش از حد در یک گروه موجودیت به دست می آورد.
الگوهای دسترسی به داده ها
داشبورد VTS از الگوهای دسترسی به داده های زیر استفاده می کند:
- موارد دلخواه کاربر می‌توان با استفاده از فیلتر برابری در موجودیت‌های مورد علاقه کاربر که شیء کاربر App Engine خاص را به عنوان ویژگی دارند، درخواست کرد.
- لیست تست . پرس و جوی ساده از موجودیت های آزمایشی. برای کاهش پهنای باند برای نمایش صفحه اصلی، می‌توان از یک پیش‌نمایش در شمارش‌های عبوری و ناموفق استفاده کرد تا فهرست طولانی بالقوه شناسه‌های مورد آزمایشی ناموفق و سایر ابرداده‌های مورد استفاده توسط مشاغل هشدار حذف شود.
- اجراهای آزمایشی پرس‌وجو برای موجودیت‌های اجرای آزمایشی به مرتب‌سازی کلید (مهر زمانی) و فیلتر کردن احتمالی ویژگی‌های اجرای آزمایشی مانند شناسه ساخت، تعداد پاس‌ها و غیره نیاز دارد. با انجام یک پرس‌وجوی اجدادی با یک کلید موجودیت آزمایشی، خواندن کاملاً سازگار است. در این مرحله، تمام نتایج تست موردی را می توان با استفاده از لیست شناسه های ذخیره شده در ویژگی اجرای آزمایشی بازیابی کرد. این نیز تضمین شده است که به دلیل ماهیت عملیات دریافت دیتا استور، یک نتیجه کاملاً ثابت است.
- مشخصات و داده های پوشش . پرس و جو برای داده های نمایه یا پوشش مرتبط با یک آزمون می تواند بدون بازیابی سایر داده های اجرای آزمایشی (مانند سایر داده های نمایه/پوشش، داده های مورد آزمایش و غیره) انجام شود. یک جستجوی اجدادی با استفاده از کلیدهای موجودیت آزمایشی و اجرای آزمایشی، تمام نقاط پروفایل ثبت شده در طول اجرای آزمایشی را بازیابی می کند. با فیلتر کردن نام نقطه نمایه یا نام فایل، می توان یک نمایه یا موجودیت پوشش را بازیابی کرد. با توجه به ماهیت پرس و جوهای اجدادی، این عملیات به شدت سازگار است.
برای جزئیات بیشتر در مورد رابط کاربری و تصاویری از این الگوهای داده در حال عمل، به رابط کاربری داشبورد VTS مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","easyToUnderstand","thumb-up"],["مشکلم را برطرف کرد","solvedMyProblem","thumb-up"],["غیره","otherUp","thumb-up"]],[["اطلاعاتی که نیاز دارم وجود ندارد","missingTheInformationINeed","thumb-down"],["بیشازحد پیچیده/ مراحل بسیار زیاد","tooComplicatedTooManySteps","thumb-down"],["قدیمی","outOfDate","thumb-down"],["مشکل ترجمه","translationIssue","thumb-down"],["مشکل کد / نمونهها","samplesCodeIssue","thumb-down"],["غیره","otherDown","thumb-down"]],["تاریخ آخرین به‌روزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# VTS Dashboard database\n\nTo support a continuous integration dashboard that is scalable, performant, and\nflexible, the VTS Dashboard backend must be carefully designed with a strong\nunderstanding of database functionality.\n[Google Cloud\nDatastore](https://cloud.google.com/datastore/docs/) is a NoSQL database that offers transactional ACID guarantees and\neventual consistency as well as strong consistency within entity groups.\nHowever, the structure is very different than SQLdatabases (and even Cloud\nBigtable); instead of tables, rows, and cells there are kinds, entities, and\nproperties.\n\n\nThe following sections outline the data structure and querying patterns for\ncreating an effective backend for the VTS Dashboard web service.\n\nEntities\n--------\n\n\nThe following entities store summaries and resources from VTS test runs:\n\n- **Test Entity**. Stores metadata about test runs of a particular test. Its key is the test name and its properties include the failure count, passing count, and list of test case breakages from when the alert jobs update it.\n- **Test Run Entity**. Contains metadata from runs of a particular test. It must store the test start and end timestamps, the test build ID, the number of passing and failing test cases, the type of run (e.g. pre-submit, post-submit, or local), a list of log links, the host machine name, and coverage summary counts.\n- **Device Information Entity**. Contains details about the devices used during the test run. It includes the device build ID, product name, build target, branch, and ABI information. This is stored separately from the test run entity to support multi-device test runs in a one-to-many fashion.\n- **Profiling Point Run Entity**. Summarizes the data gathered for a particular profiling point within a test run. It describes the axis labels, profiling point name, values, type, and regression mode of the profiling data.\n- **Coverage Entity**. Describes the coverage data gathered for one file. It contains the Git project information, file path, and the list of coverage counts per line in the source file.\n- **Test Case Run Entity**. Describes the outcome of a particular test case from a test run, including the test case name and its result.\n- **User Favorites Entity**. Each user subscription can be represented in an entity containing a reference to the test and the user ID generated from the App Engine user service. This allows for efficient bi-directional querying (i.e. for all users subscribed to a test and for all tests favorited by a user).\n\nEntity grouping\n---------------\n\n\nEach test module represents the root of an entity group. Test run entities\nare both children of this group and parents for device entities, profiling point\nentities, and coverage entities relevant to the respective test and test run\nancestor.\n**Figure 1**. Test entity ancestry.\n\n**Key Point:** When designing ancestry\nrelationships, you must balance the need to provide effective and consistent\nquerying mechanisms against the limitations enforced by the database.\n\n### Benefits\n\n\nThe consistency requirement ensures that future operations will not see the\neffects of a transaction until it commits, and that transactions in the past are\nvisible to present operations. In Cloud Datastore, entity grouping creates\nislands of strong read and write consistency within the group, which in this\ncase is all of test runs and data related to a test module. This offers the\nfollowing benefits:\n\n- Reads and updates to test module state by alert jobs can be treated as atomic\n- Guaranteed consistent view of test case results within test modules\n- Faster querying within ancestry trees\n\n### Limitations\n\n\nWriting to an entity group at a rate faster than one entity per second is not\nadvised as some writes may be rejected. As long as the alert jobs and the\nuploading does not happen at a rate faster than one write per second, the\nstructure is solid and guarantees strong consistency.\n\n\nUltimately, the cap of one write per test module per second is reasonable because\ntest runs usually take at least one minute including the overhead of the VTS\nframework; unless a test is consistently being executed simultaneously on more\nthan 60 different hosts, there cannot be a write bottleneck. This becomes even\nmore unlikely given that each module is part of a test plan which often takes\nlonger than one hour. Anomalies can easily be handled if hosts run the tests at\nthe same time, causing short bursts of writes to the same hosts (e.g. by\ncatching write errors and trying again).\n\n### Scaling considerations\n\n\nA test run doesn't necessarily need to have the test as its parent (e.g. it\ncould take some other key and have test name, test start time as properties);\nhowever, this will exchange strong consistency for eventual consistency. For\ninstance, the alert job may not see a mutually consistent snapshot of the most\nrecent test runs within a test module, which means that the global state may not\ndepict a fully accurate representation of sequence of test runs. This may also\nimpact the display of test runs within a single test module, which may not\nnecessarily be a consistent snapshot of the run sequence. Eventually the\nsnapshot will be consistent, but there are no guarantees the freshest data\nwill be.\n\nTest cases\n----------\n\n\nAnother potential bottleneck is large tests with many test cases. The two\noperative constraints are the write throughput maximum within of an entity group\nof one per second, along with a maximum transaction size of 500 entities.\n\n\nOne approach would be to specify a test case that has a test run as an ancestor\n(similar to how coverage data, profiling data, and device information\nare stored):\n**Figure 2**. Test Cases descend from Test Runs (NOT RECOMMENDED).\n\nWhile this approach offers atomicity and consistency, it imposes strong\nlimitations on tests: If a transaction is limited to 500 entities, then a test\ncan have no more than 498 test cases (assuming no coverage or profiling data).\nIf a test were to exceed this, then a single transaction could not write all of\nthe test case results at once, and dividing the test cases into separate\ntransactions could exceed the maximum entity group write throughput of one\niteration per second. As this solution will not scale well without sacrificing\nperformance, it is not recommended.\n\n\nHowever, instead of storing the test case results as children of the test run,\nthe test cases can be stored independently and their keys provided to the test\nrun (a test run contains a list of identifiers to its test cases entities):\n**Figure 3**. Test Cases stored independently (RECOMMENDED).\n\n\nAt first glance, this may appear to break the strong consistency guarantee.\nHowever, if the client has a test run entity and a list of test case\nidentifiers, it doesn't need to construct a query; it can instead directly get\nthe test cases by their identifiers, which is always guaranteed to be\nconsistent. This approach vastly alleviates the constraint on the number of test\ncases a test run may have while gaining strong consistency without threatening\nexcessive writing within an entity group.\n\nData access patterns\n--------------------\n\n\nThe VTS Dashboard uses the following data access patterns:\n\n- **User favorites**. Can be queried for by using an equality filter on user favorites entities having the particular App Engine User object as a property.\n- **Test listing**. Simple query of test entities. To reduce bandwidth to render the home page, a projection can be used on passing and failing counts so as to omit the potentially long listing of failed test case IDs and other metadata used by the alerting jobs.\n- **Test runs**. Querying for test run entities requires a sort on the key (timestamp) and possible filtering on the test run properties such as build ID, passing count, etc. By performing an ancestor query with a test entity key, the read is strongly consistent. At this point, all of the test case results can be retrieved using the list of IDs stored in a test run property; this also is guaranteed to be a strongly consistent outcome by the nature of datastore get operations.\n- **Profiling and coverage data**. Querying for profiling or coverage data associated with a test can be done without also retrieving any other test run data (such as other profiling/coverage data, test case data, etc.). An ancestor query using the test test and test run entity keys will retrieve all profiling points recorded during the test run; by also filtering on the profiling point name or filename, a single profiling or coverage entity can be retrieved. By the nature of ancestor queries, this operation is strongly consistent.\n\n\nFor details on the UI and screenshots of these data patterns in action, see\n[VTS Dashboard UI](/docs/core/tests/vts/ui)."]]
