اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release
بدلاً من aosp-main
لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
قاعدة بيانات لوحة بيانات مراقبة الأداء في الوقت الفعلي
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
لدعم لوحة بيانات الدمج المستمر التي يمكن توسيع نطاقها وتحسين أدائها
ومرونتها، يجب تصميم الخلفية في لوحة بيانات VTS بعناية مع فهم عميق
لوظائف قاعدة البيانات.
Google Cloud
Datastore هي قاعدة بيانات NoSQL تقدّم ضمانات ACID للمعاملات و
الاتساق النهائي بالإضافة إلى اتساق قوي داخل مجموعات الكيانات.
ومع ذلك، تختلف البنية كثيرًا عن قواعد بيانات SQL (وحتى عن قاعدة بيانات
Bigtable في السحابة الإلكترونية). فبدلاً من الجداول والصفوف والخلايا، تتضمّن البنية أنواعًا وكيانات
وخصائص.
توضّح الأقسام التالية بنية البيانات وأنماط طلب البيانات ل
إنشاء واجهة خلفية فعّالة لخدمة الويب VTS Dashboard.
عدد العناصر
تخزِّن الكيانات التالية الملخّصات والمراجع من عمليات تشغيل اختبار VTS:
- كيان الاختبار: تخزِّن البيانات الوصفية حول عمليات تنفيذ اختبار معيّن. مفتاحها هو اسم الاختبار وتشمل خصائصه عدد حالات الانهيار
وعدد حالات النجاح وقائمة حالات تعطُّل نموذج الاختبار منذ تعديلها من خلال مهام التنبيهات.
- كيان التشغيل التجريبي يحتوي على بيانات وصفية من عمليات تنفيذ
اختبار معيّن. يجب أن يخزن الطابع الزمني لبدء الاختبار وانتهائه، وملف تعريف الإصدار
للاختبار، وعدد حالات الاختبار التي نجحت والتي تعذّر إكمالها، ونوع التشغيل (مثل
التشغيل قبل الإرسال أو بعد الإرسال أو على الجهاز المحلي)، وقائمة بروابط السجلّات، واسم الجهاز المضيف،
وعدد ملخّصات التغطية.
- عنصر معلومات الجهاز يحتوي على تفاصيل حول
الأجهزة المستخدَمة أثناء إجراء الاختبار. ويشمل معرّف إصدار الجهاز واسم المنتج
ومعلومات عن إصدار الإصدار والفرع وABI. ويتم تخزين هذا العنصر بشكل منفصل عن
عنصر عملية الاختبار لتتمكّن من إجراء عمليات اختبار على أجهزة متعددة بطريقة من واحد إلى عدة أجهزة.
- Profiling Point Run Entity (كيان نقطة بدء التحليل) يلخِّص هذا التقرير البيانات التي تم جمعها
لنقطة ملف تعريف معيّنة خلال عملية إجراء اختبار. ويوضّح تصنيفات محور
البيانات واسم نقطة التحليل والقيم والنوع ووضع الانحدار لبيانات
التحليل.
- كيان التغطية: يصف بيانات التغطية التي تم جمعها لملف واحد. يحتوي على معلومات مشروع Git ومسار الملف وقائمة
أعداد التغطية لكل سطر في الملف المصدر.
- كيان تنفيذ نموذج الاختبار يصف هذا العمود نتيجة أحد
حالات الاختبار المحدّدة من عملية إجراء اختبار، بما في ذلك اسم حالة الاختبار ونتيجة الاختبار.
- عنصر "الأماكن المفضّلة للمستخدم" يمكن تمثيل كل اشتراك مستخدم
في عنصر يحتوي على إشارة إلى الاختبار ورقم تعريف المستخدم
الذي تم إنشاؤه من خدمة مستخدم App Engine. يتيح ذلك إجراء عمليات بحث فعالة في الاتجاهين (أي لجميع المستخدمين المشتركين في اختبار ولجميع الاختبار
التي أعجب بها أحد المستخدمين).
تجميع الكيانات
تمثّل كلّ وحدة اختبار جذر مجموعة كيانات. عناصر عمليات التشغيل التجريبية
هي عناصر فرعية لهذه المجموعة وعناصر رئيسية لعناصر الأجهزة ونقاط ملف الأداء
وعناصر التغطية ذات الصلة باختبار وتشغيل تجربي
العلويَين.
الشكل 1: اختبِر سلسلة الإحالة إلى الكيان.
نقطة رئيسية: عند تصميم روابط
الأصول، عليك موازنة الحاجة إلى توفير آليات فعالة ومتسقة
للاستعلام مع القيود التي تفرضها قاعدة البيانات.
المزايا
يضمن شرط الاتساق عدم ظهور أثر المعاملة في العمليات المستقبلية إلى أن يتم تأكيدها، وأن تكون المعاملات السابقة مرئية للعمليات الحالية. في Cloud Datastore، تُنشئ تجميعات الكيانات
مجموعات من عمليات القراءة والكتابة المتسقة داخل المجموعة، والتي تشمل في هذه الحالة كل عمليات الاختبار والبيانات ذات الصلة بوحدة اختبار. في ما يلي فوائد ذلك:
- يمكن التعامل مع عمليات القراءة والتعديل لحالة وحدة الاختبار من خلال وظائف التنبيهات على أنّها
عمليات أساسية
- عرض متّسق مضمون لنتائج حالات الاختبار ضمن وحدات الاختبار
- إجراء عمليات بحث أسرع ضمن أشجار الأنساب
القيود
لا يُنصح بالكتابة إلى مجموعة كيانات بمعدّل أسرع من كيان واحد في الثانية، لأنّه قد يتم رفض بعض عمليات الكتابة. ما دامت مهام التنبيهات وعمليات التحميل تتم بمعدّل لا يتجاوز عملية كتابة واحدة في الثانية، تكون البنية قوية وتضمن اتساقًا قويًا.
في النهاية، يكون الحد الأقصى لكتابة واحدة لكل وحدة اختبار في الثانية معقولاً لأنّه
يستغرق عادةً تنفيذ الاختبارات دقيقة واحدة على الأقل، بما في ذلك الوقت المستغرَق في تنفيذ إطار عمل VTS
، ما لم يتم تنفيذ الاختبار باستمرار في وقت واحد على أكثر
من 60 مضيفًا مختلفًا، لا يمكن أن يكون هناك ازدحام في عمليات الكتابة. يصبح هذا الأمر
أكثر احتمالًا نظرًا لأنّ كل وحدة هي جزء من خطة اختبار تستغرق في أغلب الأحيان
أكثر من ساعة. يمكن التعامل بسهولة مع القيم الشاذة إذا كان المضيفون يجرون الاختبارات في
الوقت نفسه، ما يؤدي إلى حدوث طفرات قصيرة في عمليات الكتابة إلى المضيفين نفسهم (على سبيل المثال، من خلال
رصد أخطاء الكتابة وإعادة المحاولة).
اعتبارات التوسّع
لا يلزم أن يكون الاختبار هو العنصر الرئيسي لعملية تنفيذ الاختبار (على سبيل المثال، يمكنه استخدام مفتاح آخر ويكون له اسم الاختبار ووقت بدء الاختبار كسمات)، ولكن سيؤدي ذلك إلى استبدال الاتساق القوي بالاتساق النهائي. على سبيل المثال، قد لا ترى مهمة التنبيه لقطة اتّساق متبادل من أحدث عمليات تنفيذ الاختبار ضمن وحدة اختبار، ما يعني أنّ الحالة العامة قد لا تصوّر بشكل دقيق تسلسل عمليات تنفيذ الاختبار. وقد يؤثر ذلك أيضًا
في عرض عمليات تنفيذ الاختبار ضمن وحدة اختبار واحدة، والتي قد لا
تكون بالضرورة لقطة منتظمة لتسلسل التنفيذ. وفي النهاية، ستكون المقتطفات متسقة، ولكن لا يمكن ضمان أن تكون أحدث البيانات متسقة.
أُطُر الاختبار
ومن العوائق المحتملة الأخرى الاختبارات الكبيرة التي تتضمّن العديد من حالات الاختبار. إنّ المَعلمتَين
المحدودتَين للتشغيل هما الحد الأقصى لمعدل نقل البيانات للكتابة ضمن مجموعة كيانات
بمقدار معاملة واحدة في الثانية، بالإضافة إلى الحد الأقصى لحجم المعاملة الذي يبلغ 500 عنصر.
يمكن اتّباع نهج معيّن لتحديد نموذج اختبار يتضمّن عملية إجراء اختبار كعنصر أصل
(على غرار طريقة تخزين بيانات التغطية وبيانات الملف الشخصي ومعلومات الجهاز
):
الشكل 2: تُنشئ "أُطر الاختبار" من "عمليات الاختبار" (لا يُنصح بذلك).
على الرغم من أنّ هذا النهج يقدّم اتساقًا ووحدة، إلا أنّه يفرض قيودًا قوية
على الاختبارات: إذا كانت المعاملة تقتصر على 500 عنصر، لا يمكن أن يتضمّن الاختبار سوى 498 حالة اختبار (على افتراض عدم توفّر بيانات تغطية أو ملفّات تعريف).
إذا تجاوز الاختبار هذا الحدّ، لن تتمكّن معاملة واحدة من كتابة كل نتائج
حالة الاختبار دفعة واحدة، وقد يؤدي تقسيم حالات الاختبار إلى معاملات
منفصلة إلى تجاوز الحدّ الأقصى لمعدل نقل البيانات لكتابة مجموعة الكيانات، وهو دورة واحدة
في الثانية. لا يُنصح باستخدام هذا الحلّ لأنّه لن يتمكّن من التوسّع بشكل جيد بدون التضحية
بالأداء.
ومع ذلك، بدلاً من تخزين نتائج حالات الاختبار كعناصر فرعية لمسار الاختبار،
يمكن تخزين حالات الاختبار بشكل مستقل وتقديم مفاتيحها إلى مسار الاختبار (يحتوي مسار الاختبار على قائمة بالمعرّفات لعناصر حالات الاختبار):
الشكل 3: حالات الاختبار المخزّنة بشكل مستقل
(إجراء يُنصح به)
للوهلة الأولى، قد يبدو أنّ هذا يخالف ضمان الاتساق القوي.
ومع ذلك، إذا كان لدى العميل عنصر تشغيل اختبار وقائمة بمعرّفات حالات الاختبار، لن يحتاج إلى إنشاء طلب بحث، بل يمكنه بدلاً من ذلك الحصول مباشرةً على حالات الاختبار من خلال معرّفاتها، والتي يُضمن دائمًا أن تكون متسقة. يخفّف هذا النهج بشكل كبير من القيود المفروضة على عدد حالات الاختبار التي قد تتضمنها عملية الاختبار، مع تحقيق اتساق قوي بدون التهديد بالكتابة المفرطة ضمن مجموعة عناصر.
أنماط الوصول إلى البيانات
تستخدِم لوحة بيانات "التتبّع في الوقت الفعلي" أنماط الوصول إلى البيانات التالية:
- أجهزة المستخدم المفضّلة يمكن البحث عنها باستخدام فلتر مساواة
على عناصر المفضّلات الخاصة بالمستخدمين التي تحتوي على عنصر مستخدم App Engine معيّن
كخاصية.
- البيانات الاختبارية: طلب بحث بسيط عن الكيانات الاختبارية لتقليل
النطاق الترددي لعرض الصفحة الرئيسية، يمكن استخدام توقّع لعدد الاختبارات التي اجتازت الاختبار وعدد الاختبارات التي تعذّر إكمالها من أجل حذف القائمة الطويلة المحتملة لأرقام تعريف اختبارات الحالة التي تعذّر إكمالها وغيرها من البيانات الوصفية التي تستخدمها مهام التنبيهات.
- عمليات التنفيذ التجريبي: يتطلّب طلب البحث عن عناصر عمليات التشغيل التجريبية ترتيبًا
حسب المفتاح (الطابع الزمني) والفلترة المحتمَلة لخصائص عمليات التشغيل التجريبية، مثل
معرّف الإصدار وعدد عمليات الموافقة وما إلى ذلك. من خلال إجراء طلب بحث عن سلف باستخدام مفتاح
عنصر الاختبار، تكون القراءة متسقة بشكل كبير. في هذه المرحلة، يمكن استرجاع جميع
نتائج نموذج الاختبار باستخدام قائمة الأرقام التعريفية المخزّنة في خاصية "تشغيل الاختبار"، ويضمن ذلك أيضًا أن تكون النتيجة متسقة بشكل كبير بسبب طبيعة عمليات retrieving datastore.
- بيانات الملف الشخصي والتغطية: يمكن إجراء طلب بحث عن بيانات التحليل أو
التغطية المرتبطة باختبار بدون استرداد أي
بيانات أخرى عن عمليات تنفيذ الاختبار (مثل بيانات التحليل/التغطية الأخرى وبيانات حالات الاختبار وغيرها).
سيؤدي طلب بحث سلف باستخدام مفاتيح عنصرَي الاختبار وتشغيل الاختبار إلى retrieving all profiling points recorded during the test run. ومن خلال الفلترة أيضًا على اسم نقطة التحليل أو اسم الملف، يمكن retrieving a single profiling or coverage entity. وبحكم طبيعة طلبات البحث عن الأصول، تكون هذه العملية
متسقة بشكل كبير.
لمعرفة تفاصيل عن واجهة المستخدم ولقطات الشاشة لأنماط البيانات هذه أثناء استخدامها، يُرجى الاطّلاع على
واجهة مستخدم لوحة بيانات مراقبة الفيديو.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-07-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","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-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],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)."]]