أداء عالي وتقسيم أصلي: Zabbix مع دعم TimescaleDB

Zabbix هو نظام مراقبة. مثل أي نظام آخر ، فإنه يواجه ثلاث مشاكل رئيسية لجميع أنظمة المراقبة: جمع البيانات ومعالجتها ، وتخزين المحفوظات ، ومسحها.

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

يتم حل مشاكل تأخير التجميع والتخزين في Zabbix عن طريق التخزين المؤقت: عدة أنواع من ذاكرات التخزين المؤقت ، والتخزين المؤقت في قاعدة البيانات. لحل المشكلة الثالثة ، التخزين المؤقت غير مناسب ، لذلك تم استخدام TimescaleDB في Zabbix. سوف اقول عن ذلك أندري جوشين - مهندس دعم فني زابيكس سيا. كان Andrey يدعم Zabbix منذ أكثر من 6 سنوات ويشارك بشكل مباشر في الأداء.

كيف يعمل TimescaleDB ، ما هو الأداء الذي يمكن أن يقدمه مقارنة بـ PostgreSQL العادية؟ ما هو الدور الذي يلعبه Zabbix في TimescaleDB؟ كيف تبدأ من الصفر وكيف يتم الترحيل من PostgreSQL وأي تكوين هو أفضل؟ كل هذا تحت الخفض.

تحديات الأداء

يواجه كل نظام مراقبة تحديات أداء معينة. سأتحدث عن ثلاثة منهم: جمع البيانات ومعالجتها ، والتخزين ، وتنظيف السجل.

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

تخزين التاريخ. يجب أن يخزن نظام المراقبة الجيد التاريخ في قاعدة بيانات ويوفر وصولاً سهلاً إلى المقاييس. يجب استخدام السجل في التقارير والرسوم البيانية والمشغلات والحدود وعناصر التنبيه المحسوبة.

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

يعد تنظيف البيانات القديمة مشكلة شائكة لها تأثير كبير على أداء قاعدة البيانات.

التخزين المؤقت في Zabbix

في Zabbix ، يتم حل الاستدعاءات الأولى والثانية باستخدام التخزين المؤقت. تستخدم ذاكرة الوصول العشوائي لجمع البيانات ومعالجتها. للتخزين - التاريخ في المشغلات والرسوم البيانية والعناصر المحسوبة. على جانب قاعدة البيانات ، هناك بعض التخزين المؤقت للتحديدات الأساسية ، مثل الرسوم البيانية.

التخزين المؤقت على جانب خادم Zabbix نفسه هو:

• تكوين ذاكرة التخزين المؤقت.
• ValueCache ؛
• HistoryCache.
• الاتجاهات

النظر فيها بمزيد من التفصيل.

تكوين ذاكرة التخزين المؤقت

هذه هي ذاكرة التخزين المؤقت الرئيسية التي نخزن فيها المقاييس والمضيفين وعناصر البيانات والمحفزات - كل ما هو مطلوب للمعالجة المسبقة وجمع البيانات.

يتم تخزين كل هذا في ConfigurationCache حتى لا يتم إنشاء استعلامات غير ضرورية في قاعدة البيانات. بعد بدء تشغيل الخادم ، نقوم بتحديث ذاكرة التخزين المؤقت هذه ، وإنشاء التكوينات وتحديثها بشكل دوري.

جمع البيانات

المخطط كبير جدًا ، لكن الشيء الرئيسي فيه جامعي. هذه هي "أجهزة الاقتراع" المختلفة - عمليات التجميع. إنهم مسؤولون عن أنواع مختلفة من التجميع: يقومون بجمع البيانات عبر SNMP و IPMI ونقلها جميعًا إلى المعالجة المسبقة.

المنتقون محاطون بدائرة باللون البرتقالي.

قام Zabbix بحساب عناصر التجميع اللازمة لتجميع الشيكات. إذا كانت لدينا ، فإننا نأخذ البيانات الخاصة بهم مباشرة من ValueCache.

المعالجة المسبقة لذاكرة التخزين المؤقت

يستخدم جميع المُجمِّعين ConfigurationCache لتلقي الوظائف. ثم يقومون بنقلها إلى المعالجة المسبقة.

تستخدم المعالجة المسبقة ConfigurationCache للحصول على خطوات المعالجة المسبقة. يعالج هذه البيانات بطرق مختلفة.

بعد معالجة البيانات باستخدام المعالجة المسبقة ، نقوم بتخزينها في HistoryCache لمعالجتها. هذا يكمل جمع البيانات وننتقل إلى العملية الرئيسية في Zabbix - مزامنة التاريخ، لأنها معمارية متجانسة.

ملاحظة: ما قبل المعالجة عملية ثقيلة إلى حد ما. منذ الإصدار 4.2 تم نقله إلى وكيل. إذا كان لديك Zabbix كبير جدًا به عدد كبير من العناصر وتكرار التجميع ، فإن هذا يجعل الأمور أسهل كثيرًا.

ValueCache والتاريخ وذاكرة التخزين المؤقت للاتجاهات

مزامنة التاريخ هي العملية الرئيسية التي تعالج ذريًا كل عنصر من عناصر البيانات ، أي كل قيمة.

تأخذ مزامنة السجل القيم من HistoryCache وتتحقق من التهيئة لمشغلات العمليات الحسابية. إذا كانوا - يحسب.

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

تكتب مزامنة التاريخ جميع البيانات في قاعدة البيانات ، وتكتب على القرص. تنتهي عملية المعالجة هنا.

DB التخزين المؤقت

هناك العديد من ذاكرات التخزين المؤقت على جانب قاعدة البيانات عندما تريد إلقاء نظرة على الرسوم البيانية أو تقارير الأحداث:

• Innodb_buffer_pool على جانب MySQL ؛
• shared_buffers على جانب PostgreSQL ؛
• effective_cache_size على جانب أوراكل ؛
• shared_pool على جانب DB2.

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

أداء قاعدة البيانات أمر بالغ الأهمية

يقوم خادم Zabbix باستمرار بجمع البيانات وتدوينها. عند إعادة التشغيل ، يقرأ أيضًا من السجل لملء ValueCache. استخدامات البرامج النصية والتقارير واجهة برمجة تطبيقات زابيكس، والتي تم إنشاؤها على أساس واجهة الويب. يصل Zabbix API إلى قاعدة البيانات ويسترد البيانات الضرورية للرسوم البيانية والتقارير وقوائم الأحداث والأحداث الأخيرة.

للتصور - جرافانا. هذا حل شائع بين مستخدمينا. يمكنها إرسال الطلبات مباشرة من خلال Zabbix API وإلى قاعدة البيانات ، وإنشاء التزامن معين للحصول على البيانات. لذلك ، هناك حاجة إلى ضبط قاعدة البيانات بشكل أفضل وأفضل لمطابقة التسليم السريع للنتائج والاختبارات.

مدبرة المنزل

التحدي الثالث للأداء في Zabbix هو تنظيف التاريخ مع مدبرة المنزل. يحترم جميع الإعدادات - تشير عناصر البيانات إلى مدة تخزين ديناميكيات التغييرات (الاتجاهات) في الأيام.

TrendsCache نحسبها بسرعة. عندما تأتي البيانات ، نقوم بتجميعها في ساعة واحدة ووضعها في جداول لديناميكيات تغييرات الاتجاه.

تبدأ خدمة Housekeeper وتزيل المعلومات من قاعدة البيانات باستخدام "المحددات" المعتادة. هذا ليس فعالًا دائمًا ، وهو ما يمكن فهمه من الرسوم البيانية لأداء العمليات الداخلية.

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

متى يجب تعطيل مدبرة المنزل؟ على سبيل المثال ، هناك "معرف العنصر" وتحتاج إلى حذف آخر 5 آلاف سطر في وقت معين. بالطبع ، يحدث هذا عن طريق الفهارس. ولكن عادةً ما تكون مجموعة البيانات كبيرة جدًا ، ولا تزال قاعدة البيانات تقرأ من القرص وتضعها في ذاكرة التخزين المؤقت. هذه دائمًا عملية مكلفة للغاية لقاعدة البيانات ، واعتمادًا على حجم قاعدة البيانات ، يمكن أن تؤدي إلى مشاكل في الأداء.

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

تم تعطيل مدبرة المنزل ، وتم إيقاف تشغيل الرسومات - ما هي المشاكل التي يمكن أن تكون في هذه الحالة وما الذي يمكن أن يساعد في حل تحدي الأداء الثالث؟

التقسيم - التقسيم أو التقسيم

عادةً ما يتم تكوين التقسيم بطريقة مختلفة في كل قاعدة بيانات علائقية أدرجتها. لكل منها تقنيتها الخاصة ، لكنها متشابهة بشكل عام. غالبًا ما يؤدي إنشاء قسم جديد إلى مشاكل معينة.

عادةً ما يتم تكوين الأقسام اعتمادًا على "الإعداد" - مقدار البيانات التي يتم إنشاؤها في يوم واحد. كقاعدة عامة ، يتم إعداد التقسيم في يوم واحد ، وهذا هو الحد الأدنى. لاتجاهات التقسيم الجديدة - شهر واحد.

قد تتغير القيم في حالة "الإعداد" الكبير جدًا. إذا كان "الإعداد" الصغير يصل إلى 5 nvps (قيم جديدة في الثانية) ، فإن المتوسط ​​يتراوح من 000 إلى 5 ، ثم يكون الإعداد الكبير أعلى من 000 nvps. هذه عمليات تثبيت كبيرة وكبيرة جدًا تتطلب تكوينًا دقيقًا لقاعدة البيانات نفسها.

في عمليات التثبيت الكبيرة جدًا ، قد لا يكون يوم واحد هو الأمثل. لقد رأيت أقسام MySQL بسعة 40 غيغابايت أو أكثر يوميًا. هذه كمية كبيرة جدًا من البيانات يمكن أن تؤدي إلى مشاكل ويجب تقليلها.

ما الذي يعطي التقسيم؟

طاولات التقسيم. غالبًا ما تكون هذه ملفات منفصلة على القرص. تحدد خطة الاستعلام قسمًا واحدًا على النحو الأمثل. عادةً ما يتم استخدام التقسيم حسب النطاق - وهذا ينطبق أيضًا على Zabbix. نستخدم هناك "الطابع الزمني" - الوقت منذ بداية العصر. لدينا أرقام منتظمة. أنت تحدد بداية اليوم ونهايته - هذا قسم.

إزالة سريعة - DELETE. تم تحديد ملف واحد / جدول فرعي ، وليس مجموعة من الصفوف للحذف.

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

غالبًا ما يتم تسريع العديد من قواعد البيانات INSERT - يُدرج في الجدول الفرعي.

الجدول الزمني

بالنسبة للإصدار 4.2 ، وجهنا انتباهنا إلى TimescaleDB. هذا امتداد PostgreSQL بواجهة أصلية. يعمل الامتداد بكفاءة مع بيانات السلاسل الزمنية دون فقدان مزايا قواعد البيانات العلائقية. يتم أيضًا تقسيم TimescaleDB تلقائيًا.

TimescaleDB لديه مفهوم مفرط (قابل للضغط) الذي تقوم بإنشائه. بداخلها قطع - حواجز. المقاطع هي أجزاء مُدارة تلقائيًا من قابل للضغط لا تؤثر على الأجزاء الأخرى. كل قطعة لها نطاقها الزمني الخاص.

TimescaleDB مقابل PostgreSQL

TimescaleDB فعالة حقًا. يدعي منتجو الامتداد أنهم يستخدمون خوارزمية معالجة استعلام أكثر دقة ، على وجه الخصوص ، inserts . مع نمو حجم إدراج مجموعة البيانات ، تحافظ الخوارزمية على أداء ثابت.

بعد 200 مليون صف ، تبدأ PostgreSQL عادةً في التدهور كثيرًا وفقدان الأداء إلى الصفر. يسمح لك TimescaleDB بإدراج "الإدخالات" بكفاءة مع أي كمية من البيانات.

تركيب

يعد تثبيت TimescaleDB أمرًا سهلاً بما يكفي لأي حزم. في توثيق كل شيء مفصل - يعتمد ذلك على حزم PostgreSQL الرسمية. يمكن أيضًا بناء TimescaleDB وتجميعها يدويًا.

بالنسبة لقاعدة بيانات Zabbix ، نقوم ببساطة بتنشيط الامتداد:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

تقوم بتنشيطه extension وقم بإنشائه لقاعدة بيانات Zabbix. الخطوة الأخيرة هي إنشاء ملف قابل للضغط.

ترحيل جداول المحفوظات إلى TimescaleDB

هناك وظيفة خاصة لهذا. create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

الوظيفة لها ثلاث معلمات. أولاً - الجدول في قاعدة البياناتالذي تريد إنشاء ملف. ثانية - حقل، والتي بموجبها من الضروري الخلق chunk_time_interval - الفاصل الزمني لأجزاء التقسيم المراد استخدامها. في حالتي ، الفاصل الزمني هو يوم واحد - 86.

المعلمة الثالثة هي migrate_data. إذا تم ضبطه true، ثم يتم نقل جميع البيانات الحالية إلى أجزاء تم إنشاؤها مسبقًا. أنا نفسي قد استخدمت migrate_data. كان لدي حوالي 1 تيرابايت استغرق أكثر من ساعة. حتى في بعض الحالات ، عند الاختبار ، قمت بحذف البيانات التاريخية لأنواع الأحرف التي تعتبر اختيارية للتخزين حتى لا يتم نقلها.

اخر خطوة - UPDATE: في db_extension يضع timescaledbحتى تفهم قاعدة البيانات أن هناك هذا الامتداد. يقوم Zabbix بتنشيطه ويستخدم بشكل صحيح بناء الجملة والاستعلامات الموجودة بالفعل في قاعدة البيانات - تلك الميزات الضرورية لـ TimescaleDB.

تكوين الأجهزة

لقد استخدمت خادمين. أولاً - آلة VMware. إنه صغير بما يكفي: 20 وحدة المعالجة المركزية Intel® Xeon® CPU E5-2630 v 4 @ 2.20 جيجاهرتز و 16 جيجابايت من ذاكرة الوصول العشوائي ومحرك أقراص SSD سعة 200 جيجابايت.

لقد قمت بتثبيت PostgreSQL 10.8 عليه باستخدام نظام الملفات Debian OS 10.8-1.pgdg90 + 1 و xfs. لقد قمت بتكوين كل شيء بشكل ضئيل لاستخدام قاعدة البيانات هذه ، باستثناء ما سيستخدمه Zabbix نفسه.

على نفس الجهاز كان هناك خادم Zabbix و PostgreSQL و وكلاء التحميل. كان لدي 50 عاملًا نشطًا استخدموا LoadableModuleلتوليد نتائج مختلفة بسرعة كبيرة: أرقام ، سلاسل. لقد ملأت قاعدة البيانات بالكثير من البيانات.

في البداية ، تم تضمين التكوين 5 عنصر البيانات لكل مضيف. احتوى كل عنصر تقريبًا على مشغل لجعله يبدو وكأنه عمليات تثبيت حقيقية. في بعض الحالات كان هناك أكثر من مشغل واحد. كانت عقدة شبكة واحدة 3-000 محفز.

الفاصل الزمني لتحديث العنصر - 4-7 ثواني. لقد قمت بتنظيم الحمل نفسه ليس فقط باستخدام 50 عاملًا ، ولكن بإضافة المزيد. أيضًا ، بمساعدة عناصر البيانات ، قمت بتنظيم الحمل ديناميكيًا وخفضت الفاصل الزمني للتحديث إلى 4 ثوانٍ.

PostgreSQL. 35 nvps

كان أول تشغيل لي على هذا الجهاز على PostgreSQL النقي - 35 ألف قيمة في الثانية. كما ترى ، يستغرق إدخال البيانات أجزاء من الثانية - كل شيء على ما يرام وسريع. الشيء الوحيد هو أن محرك أقراص SSD سعة 200 جيجابايت يمتلئ بسرعة.

هذه لوحة معلومات قياسية لأداء خادم Zabbix.

الرسم البياني الأول باللون الأزرق هو عدد القيم في الثانية. الرسم البياني الثاني على اليمين هو تحميل عمليات البناء. والثالث هو تحميل عمليات البناء الداخلية: مزامنات التاريخ ومدبرة المنزل ، والتي كانت تعمل منذ بعض الوقت هنا.

يوضح الرسم البياني الرابع استخدام HistoryCache. هذا نوع من المخزن المؤقت قبل الإدراج في قاعدة البيانات. يُظهر الرسم البياني الخامس الأخضر استخدام ValueCache ، أي أن عدد نتائج ValueCache للمشغلات هو عدة آلاف من القيم في الثانية.

PostgreSQL. 50 nvps

ثم قمت بزيادة الحمل إلى 50 ألف قيمة في الثانية على نفس الجهاز.

عند التحميل من Housekeeper ، استغرق إدخال 10 آلاف قيمة من 2 إلى 3 ثوانٍ.

مدبرة المنزل بدأت بالفعل في الوقوف في الطريق.

يوضح الرسم البياني الثالث ، بشكل عام ، أن تحميل المتراكبين ومزامني التاريخ لا يزال عند مستوى 60٪. في الرسم البياني الرابع ، بدأ HistoryCache أثناء تشغيل Housekeeper بالفعل بالملء بنشاط كبير. 20٪ ممتلئ - حوالي 0,5 غيغابايت.

PostgreSQL. 80 nvps

ثم قمت بزيادة الحمل إلى 80 ألف قيمة في الثانية. هذا ما يقرب من 400 ألف عنصر بيانات و 280 ألف مشغل.

إدراج تحميل ثلاثين مزامنة للتاريخ مرتفع بالفعل.

لقد قمت أيضًا بزيادة المعلمات المختلفة: مزامنة التاريخ ، وذاكرة التخزين المؤقت.

على أجهزتي ، زاد تحميل مزامنات السجل إلى الحد الأقصى. تملأ HistoryCache بالبيانات بسرعة - لقد قام المخزن المؤقت بتجميع البيانات للمعالجة.

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

لقد استفدت من سعة القرص القصوى على هذا الجهاز وعلى هذا الجهاز الظاهري. بهذه الكثافة ، بدأت PostgreSQL في تفريغ البيانات بنشاط كبير ، ولم يعد للقرص وقت للكتابة والقراءة.

الخادم الثاني

أخذت خادمًا آخر يحتوي بالفعل على 48 معالجًا و 128 جيجابايت من ذاكرة الوصول العشوائي. قمت بضبطه - ضبط 60 مزامنة للتاريخ ، وحققت أداءً مقبولاً.

في الواقع ، يعد هذا بالفعل حدًا للأداء حيث يلزم القيام بشيء ما.

مقياس الوقت ب. 80،000 nvps

مهمتي الرئيسية هي اختبار قدرات TimescaleDB مقابل تحميل Zabbix. 80 ألف قيمة في الثانية هي عدد كبير ، وتكرار جمع المقاييس (باستثناء Yandex بالطبع) و "الإعداد" الكبير إلى حد ما.

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

يسمح لك TimescaleDB بإدخال البيانات بشكل أسرع بثلاث مرات تقريبًا واستخدام أقل لـ HistoryCache.

وفقًا لذلك ، ستتلقى البيانات في الوقت المناسب.

مقياس الوقت ب. 120،000 nvps

ثم قمت بزيادة عدد عناصر البيانات إلى 500 ألف ، وكانت المهمة الرئيسية هي التحقق من إمكانيات TimescaleDB - حصلت على قيمة محسوبة تبلغ 125 ألف قيمة في الثانية.

هذا "إعداد" عملي يمكن أن يستغرق وقتًا طويلاً للعمل. ولكن نظرًا لأن قرصي كان 1,5 تيرابايت فقط ، فقد ملأته في غضون يومين.

الأهم من ذلك ، أنه تم إنشاء أقسام TimescaleDB جديدة في نفس الوقت.

بالنسبة للأداء ، هذا غير ملحوظ تمامًا. عندما يتم إنشاء الأقسام في MySQL ، على سبيل المثال ، تختلف الأمور. يحدث هذا عادة في الليل ، لأنه يمنع الإدراج العام ، والتلاعب بالجدول ويمكن أن يؤدي إلى تدهور الخدمة. هذا ليس هو الحال مع TimescaleDB.

على سبيل المثال ، سأعرض رسمًا بيانيًا واحدًا من المجموعة في المجتمع. في الصورة ، تم تمكين TimescaleDB ، وبفضل ذلك انخفض الحمل على استخدام io.weight على المعالج. كما انخفض استخدام عناصر العمليات الداخلية. علاوة على ذلك ، هذه آلة افتراضية عادية على أقراص فطيرة عادية ، وليست SSD.

النتائج

TimescaleDB هو حل جيد "للإعدادات" الصغيرة، والتي تعتمد على أداء القرص. سيسمح لك بمواصلة العمل بشكل جيد حتى يتم ترحيل قاعدة البيانات إلى الأجهزة بشكل أسرع.

من السهل إعداد TimescaleDB ، ويعزز الأداء ، ويعمل بشكل جيد مع Zabbix و لها مزايا على PostgreSQL.

إذا كنت تستخدم PostgreSQL ولا تخطط لتغييره ، فأنا أوصي بذلك استخدم PostgreSQL مع ملحق TimescaleDB جنبًا إلى جنب مع Zabbix. يعمل هذا الحل بشكل فعال حتى "الإعداد" المتوسط.

نقول "أداء عالي" - نعني HighLoad ++. لن يمر وقت طويل قبل أن تتعرف على التقنيات والممارسات التي تسمح للخدمات بخدمة ملايين المستخدمين. قائمة التقارير في 7 و 8 تشرين الثاني (نوفمبر) ، وضعنا بالفعل ، لكن اللقاءات يمكن اقتراح المزيد.

اشترك في موقعنا النشرة الإخبارية и تيليجرام، والذي نكشف فيه عن ملامح المؤتمر القادم ، ونتعرف على كيفية تحقيق أقصى استفادة منه.

المصدر: www.habr.com