لماذا قد تصبح استعلامات سجل Home Assistant بطيئة مع نمو بيانات المسجّل؟

لا يمتلك Home Assistant محرك «بحث» موحدًا تتراجع سرعته مع كل كيان تتم إضافته. تتمثل مشكلة التوسع الأوضح في أعمال الاستعلامات التاريخية: إذ يتعين على لوحة «السجل التاريخي» والعروض الشبيهة بسجل الأحداث والإحصاءات والميزات الأخرى المعتمدة على قاعدة البيانات استرداد بيانات Recorder المحتفظ بها وتنظيمها.

مع نمو مجموعة البيانات، تعتمد تكلفة الطلب على عدد الصفوف المطابقة، والفهارس التي يمكنها تضييق نطاقها، وما إذا كان يجب ضم السمات، ومقدار البيانات الموجود مسبقًا في الذاكرة، ومدى سرعة قدرة وحدة التخزين على توفير الصفحات غير الموجودة. حجم قاعدة البيانات مهم، لكن شكل الاستعلام مهم بالقدر نفسه.

يقرأ السجل التاريخي من Recorder، وليس من آلة الحالات الحية وحدها

تعيش قيم الأجهزة الحالية في نموذج الحالات قيد التشغيل في Home Assistant، بينما يقرأ تكامل السجل التاريخي الملاحظات المخزنة من Recorder. لذلك تستخدم بطاقة لوحة تعرض درجة الحرارة الحالية ومخططًا تاريخيًا لمدة خمسة أيام مساري بيانات مختلفين.

يوضح Home Assistant أن السجل التاريخي يعتمد على Recorder ويقرأ عادةً بيانات Recorder الخام ضمن فترة الاحتفاظ المُهيأة. وعندما يتجاوز النطاق المحدد هذه الفترة بالنسبة إلى المستشعرات المؤهلة، يمكنه استخدام الإحصاءات طويلة الأجل المجمعة كل ساعة بدلًا من ذلك.

لهذا السبب قد تجعل قاعدة البيانات التاريخية الكبيرة السجل التاريخي يبدو بطيئًا، بينما يستجيب تشغيل ضوء محلي فورًا.

المزيد من الحالات المحتفظ بها يعني المزيد من الصفوف والبيانات الوصفية وعمل الفهارس

تضيف كل عملية تحديث مسجلة معلومات إلى قاعدة البيانات. يقلل Home Assistant من التكرار عبر فصل معرّفات الكيانات والسمات المشتركة في جداول مرتبطة، لكن التثبيت النشط قد يراكم مع ذلك أعدادًا كبيرة من صفوف الحالات.

يوضح نموذج بيانات Home Assistant الحالي أن الحالات المسجلة تشير إلى بيانات تعريف الكيانات وصفوف السمات المشتركة، وتتضمن طوابع زمنية مفهرسة وعلاقات تُستخدم في الاستعلامات التاريخية. لذلك تزيد الكيانات سريعة التغير أكثر من مجرد عدد القيم المقروءة بسهولة.

يضاعف كل من مدة الاحتفاظ وتواتر التحديث تأثير الآخر. فالمستشعر الذي يتغير كل ثانية ينشئ مجموعة عمل مختلفة تمامًا عن مستشعر يتغير مرتين يوميًا، حتى لو كان كلاهما «كيانًا واحدًا».

تقلل الفهارس من عمل البحث، لكنها لا تجعل حجم النتائج مجانيًا

يمكن لـ SQLite استخدام الفهارس لتجنب فحص كل صف عند وجود قيود وترتيب شائعين للاستعلام. وهذا أمر ضروري للسجل التاريخي، لكن الفهرس لا يلغي تكلفة إرجاع نطاق كبير مطابق أو ضم البيانات المرتبطة.

توضح وثائق مخطط الاستعلام في SQLite أن الفهارس تسرّع البحث والترتيب، بينما تظل مجموعات النتائج الكبيرة وعمليات البحث عن الصفوف والفرز تتطلب عملًا يتناسب مع البيانات المحددة والخطة المستخدمة. ويختار المخطط من بين المسارات المتاحة بناءً على التكلفة المقدّرة.

وهذا يعني أن عبارة «تحتوي قاعدة البيانات على فهرس» وعبارة «يظل هذا الاستعلام بزمن ثابت إلى الأبد» ليستا متكافئتين. فلا تزال النطاقات الزمنية الأوسع والكيانات كثيرة الضوضاء تجعل مزيدًا من الصفحات والصفوف ذات صلة.

-15% OFF

ZimaBoard 2 - خادم منزلي صغير لأفكارك الكبيرة

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

الاحتفاظ ببيانات Recorder هو عنصر للتحكم في الأداء والسعة

يحذف Home Assistant بيانات Recorder القديمة تلقائيًا حتى لا تنمو بيانات الحالات التفصيلية بلا حدود. ويوفر تمديد فترة الاحتفاظ مزيدًا من السجل عالي الدقة، لكنه يزيد أيضًا مجموعة العمل التاريخية النشطة وحجم النسخ الاحتياطية وأعمال الصيانة.

تحذر وثائق Recorder صراحةً من أن السماح لقاعدة البيانات بالنمو بشكل مفرط يستهلك مساحة القرص وقد يجعل Home Assistant بطيئًا. وتوجد آلية الحذف وإعادة تنظيم البيانات الافتراضية فيه جزئيًا للحفاظ على نمو قاعدة البيانات ضمن حدود معقولة.

لذلك تُعد فترة الاحتفاظ المناسبة متطلبًا وظيفيًا. احتفظ بالبيانات عالية الدقة مدة كافية للإجابة عن الأسئلة المنزلية الفعلية، وليس لمجرد توفر مساحة على القرص.

تحدد وحدة التخزين وذاكرة التخزين المؤقت مدى تكلفة الاستعلام نفسه

قد يكون طلب السجل التاريخي المتكرر أسرع لأن صفحات قاعدة البيانات ونظام الملفات موجودة مسبقًا في الذاكرة. وقد يحتاج الاستعلام نفسه بعد إعادة التشغيل أو تحت ضغط الذاكرة إلى مزيد من عمليات القراءة الفعلية. كما يمكن لخدمة أخرى تكتب بكثافة على وحدة SSD نفسها أن تزيد زمن الاستجابة من دون تغيير طلب SQL.

يشرح تحليل ZimaSpace حول نمو البيانات الوصفية والسجل التاريخي في Home Assistant أسباب الجانب المتعلق بالكتابة. أما أداء الاستعلام فهو نتيجة جانب القراءة: وتصبح كثرة الحالات المحتفظ بها مؤثرة بدرجة أكبر عندما يلامسها النطاق المحدد أو مجموعة العمل فعلًا.

قِس زمن الاستعلام إلى جانب زمن استجابة وحدة التخزين وضغط الذاكرة قبل نقل قواعد البيانات أو شراء أجهزة أسرع.

خفّض تكلفة الاستعلام بتقليل البيانات غير الضرورية، لا السجل المفيد

• استبعد الكيانات التي لا تحمل تغيّراتها قيمة لاتخاذ القرار.
• قلل تواتر التحديث من المصدر عندما لا تكون التغيّرات عالية التواتر مفيدة.
• واءم فترة الاحتفاظ بالبيانات الخام مع النطاق الزمني الذي يفحصه المستخدمون فعليًا.
• استخدم الإحصاءات طويلة الأجل للفترات الممتدة عندما تكون التجميعات الساعية كافية.
• أبقِ Recorder على وحدة تخزين موثوقة منخفضة زمن الاستجابة مع هامش كافٍ من المساحة الحرة.
• قارن النطاق التاريخي نفسه قبل كل تغيير وبعده.

المقياس المفيد ليس حجم قاعدة البيانات وحده، بل كيفية تغير زمن الاستعلام مع تغير عدد الصفوف المحتفظ بها والنطاق الزمني المطلوب وحالة ذاكرة التخزين المؤقت وظروف وحدة التخزين.

الأسئلة الشائعة

هل تجعل قاعدة بيانات Recorder الأكبر حجمًا عمليات التشغيل المحلية أبطأ تلقائيًا؟

لا. يسلك التحكم في الأجهزة الحية والاستعلامات التاريخية مسارين منفصلين. وقد يؤثر أحدهما في الآخر بشكل غير مباشر عندما تتسبب أعمال Recorder في استهلاك مشترك للمعالج أو الذاكرة أو وحدة التخزين، لكن بطء مخطط السجل التاريخي لا يثبت أن محرك التشغيل بطيء.