Zabbix هو نظام مراقبة. مثله مثل أي نظام آخر ، فإنه يواجه ثلاث مشكلات رئيسية لجميع أنظمة المراقبة: جمع البيانات ومعالجتها ، وتخزين المحفوظات ، وتنظيفها.
تستغرق خطوات الحصول على البيانات ومعالجتها وتسجيلها بعض الوقت. ليس كثيرًا ، لكن بالنسبة للنظام الكبير ، قد يؤدي ذلك إلى تأخير كبير. مشكلة التخزين مشكلة في الوصول إلى البيانات. يتم استخدامها للتقارير والشيكات والمشغلات. التأخير في الوصول إلى البيانات يؤثر أيضًا على الأداء. عندما تنمو قاعدة البيانات ، يجب حذف البيانات غير ذات الصلة. الإزالة هي عملية صعبة تستهلك أيضًا بعض الموارد.
يتم حل مشاكل التأخير أثناء التجميع والتخزين في Zabbix بواسطة التخزين المؤقت: عدة أنواع من التخزين المؤقت ، والتخزين المؤقت في قاعدة البيانات. لحل المشكلة الثالثة ، التخزين المؤقت غير مناسب ، لذلك ، استخدم Zabbix TimescaleDB.
سيتحدث Andrey Gushchin ، مهندس الدعم الفني في
Zabbix SIA ، عن هذا. يعمل Andrey على دعم Zabbix لأكثر من 6 سنوات ويواجه الأداء مباشرةً.
كيف يعمل TimescaleDB ، ما الأداء الذي يمكن أن يقدمه مقارنةً بـ PostgreSQL العادي؟ ما هو الدور الذي يلعبه Zabbix في TimescaleDB؟ كيف تعمل من الصفر وكيف تهاجر مع PostgreSQL وأي أداء أفضل؟ حول كل هذا تحت الخفض.
تحديات الأداء
يواجه كل نظام مراقبة تحديات خاصة بالأداء. سأتحدث عن ثلاثة منهم: جمع ومعالجة البيانات وتخزين وتنظيف السجل.
جمع ومعالجة البيانات بسرعة. يجب أن يتلقى نظام المراقبة الجيد جميع البيانات بسرعة ويعالجها وفقًا لتعبيرات المشغل - وفقًا لمعاييره الخاصة. بعد المعالجة ، يجب على النظام أيضًا حفظ هذه البيانات بسرعة في قاعدة البيانات لاستخدامها لاحقًا.
حفظ قصة. يجب أن يخزن نظام المراقبة الجيد السجل في قاعدة البيانات ويوفر سهولة الوصول إلى المقاييس. هناك حاجة إلى قصة لاستخدامها في التقارير والرسوم البيانية والمشغلات والعتبات وعناصر البيانات المحسوبة للتنبيهات.
مسح التاريخ. في بعض الأحيان يأتي يوم عندما لا تحتاج إلى تخزين المقاييس. لماذا تحتاج إلى البيانات التي تم جمعها منذ 5 سنوات أو شهر أو شهرين: تم حذف بعض العقد ، ولم تعد هناك حاجة إلى بعض المضيفين أو المقاييس ، لأنها عفا عليها الزمن وتوقفت عن التجميع. يجب أن يقوم نظام المراقبة الجيد بتخزين البيانات التاريخية وحذفها من وقت لآخر حتى لا تنمو قاعدة البيانات.
يعد مسح البيانات القديمة مشكلة ساخنة لها تأثير كبير على أداء قاعدة البيانات.
التخزين المؤقت Zabbix
في Zabbix ، يتم حل المكالمات الأولى والثانية باستخدام التخزين المؤقت. يستخدم RAM لجمع البيانات ومعالجتها. للتخزين - قصص في المشغلات ، الرسوم البيانية ، وعناصر البيانات المحسوبة. على جانب قاعدة البيانات ، يوجد تخزين مؤقت معين للعينات الرئيسية ، على سبيل المثال ، المخططات.
التخزين المؤقت على جانب خادم Zabbix نفسه:
- ConfigurationCache.
- ValueCache.
- HistoryCache.
- TrendsCache.
لننظر فيها بمزيد من التفصيل.
ConfigurationCache
هذا هو ذاكرة التخزين المؤقت الرئيسية التي نخزن فيها المقاييس والمضيفات وعناصر البيانات والمشغلات - كل ما هو مطلوب للمعالجة المسبقة ولجمع البيانات.
يتم تخزين كل هذا في ConfigurationCache حتى لا يتم إنشاء استعلامات غير ضرورية في قاعدة البيانات. بعد بدء تشغيل الخادم ، نقوم بتحديث ذاكرة التخزين المؤقت هذه وإنشاء تكوينات وتحديثها بشكل دوري.
جمع البيانات
المخطط كبير جدًا ، لكن الشيء الرئيسي فيه هو
المجمعات . هذه هي "استطلاعات الرأي" المختلفة - عمليات التجميع. يتحملون مسؤولية أنواع مختلفة من التجميع: يقومون بجمع البيانات عبر SNMP ، IPMI ، ونقلها إلى PreProcessing.
المجمعات محاطة باللون البرتقالي.قام Zabbix بحساب عناصر بيانات التجميع اللازمة لتجميع عمليات التحقق. إذا كان لدينا منهم ، فإننا نأخذ البيانات الخاصة بهم مباشرة من ValueCache.
قبل تجهيز HistoryCache
يستخدم جميع المجمعين ConfigurationCache لتلقي الوظائف. ثم يمررونها إلى PreProcessing.
يستخدم PreProcessing ConfigurationCache لتلقي خطوات PreProcessing. يعالج هذه البيانات بطرق مختلفة.
بعد معالجة البيانات باستخدام PreProcessing ، نقوم بحفظها في HistoryCache لمعالجتها. ينتهي هذا بجمع البيانات وننتقل إلى العملية الرئيسية في Zabbix -
syncer history ، لأنها بنية متجانسة.
ملاحظة: PreProcessing هي عملية صعبة للغاية. منذ الإصدار 4.2 ، تم إرساله إلى الخادم الوكيل. إذا كان لديك Zabbix كبير جدًا به عدد كبير من عناصر البيانات وتكرار التجميع ، فهذا يسهل العمل إلى حد كبير.ValueCache ، ذاكرة التخزين المؤقت والاتجاهات التاريخ
محفوظات السجل هي العملية الرئيسية التي تقوم بمعالجة كل عنصر من عناصر البيانات تلقائيًا ، أي كل قيمة.
يأخذ محفوظات المحفوظات قيمًا من HistoryCache ويتحقق من "التكوين" بحثًا عن مشغلات الحسابات. إذا كانوا كذلك ، فإنه يحسب.
ينشئ مزامنة السجل حدثًا وتصعيدًا لإنشاء تنبيهات ، إذا لزم الأمر من خلال التكوين والسجلات. إذا كانت هناك مشغلات للمعالجة اللاحقة ، فإنه يتذكر هذه القيمة في ValueCache حتى لا يتمكن من الوصول إلى جدول المحفوظات. لذلك يتم تعبئة ValueCache بالبيانات الضرورية لحساب المشغلات والعناصر المحتسبة.
تزامن محفوظات يكتب جميع البيانات إلى قاعدة البيانات ، ويتم كتابتها إلى القرص. تنتهي عملية المعالجة هنا.
التخزين المؤقت DB
على الجانب DB ، هناك العديد من ذاكرات التخزين المؤقت عندما تريد مشاهدة الرسوم البيانية أو تقارير الأحداث:
Innodb_buffer_pool على الجانب MySQL ؛shared_buffers على الجانب PostgreSQL ؛effective_cache_size على جانب Oracle ؛shared_pool على الجانب DB2.
هناك العديد من ذاكرات التخزين المؤقت الأخرى ، ولكن هذه هي العناصر الرئيسية لجميع قواعد البيانات. إنها تتيح لك الاحتفاظ بالذاكرة في كثير من الأحيان البيانات اللازمة للاستعلامات. لديهم تقنياتهم الخاصة لهذا الغرض.
أداء قاعدة البيانات أمر بالغ الأهمية
يقوم Zabbix-server بجمع البيانات باستمرار وكتابتها. عند إعادة التشغيل ، يقرأ أيضًا من السجل لملء ValueCache. تستخدم البرامج النصية والتقارير
واجهة برمجة تطبيقات Zabbix ، والتي بنيت على أساس واجهة الويب. تقوم واجهة برمجة تطبيقات Zabbix بالاتصال بقاعدة البيانات وتتلقى البيانات اللازمة للرسوم البيانية والتقارير وقوائم الأحداث والمشاكل الحديثة.
للتصور -
غرافانا . بين مستخدمينا ، هذا هو الحل الشعبي. يمكنه إرسال الطلبات مباشرة من خلال واجهة برمجة تطبيقات Zabbix وإلى قاعدة البيانات ، ويخلق قدرة تنافسية معينة لاستقبال البيانات. لذلك ، نحتاج إلى ضبط أفضل وأفضل لقاعدة البيانات لتتوافق مع النتائج السريعة للنتائج والاختبار.
مدبرة المنزل
التحدي الثالث في الأداء في Zabbix هو مسح التاريخ مع مدبرة منزل. يتبع كل الإعدادات - تشير عناصر البيانات إلى مقدار الاحتفاظ بديناميات التغييرات (الاتجاهات) بالأيام.
نحن نحسب TrendsCache على الطاير. عندما تصل البيانات ، نقوم بتجميعها في ساعة واحدة ونكتبها في جداول ديناميكية تغييرات الاتجاه.
مدبرة المنزل تبدأ وتحذف المعلومات من قاعدة البيانات مع المعتاد "يختار". هذا ليس فعالًا دائمًا ، والذي يمكن فهمه من خلال الرسوم البيانية لأداء العمليات الداخلية.
يشير الرسم البياني الأحمر إلى أن مزامنة السجل مشغولة باستمرار. المخطط البرتقالي أعلاه هو مدبرة المنزل ، والذي يعمل باستمرار. إنه يتوقع أن تحذف قاعدة البيانات جميع الصفوف التي حددها.
متى تغلق مدبرة المنزل؟ على سبيل المثال ، هناك "معرف العنصر" وتحتاج إلى حذف آخر 5 آلاف سطر في وقت معين. بالطبع ، هذا يحدث عن طريق الفهرس. ولكن عادةً ما تكون مجموعة البيانات كبيرة جدًا ، ولا تزال قاعدة البيانات تقرأ من القرص وترفعها إلى ذاكرة التخزين المؤقت. هذه دائمًا عملية مكلفة للغاية لقاعدة البيانات ، ويمكن أن تؤدي إلى مشاكل في الأداء ، اعتمادًا على حجم قاعدة البيانات.
مدبرة المنزل هو مجرد قطع الاتصال. في واجهة الويب ، يوجد إعداد في "الإدارة العامة" لـ Housekeeper. تعطيل التدبير المنزلي الداخلي لتاريخ الاتجاه الداخلي ولم يعد يدير هذا.
تم إيقاف مدبرة المنزل ، وتم تسوية الرسوم البيانية - ما المشكلة التي يمكن أن تحدث في هذه الحالة ، وما الذي يمكن أن يساعد في حل مكالمة الأداء الثالثة؟
التقسيم - التقسيم أو التقسيم
عادة ، يتم تكوين التقسيم بطريقة مختلفة على كل قاعدة بيانات علائقية قمت بإدراجها. لكل منها التكنولوجيا الخاصة بها ، لكنها متشابهة ، بشكل عام. غالباً ما يؤدي إنشاء قسم جديد إلى بعض المشكلات.
عادة ما يتم تكوين الأقسام حسب "الإعداد" - مقدار البيانات التي يتم إنشاؤها في يوم واحد. كقاعدة عامة ، يتم كشف التقسيم في يوم واحد ، وهذا هو الحد الأدنى. لاتجاهات القسم الجديد - لمدة شهر واحد.
قد تتغير القيم في حالة وجود "إعداد" كبير جدًا. إذا كان "الإعداد" الصغير يصل إلى 5000 nvps (قيم جديدة في الثانية الواحدة) ، فإن المتوسط يتراوح من 5000 إلى 25000 ، ثم الكبير أكبر من 25000 nvps. هذه عمليات تثبيت كبيرة وكبيرة جدًا تتطلب تكوينًا دقيقًا لقاعدة البيانات.
في عمليات التثبيت الكبيرة جدًا ، قد لا يكون التشغيل ليوم واحد هو الأمثل. رأيت على أقسام الخلية من 40 غيغابايت أو أكثر في اليوم الواحد. هذه كمية كبيرة جدًا من البيانات التي يمكن أن تؤدي إلى مشاكل ، ويجب تقليلها.
ما يعطي التقسيم؟
جداول التقسيم . غالبًا ما تكون هذه ملفات منفصلة على القرص. تحدد خطة الاستعلام قسمًا واحدًا على النحو الأمثل. عادة ما يتم استخدام التقسيم على مدى - بالنسبة إلى Zabbix ، هذا صحيح أيضًا. نستخدم هناك "الطابع الزمني" - الوقت من بداية العصر. لدينا أرقام عادية. قمت بتعيين بداية ونهاية اليوم - وهذا هو القسم.
حذف سريع -
DELETE . يتم تحديد ملف واحد / جدول فرعي ، وليس مجموعة مختارة من الصفوف المراد حذفها.
يسرع بشكل واضح من استرداد SELECT لاسترداد البيانات - يستخدم قسمًا أو أكثر ، وليس الجدول بأكمله. إذا طلبت بيانات قبل يومين ، يتم اختيارهم من قاعدة البيانات بشكل أسرع لأنك تحتاج إلى تحميل في ذاكرة التخزين المؤقت وإصدار ملف واحد فقط ، وليس جدول كبير.
في كثير من الأحيان ، تسريع العديد من قواعد البيانات
INSERT إدراج في الجدول التابع.
TimescaleDB
بالنسبة إلى الإصدار 4.2 ، لجأنا إلى TimescaleDB. هذا امتداد لبرنامج PostgreSQL مع واجهة أصلية. يعمل الملحق بفعالية مع بيانات السلاسل الزمنية ، دون فقد فوائد قواعد البيانات العلائقية. TimescaleDB أيضا أقسام تلقائيا.
TimescaleDB لديه مفهوم
hypertable التي تقوم بإنشائها. أنه يحتوي على
قطع - أقسام. الأجزاء يتم التحكم فيها تلقائيًا في أجزاء من hypertable لا تؤثر على الأجزاء الأخرى. كل قطعة لها مجموعة زمنية خاصة بها.
TimescaleDB مقابل بوستجرس
TimescaleDB يعمل بكفاءة حقا. يدعي مصنعو الإضافات أنهم يستخدمون خوارزمية معالجة طلب أكثر دقة ، ولا سيما <code> insertions </code>. عندما تنمو أبعاد مجموعة البيانات ، تحافظ الخوارزمية على أداء ثابت.
بعد 200 مليون صف ، يبدأ PostgreSQL عادة في الترهل بشدة ويفقد الأداء حتى 0. يسمح لك TimescaleDB بإدراج "إدراج" بكفاءة لأي كمية من البيانات.
تركيب
إن تثبيت TimescaleDB سهل بدرجة كافية لأي حزم. تصف
الوثائق كل شيء بالتفصيل - تعتمد على حزم PostgreSQL الرسمية. يمكن أيضًا تصنيف TimescaleDB وتجميعه يدويًا.
بالنسبة لقاعدة بيانات Zabbix ، نقوم ببساطة بتنشيط الامتداد:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
يمكنك تنشيط
extension وإنشائه لقاعدة بيانات Zabbix. الخطوة الأخيرة هي إنشاء hypertable.
ترحيل جداول المحفوظات إلى 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
وظيفة لديها ثلاثة معايير. الأول هو
جدول في قاعدة البيانات التي تحتاج إلى إنشاء hypertable. الثاني هو
الحقل الذي سيتم من خلاله إنشاء
chunk_time_interval - الفاصل الزمني
chunk_time_interval الأجزاء التي تريد استخدامها. في حالتي ، الفاصل الزمني هو يوم واحد - 86400.
المعلمة الثالثة هي
migrate_data . إذا تم التعيين على
true ، فسيتم نقل جميع البيانات الحالية إلى مجموعات تم إنشاؤها مسبقًا. أنا نفسي تستخدم
migrate_data . كان لدي حوالي 1 تيرابايت ، والتي استغرقت أكثر من ساعة. حتى في بعض الحالات ، عند الاختبار ، قمت بحذف البيانات التاريخية لأنواع الأحرف التي كانت اختيارية للتخزين ، حتى لا أقوم بنقلها.
الخطوة الأخيرة هي
UPDATE : لقد قمنا بتعيين
timescaledb في
db_extension بحيث تدرك قاعدة البيانات وجود هذا الامتداد. يقوم Zabbix بتنشيطه ويستخدم بشكل صحيح بناء الجملة والاستعلامات بالفعل في قاعدة البيانات - تلك الميزات الضرورية لـ TimescaleDB.
تكوين الحديد
اعتدت خادمين. الأول هو جهاز
VMware . إنها صغيرة بما يكفي: 20 معالجات Intel® Xeon® E5-2630 v 4 @ 2.20GHz و 16 جيجابايت من ذاكرة الوصول العشوائي و SSD بسعة 200 جيجابايت.
لقد قمت بتثبيت PostgreSQL 10.8 عليه مع Debian 10.8-1.pgdg90 + 1 ونظام ملفات xfs. لقد قمت بتكوين كل شيء على أقل تقدير لاستخدام قاعدة البيانات هذه ، ناقصًا ما ستستخدمه Zabbix نفسها.
على نفس الجهاز ، كان خادم Zabbix و PostgreSQL
ووكلاء التحميل . كان لدي 50 وكيلًا نشطًا استخدموا
LoadableModule لتوليد نتائج مختلفة بسرعة: الأرقام ، السلاسل. أنا انسداد قاعدة البيانات مع الكثير من البيانات.
في البداية ، تضمن التكوين
5000 عنصر بيانات لكل مضيف. احتوى كل عنصر تقريبًا على مشغل ، بحيث كان مشابهًا للتركيبات الحقيقية. في بعض الحالات ، كان هناك أكثر من مشغل واحد. كان هناك
3000-7000 مشغلات لكل عقدة شبكة.
الفاصل الزمني لتحديث عناصر البيانات هو
4-7 ثواني . لقد قمت بتنظيم الحمل نفسه باستخدام 50 وكيلًا ، ولكن أيضًا إضافة المزيد. أيضًا ، بمساعدة عناصر البيانات ، قمت بضبط الحمل بشكل ديناميكي وخفضت الفاصل الزمني للتحديث إلى 4 ثوانٍ.
كيو. 35000 nvps
أول تشغيل على هذا الجهاز كان لي على بوستجرس نقية - 35 ألف القيم في الثانية الواحدة. كما ترى ، فإن إدخال البيانات يستغرق كسور في الثانية - كل شيء على ما يرام وسريع. الشيء الوحيد الذي يملأ بسرعة 200 جيجابايت SSD.
هذه هي لوحة القيادة القياسية لأداء خادم Zabbix.
الرسم البياني الأزرق الأول هو عدد القيم في الثانية الواحدة. الرسم البياني الثاني على اليمين هو تحميل عمليات التجميع. والثالث هو تحميل عمليات التجميع الداخلية: مزامنة التاريخ و Housekeeper ، والتي كانت تعمل منذ فترة طويلة هنا.
الرسم البياني الرابع يوضح استخدام HistoryCache. هذا هو مخزن مؤقت قبل الإدراج في قاعدة البيانات. يوضح الرسم البياني الخامس الأخضر استخدام ValueCache ، أي عدد مرات دخول ValueCache لمشغلات عدة آلاف من القيم في الثانية الواحدة.
كيو. 50000 nvps
ثم قمت بزيادة الحمل إلى 50 ألف قيمة في الثانية على نفس الجهاز.
عند التحميل من مدبرة منزل ، تم تسجيل إدراج من 10 آلاف قيمة لمدة 2-3 ثوان.
مدبرة المنزل بدأت بالفعل في الحصول على الطريق.يوضح الرسم البياني الثالث أنه ، بشكل عام ، لا يزال تحميل الصيادون ومزامنات السجل عند 60٪. في الرسم البياني الرابع ، يبدأ HistoryCache بالفعل في التعبئة بشكل نشط للغاية أثناء عمل مدبرة المنزل. 20٪ ممتلئة - حوالي 0.5 جيجابايت.
كيو. 80000 nvps
ثم قمت بزيادة الحمل إلى 80 ألف قيمة في الثانية. هذه عبارة عن 400 ألف عنصر بيانات و 280 ألف عنصر تشغيل.
إدراج لتحميل ثلاثين مزامنة التاريخ بالفعل عالية جدا.أنا أيضا زيادة المعلمات المختلفة: مزامنة التاريخ ، مخابئ.
على أجهزتي ، زاد عبء مزامنة السجل إلى الحد الأقصى. HistoryCache مليئة بسرعة مع البيانات - البيانات للمعالجة المتراكمة في المخزن المؤقت.
طوال هذا الوقت شاهدت كيف تم استخدام المعالج وذاكرة الوصول العشوائي ومعلمات النظام الأخرى ، ووجدت أن استخدام القرص تم تعظيمه.
لقد حصلت على
أقصى استفادة من محرك الأقراص على هذا الجهاز وعلى هذا الجهاز الظاهري. في هذه الكثافة ، بدأ PostgreSQL في تفريغ البيانات بنشاط كبير ، ولم يعد القرص لديه وقت للعمل على الكتابة والقراءة.
الخادم الثاني
أخذت خادمًا آخر يحتوي بالفعل على 48 معالجات و 128 جيجابايت من ذاكرة الوصول العشوائي. قم بضبطه - قم بإعداد 60 مزامنة للتاريخ ، وحقق أداء مقبولًا.
في الواقع ، هذا هو بالفعل حد الأداء حيث يجب القيام بشيء ما.
TimescaleDB. 80000 nvps
مهمتي الرئيسية هي اختبار قدرات TimescaleDB من تحميل Zabbix. 80 ألف قيمة في الثانية هي الكثير ، وتكرار جمع المقاييس (باستثناء ياندكس ، بالطبع) و "الإعداد" كبير إلى حد ما.
هناك فشل في كل مخطط - وهذا مجرد ترحيل البيانات. بعد حالات الفشل في خادم Zabbix ، تغير ملف تعريف مزامنة السجل كثيرًا - فقد انخفض ثلاث مرات.
TimescaleDB يسمح لك بإدراج البيانات بشكل أسرع ثلاث مرات تقريباً واستخدام أقل HistoryCache.
وفقًا لذلك ، سيتم تسليم البيانات إليك في الوقت المناسب.
TimescaleDB. 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 نوفمبر ، ولكن لا يزال من الممكن تقديم عمليات تخفيف .
اشترك في نشرتنا الإخبارية والبرقيات ، حيث نكشف عن رقائق المؤتمر القادم ، وتعرف على كيفية الحصول على أقصى استفادة منه.