سننظر في كيفية عمل Zabbix مع قاعدة بيانات TimescaleDB كخلفية. سنوضح لك كيفية البدء من نقطة الصفر وكيفية الترحيل من PostgreSQL. كما نقدم اختبارات أداء مقارنة للتكوينين.
HighLoad ++ سيبيريا 2019. قاعة تومسك. 24 يونيو ، 16:00. الملخصات و . سيعقد مؤتمر HighLoad ++ القادم في 6 و 7 أبريل 2020 في سان بطرسبرج. التفاصيل والتذاكر .
أندري غوشين (يُشار إليه فيما بعد - AG): - أنا مهندس دعم فني في ZABBIX (يشار إليه فيما يلي باسم "Zabbix") ، مدرب. أعمل في الدعم الفني منذ أكثر من 6 سنوات ولدي خبرة مباشرة في الأداء. سأتحدث اليوم عن الأداء الذي يمكن أن يقدمه TimescaleDB عند مقارنته بـ PostgreSQL 10. أيضًا جزء تمهيدي حول كيفية عمله بشكل عام.
أهم تحديات الأداء: من جمع البيانات إلى تنقية البيانات
بادئ ذي بدء ، هناك بعض تحديات الأداء التي يواجهها كل نظام مراقبة. يتمثل التحدي الأول في الأداء في جمع البيانات ومعالجتها بسرعة.
يجب أن يتلقى نظام المراقبة الجيد جميع البيانات على الفور وفي الوقت المناسب ، ومعالجتها وفقًا لتعبيرات المشغل ، أي معالجتها وفقًا لبعض المعايير (يختلف هذا في الأنظمة المختلفة) وحفظها في قاعدة البيانات من أجل استخدام هذه البيانات في المستقبل.
التحدي الثاني في الأداء هو تخزين التاريخ. قم بالتخزين في قاعدة بيانات في كثير من الأحيان ولديك وصول سريع وسهل إلى هذه المقاييس التي تم جمعها على مدار فترة زمنية. الشيء الأكثر أهمية هو أن هذه البيانات يجب أن تكون ملائمة لتلقيها ، واستخدامها في التقارير ، والرسوم البيانية ، والمحفزات ، في نوع من القيم الحدية ، للتنبيهات ، وما إلى ذلك.
التحدي الثالث في الأداء هو تنظيف السجل ، أي عندما يكون لديك يوم لا تحتاج فيه إلى تخزين بعض المقاييس التفصيلية التي تم جمعها على مدار 5 سنوات (حتى أشهر أو شهرين). تمت إزالة بعض عُقد الشبكة ، أو لم تعد هناك حاجة للمقاييس لبعض المضيفين لأنها قديمة بالفعل ولم تعد مجمعة. كل هذا يحتاج للتنظيف حتى لا تنمو قاعدة البيانات الخاصة بك إلى حجم كبير. وبشكل عام ، يعد مسح السجل غالبًا اختبارًا جادًا للتخزين - غالبًا ما يؤثر على الأداء كثيرًا.
كيف تحل مشاكل التخزين المؤقت؟
سأتحدث الآن على وجه التحديد عن Zabbix. في Zabbix ، يتم حل المكالمات الأولى والثانية باستخدام التخزين المؤقت.
جمع البيانات ومعالجتها - نستخدم ذاكرة الوصول العشوائي لتخزين كل هذه البيانات. سيتم الآن مناقشة هذه البيانات بمزيد من التفصيل.
يوجد أيضًا على جانب قاعدة البيانات تخزين مؤقت محدد للتحديدات الرئيسية - للرسوم البيانية ، وأشياء أخرى.
التخزين المؤقت على جانب خادم Zabbix نفسه: لدينا ConfigurationCache و ValueCache و HistoryCache و TrendsCache. ما هذا؟
ConfigurationCache هي ذاكرة التخزين المؤقت الرئيسية حيث نقوم بتخزين المقاييس والمضيفين والعناصر والمشغلات ؛ كل ما تحتاجه لمعالجة المعالجة المسبقة ، وجمع البيانات ، ومن أي المضيفين سيجمعون ، وبأي تردد. يتم تخزين كل هذا في ConfigurationCache حتى لا تذهب إلى قاعدة البيانات ، وليس لإنشاء طلبات غير ضرورية. بعد بدء تشغيل الخادم ، نقوم بتحديث ذاكرة التخزين المؤقت هذه (إنشائها) وتحديثها بشكل دوري (حسب إعدادات التكوين).
التخزين المؤقت في Zabbix. جمع البيانات
هنا المخطط كبير جدًا:
العوامل الرئيسية في المخطط هي هذه المجمعات:
هذه هي عمليات البناء نفسها ، "المستطلعون" المختلفون المسؤولون عن أنواع مختلفة من البنيات. يقومون بجمع البيانات عبر icmp و ipmi باستخدام بروتوكولات مختلفة ونقلها جميعًا إلى المعالجة المسبقة.
المعالجة المسبقة لذاكرة التخزين المؤقت
أيضًا ، إذا قمنا بحساب عناصر البيانات (أولئك الذين هم على دراية بـ Zabbix يعرفون) ، أي عناصر بيانات التجميع المحسوبة ، فإننا نأخذها مباشرة من ValueCache. كيف يتم ملؤها ، سأقول لاحقًا. كل هؤلاء الجامعين يستخدمون ConfigurationCache لتلقي وظائفهم ثم نقلها إلى المعالجة المسبقة.
تستخدم المعالجة المسبقة أيضًا ConfigurationCache للحصول على خطوات المعالجة المسبقة ، وتعالج هذه البيانات بطريقة مختلفة. بدءًا من الإصدار 4.2 ، قمنا بنقله إلى وكيل. هذا مريح للغاية ، لأن المعالجة المسبقة نفسها عملية ثقيلة نوعًا ما. وإذا كان لديك Zabbix كبير جدًا ، مع عدد كبير من عناصر البيانات وتكرار تجميع عالٍ ، فهذا يسهل العمل بشكل كبير.
وفقًا لذلك ، بعد أن قمنا بمعالجة هذه البيانات بطريقة ما باستخدام المعالجة المسبقة ، نقوم بحفظها في HistoryCache من أجل معالجتها بشكل أكبر. هذا يكمل جمع البيانات. ننتقل إلى العملية الرئيسية.
عملية مزامنة التاريخ
العملية الرئيسية في Zabbix (لأنها بنية متجانسة) هي مزامنة التاريخ. هذه هي العملية الرئيسية التي تتعامل مع المعالجة الذرية لكل عنصر من عناصر البيانات ، أي كل قيمة:
- تأتي القيمة (يأخذها من HistoryCache) ؛
- يتحقق في مزامنة التكوين: إذا كان هناك أي مشغلات للحساب - يحسبها ؛
إذا كان موجودًا ، يُنشئ أحداثًا ، ويُنشئ تصعيدًا لإنشاء تنبيه ، إذا لزم الأمر عن طريق التكوين ؛ - يكتب مشغلات لمزيد من المعالجة والتجميع ؛ إذا كنت تقوم بالتجميع على مدار الساعة الماضية وما إلى ذلك ، فستتذكر ValueCache هذه القيمة حتى لا تنتقل إلى جدول المحفوظات ؛ وبالتالي ، يتم تعبئة ValueCache بالبيانات الضرورية اللازمة لتقييم المشغلات والعناصر المحسوبة وما إلى ذلك ؛
- ثم يقوم مزامن السجل بكتابة جميع البيانات إلى قاعدة البيانات ؛
- تقوم قاعدة البيانات بكتابتها على القرص - وهذا يكمل المعالجة.
قاعدة البيانات. التخزين المؤقت
على جانب قاعدة البيانات ، عندما تريد عرض المخططات أو نوع من تقارير الأحداث ، فهناك العديد من ذاكرات التخزين المؤقت. لكن في إطار هذا التقرير لن أتحدث عنها.
بالنسبة لـ MySQL ، يوجد Innodb_buffer_pool ، ومجموعة من ذاكرات التخزين المؤقت المختلفة التي يمكن تهيئتها أيضًا.
لكن هذه هي أهمها:
- المشتركة_المخزن
- حجم_ذاكرة التخزين المؤقت الفعالة ؛
- بركة مشتركه.
لقد أحضرت لجميع قواعد البيانات أن هناك ذاكرة تخزين مؤقت معينة تسمح لك بالاحتفاظ بالبيانات المطلوبة غالبًا للاستعلامات في ذاكرة الوصول العشوائي. لديهم تقنياتهم الخاصة لهذا الغرض.
حول أداء قاعدة البيانات
وفقًا لذلك ، هناك بيئة تنافسية ، أي أن خادم Zabbix يجمع البيانات ويكتبها. عند إعادة التشغيل ، يقرأ أيضًا من السجل لملء ValueCache وما إلى ذلك. هناك يمكنك الحصول على نصوص وتقارير تستخدم Zabbix-API ، والتي تم إنشاؤها على أساس واجهة الويب. "Zabbix" - API يدخل قاعدة البيانات ويتلقى البيانات اللازمة للحصول على الرسوم البيانية والتقارير أو نوع من قائمة الأحداث ، المشاكل الأخيرة.
يعد Grafana أحد الحلول المرئية الشائعة جدًا ، والتي يستخدمها مستخدمونا. قادرة على الدخول مباشرة من خلال "Zabbix" -API ومن خلال قاعدة البيانات. كما أنه يخلق بعض المنافسة للحصول على البيانات: هناك حاجة إلى ضبط أفضل لقاعدة البيانات لمطابقة التسليم السريع للنتائج والاختبار.
تاريخ المقاصة. لدى Zabbix مدبرة منزل
المكالمة الثالثة التي يتم استخدامها في Zabbix هي مسح التاريخ مع مدبرة المنزل. يحترم Housekeeper جميع الإعدادات ، أي في عناصر البيانات الخاصة بنا ، يُشار إلى مقدار التخزين (بالأيام) ، ومدة تخزين الاتجاهات ، وديناميكيات التغييرات.
لم أتحدث عن TrendCash ، الذي نحسبه سريعًا: تأتي البيانات ، ونجمعها في ساعة واحدة (معظمها أرقام الساعة الأخيرة) ، المتوسط / الحد الأدنى للمبلغ ونكتبها مرة كل ساعة في جدول الاتجاه ("الاتجاهات"). تبدأ مدبرة المنزل وتحذف البيانات من قاعدة البيانات بالاختيارات المعتادة ، وهي ليست فعالة دائمًا.
كيف نفهم أنه غير فعال؟ يمكنك رؤية الصورة التالية على الرسوم البيانية لأداء العمليات الداخلية:
مزامنة السجل مشغول باستمرار (رسم بياني أحمر). والرسم البياني "الأحمر" الذي يظهر في الأعلى. هذا هو "Housekeeper" الذي يعمل وينتظر قاعدة البيانات لحذف جميع الصفوف التي عينتها.
لنأخذ بعض معرف العنصر: تحتاج إلى حذف آخر 5 آلاف ؛ بالطبع ، عن طريق الفهارس. لكن عادةً ما تكون مجموعة البيانات كبيرة جدًا - لا تزال قاعدة البيانات تقرأها من القرص وتضعها في ذاكرة التخزين المؤقت ، وهذه عملية مكلفة للغاية لقاعدة البيانات. اعتمادًا على حجمه ، يمكن أن يؤدي ذلك إلى مشاكل معينة في الأداء.
يمكنك تعطيل Housekeeper بطريقة بسيطة - لدينا واجهة ويب مألوفة للجميع. الإعداد في الإدارة العامة (إعدادات "مدبرة المنزل") نقوم بتعطيل التدبير المنزلي الداخلي للتاريخ الداخلي والاتجاهات. وفقًا لذلك ، لم يعد Housekeeper يدير هذا:
ما الذي يمكن عمله بعد ذلك؟ لقد قمت بإيقاف تشغيله ، الرسوم البيانية الخاصة بك قد توقفت ... ما هي المشاكل التي يمكن أن تكون هناك في هذه الحالة؟ ما الذي يمكن أن يساعد؟
التقسيم (التقسيم)
يتم تكوين هذا عادةً في كل قاعدة بيانات علائقية أدرجتها بطريقة مختلفة. تمتلك MySQL تقنيتها الخاصة. لكن بشكل عام ، هما متشابهان جدًا عندما يتعلق الأمر بـ PostgreSQL 10 و MySQL. بالطبع ، هناك الكثير من الاختلافات الداخلية ، وكيف يتم تنفيذها بالكامل وكيف تؤثر جميعها على الأداء. ولكن بشكل عام ، غالبًا ما يؤدي إنشاء قسم جديد إلى حدوث مشكلات معينة.
اعتمادًا على الإعداد الخاص بك (مقدار البيانات التي تنشئها في يوم واحد) ، عادةً ما يتم تعيين الحد الأدنى - وهذا هو يوم واحد / قسم ، وبالنسبة إلى "الاتجاهات" ، تكون ديناميكيات التغييرات شهرًا واحدًا / قسم جديد. قد يتغير هذا إذا كان لديك إعداد كبير جدًا.
دعنا نتحدث عن حجم الإعداد على الفور: ما يصل إلى 5 آلاف قيمة جديدة في الثانية (ما يسمى nvps) - سيعتبر هذا "إعدادًا" صغيرًا. متوسط - من 5 إلى 25 ألف قيمة في الثانية. كل شيء أعلاه هو بالفعل عمليات تثبيت كبيرة وكبيرة جدًا تتطلب ضبطًا دقيقًا للغاية لقاعدة البيانات نفسها.
في عمليات التثبيت الكبيرة جدًا ، قد لا يكون يوم واحد هو الأمثل. لقد رأيت شخصيًا في أقسام MySQL 1 غيغابايت يوميًا (وقد يكون هناك المزيد). هذه كمية كبيرة جدًا من البيانات ، والتي يمكن أن تؤدي إلى بعض المشاكل. يجب تقليله.
لماذا التقسيم ضروري؟
أعتقد أن ما يفعله التقسيم هو تقسيم الجدول. غالبًا ما تكون هذه ملفات منفصلة على القرص وطلبات الامتداد. يختار قسمًا واحدًا على النحو الأمثل إذا تم تضمينه في التقسيم العادي.
بالنسبة إلى Zabbix ، على وجه الخصوص ، يتم استخدامه حسب النطاق ، حسب النطاق ، أي أننا نستخدم طابعًا زمنيًا (رقم منتظم ، الوقت منذ بداية العصر). أنت تحدد بداية اليوم / نهاية اليوم وهذا هو القسم. وفقًا لذلك ، إذا كنت تصل إلى البيانات منذ يومين ، فسيتم تحديدها جميعًا من قاعدة البيانات بشكل أسرع ، لأنك تحتاج فقط إلى ملف واحد ليتم تحميله في ذاكرة التخزين المؤقت وعرضه (بدلاً من جدول كبير).
تعمل العديد من قواعد البيانات أيضًا على تسريع عملية الإدراج (الإدراج في جدول تابع واحد). بينما أتحدث بشكل تجريدي ، إلا أنه ممكن أيضًا. يساعد التقسيم في كثير من الأحيان.
Elasticsearch لـ NoSQL
مؤخرًا ، في الإصدار 3.4 ، طبقنا حلاً لـ NoSQL. تمت إضافة القدرة على الكتابة إلى Elasticsearch. يمكنك كتابة بعض الأنواع المنفصلة: اختر - إما كتابة الأرقام أو بعض العلامات ؛ لدينا نص سلسلة ، يمكنك كتابة السجلات في Elasticsearch ... وفقًا لذلك ، ستصل واجهة الويب أيضًا إلى Elasticsearch. هذا يعمل بشكل جيد في بعض الحالات ، ولكن في الوقت الحالي يمكن استخدامه.
مقياس الوقت ب. Hypertables
بالنسبة لـ 4.4.2 ، أولينا اهتمامًا لشيء واحد مثل TimescaleDB. ما هذا؟ هذا امتداد لـ Postgres ، أي أنه يحتوي على واجهة PostgreSQL أصلية. بالإضافة إلى ذلك ، يتيح لك هذا الامتداد العمل مع بيانات السلاسل الزمنية بكفاءة أكبر مع التقسيم التلقائي. ما يبدو عليه:
هذا قابل للضغط - يوجد شيء من هذا القبيل في مقياس الوقت. هذا ملف قابل للضغط تقوم بإنشائه ، ويحتوي على أجزاء. القطع عبارة عن أقسام ، هذه جداول فرعية ، إذا لم أكن مخطئًا. إنها فعالة حقًا.
مقياس الوقت DB و PostgreSQL
كما تؤكد الشركات المصنعة لـ TimescaleDB ، فإنها تستخدم خوارزمية معالجة استعلام أكثر دقة ، ولا سيما الإدخالات ، والتي تتيح لك الحصول على أداء ثابت تقريبًا مع زيادة حجم إدراج مجموعة البيانات. أي بعد 200 مليون سطر ، يبدأ Postgres في التدهور بشكل سيئ للغاية ويفقد الأداء حرفيًا إلى الصفر ، بينما يسمح لك مقياس الوقت بإدراج الإدخالات بأكبر قدر ممكن من الكفاءة مع أي كمية من البيانات.
كيفية تثبيت TimescaleDB؟ كل شيء بسيط!
إنه موجود في الوثائق ، موصوف - يمكنك تثبيته من الحزم لأي ... يعتمد ذلك على حزم Postgres الرسمية. يمكن تجميعها يدويًا. لقد حدث أن اضطررت إلى تجميع البيانات من أجل DB.
في Zabbix ، نقوم ببساطة بتنشيط الامتداد. أعتقد أن أولئك الذين استخدموا Extention في Postgres ... ما عليك سوى تنشيط Extention ، وإنشاءه لقاعدة بيانات Zabbix التي تستخدمها.
والخطوة الأخيرة ...
مقياس الوقت ب. ترحيل جداول المحفوظات
تحتاج إلى إنشاء ملف. هناك وظيفة خاصة لهذا - إنشاء ضغط عالي. في ذلك ، باعتباره المعلمة الأولى ، حدد الجدول المطلوب في قاعدة البيانات هذه (والتي تحتاج إلى إنشاء ملف قابل للضغط عليه).
الحقل المراد إنشاؤه و chunk_time_interval (هذا هو الفاصل الزمني للقطع (يجب استخدام الأقسام). 86 هو يوم واحد.
معلمة migrate_data: إذا قمت باللصق إلى true ، فسيؤدي ذلك إلى ترحيل جميع البيانات الحالية إلى أجزاء تم إنشاؤها مسبقًا.
لقد استخدمت migrate_data بنفسي - يستغرق الأمر وقتًا مناسبًا ، اعتمادًا على حجم قاعدة البيانات الخاصة بك. كان لدي أكثر من تيرابايت - استغرق الأمر أكثر من ساعة في الإنشاء. في بعض الحالات ، عند الاختبار ، قمت بحذف البيانات التاريخية للنص (history_text) والسلسلة (history_str) حتى لا يتم نقلها - لم تكن مثيرة للاهتمام حقًا بالنسبة لي.
ونجري التحديث الأخير في db_extention: قمنا بتعيين مقياس الوقت بحيث تدرك قاعدة البيانات ، وعلى وجه الخصوص ، Zabbix أن هناك db_extention. يقوم بتنشيطه ويستخدم الصيغة الصحيحة والاستعلامات لقاعدة البيانات ، باستخدام بالفعل تلك "الميزات" الضرورية لـ TimescaleDB.
Конфигурация сервера
لقد استخدمت خادمين. الخادم الأول عبارة عن جهاز ظاهري صغير إلى حد ما ، 20 معالجًا ، 16 جيجا بايت من ذاكرة الوصول العشوائي. قم بإعداد Postgres 10.8 عليه:
كان نظام التشغيل دبيان ، وكان نظام الملفات xfs. لقد قمت بإجراء الحد الأدنى من الإعدادات لاستخدام قاعدة البيانات هذه ، مطروحًا منها ما سيستخدمه Zabbix نفسه. على نفس الجهاز كان هناك خادم Zabbix و PostgreSQL ووكلاء تحميل.
لقد استخدمت 50 عاملًا نشطًا يستخدمون LoadableModule لتوليد نتائج مختلفة بسرعة. لقد كانوا هم من أنشأوا السلاسل والأرقام وما إلى ذلك. لقد ملأت قاعدة البيانات بالكثير من البيانات. في البداية ، احتوى التكوين على 5 آلاف عنصر بيانات لكل مضيف ، واحتوى كل عنصر بيانات تقريبًا على مشغل - من أجل أن يكون هذا إعدادًا حقيقيًا. في بعض الأحيان يستغرق الأمر أكثر من مشغل لاستخدامه.
لقد قمت بتنظيم الفاصل الزمني للتحديث ، والتحميل نفسه ليس فقط باستخدام 50 وكيلًا (إضافة المزيد) ، ولكن أيضًا باستخدام عناصر البيانات الديناميكية وتقليل الفاصل الزمني للتحديث إلى 4 ثوانٍ.
تجربة أداء. PostgreSQL: 36 ألف NVPs
التشغيل الأول ، الإعداد الأول الذي أجريته كان على PostreSQL 10 الخالص على هذا الجهاز (35 ألف قيمة في الثانية). بشكل عام ، كما ترى على الشاشة ، يستغرق إدخال البيانات أجزاء من الثانية - كل شيء على ما يرام وسريع ، محركات أقراص SSD (200 جيجابايت). الشيء الوحيد هو أن 20 جيجا بايت تمتلئ بالسرعة الكافية.
سيكون هناك الكثير من هذه الرسوم البيانية في المستقبل. هذه هي لوحة الأداء القياسية لخادم Zabbix.
الرسم البياني الأول هو عدد القيم في الثانية (الأزرق ، أعلى اليسار) ، 35 ألف قيمة في هذه الحالة. هذا (المركز العلوي) يقوم بتحميل عمليات البناء ، وهذا (أعلى اليمين) يقوم بتحميل العمليات الداخلية بالضبط: مزامنات التاريخ ومدبرة المنزل ، والتي تعمل هنا (أسفل الوسط) منذ بعض الوقت.
يوضح هذا الرسم البياني (أسفل الوسط) استخدام ValueCache - عدد مرات الوصول إلى ValueCache للمشغلات (عدة آلاف من القيم في الثانية). الرسم البياني المهم الآخر هو الرسم الرابع (أسفل اليسار) ، والذي يوضح استخدام HistoryCache الذي تحدثت عنه ، وهو عبارة عن مخزن مؤقت قبل إدراجه في قاعدة البيانات.
تجربة أداء. PostgreSQL: 50 ألف NVPs
بعد ذلك ، قمت بزيادة الحمل إلى 50 ألف قيمة في الثانية على نفس الجهاز. عند التحميل بواسطة Housekeeper ، تم بالفعل تسجيل 10 آلاف قيمة في 2-3 ثوانٍ مع الحساب. والذي ، في الواقع ، يظهر في لقطة الشاشة التالية:
بدأت مدبرة المنزل بالفعل في الوقوف في طريقها ، لكن الاستخدام العام لصيد الحفار التاريخي لا يزال عند 60٪ (الرسم البياني الثالث ، أعلى اليمين). HistoryCache بالفعل أثناء تشغيل "مدبرة المنزل" يبدأ في ملء (أسفل اليسار). كان حوالي نصف غيغابايت ، 20٪ ممتلئ.
تجربة أداء. PostgreSQL: 80 ألف NVPs
زيادة أخرى إلى 80 ألف قيمة في الثانية:
كان حوالي 400 ألف عنصر بيانات ، 280 ألف مشغل. الإدخال ، كما ترون ، من حيث تحميل غطاسات محفوظات التحميل (كان هناك 30 منهم) كان مرتفعًا بالفعل. ثم قمت بزيادة المعلمات المختلفة: غرق التاريخ ، ذاكرة التخزين المؤقت ... على هذا الجهاز ، بدأ تحميل أحواض السجل في الزيادة إلى الحد الأقصى ، تقريبًا "إلى الرف" - وفقًا لذلك ، ذهب HistoryCache إلى حمل كبير جدًا:
طوال هذا الوقت كنت أراقب جميع معلمات النظام (كيفية استخدام المعالج ، ذاكرة الوصول العشوائي) ووجدت أن استخدام القرص كان بحد أقصى - لقد حققت السعة القصوى لهذا القرص على هذا الجهاز ، في هذا الجهاز الظاهري. بدأ Postgres في تفريغ البيانات بنشاط كبير بمثل هذه الكثافة ، ولم يعد للقرص وقت للكتابة والقراءة ...
أخذت خادمًا آخر يحتوي بالفعل على 48 معالجًا 128 جيجا بايت من ذاكرة الوصول العشوائي:
كما أنني "ضبطته" - لقد قمت بتثبيت مزامنة السجل (60 قطعة) وحققت أداءً مقبولاً. في الواقع ، نحن لسنا "في الرف" ، ولكن ربما يكون هذا هو حد الإنتاجية ، حيث من الضروري بالفعل القيام بشيء حيال ذلك.
تجربة أداء. DB: 80K NVPs
كانت مهمتي الرئيسية هي استخدام TimescaleDB. يظهر كل رسم بياني انخفاضًا:
هذه الإخفاقات هي مجرد ترحيل بيانات. بعد ذلك ، في خادم Zabbix ، تغير ملف تعريف التنزيل الخاص بأصحاب المحفوظات ، كما ترون ، كثيرًا. يسمح لك بإدخال البيانات أسرع بثلاث مرات تقريبًا واستخدام أقل لـ HistoryCache - وفقًا لذلك ، ستتلقى البيانات في الوقت المناسب. مرة أخرى ، 3 ألف قيمة في الثانية هي معدل مرتفع إلى حد ما (بالطبع ، ليس لـ Yandex). بشكل عام ، يعد هذا إعدادًا كبيرًا إلى حد ما ، مع خادم واحد.
معيار PostgreSQL: 120K NVPs
بعد ذلك قمت بزيادة قيمة عدد عناصر البيانات إلى نصف مليون وحصلت على قيمة محسوبة 125 ألف في الثانية:
وحصلت على هذه المخططات:
من حيث المبدأ ، يعد هذا إعدادًا عمليًا ، ويمكن أن يعمل لفترة طويلة جدًا. ولكن نظرًا لأن لدي قرصًا بسعة 1,5 تيرابايت فقط ، فقد قضيته في غضون يومين. الأهم من ذلك ، أنه تم إنشاء أقسام جديدة على TimescaleDB في نفس الوقت ، وكان هذا غير ملحوظ تمامًا بالنسبة للأداء ، وهو ما لا يمكن قوله عن MySQL.
عادة ما يتم إنشاء الأقسام في الليل ، لأن هذا يمنع الإدراج والعمل مع الجداول بشكل عام ، ويمكن أن يؤدي إلى تدهور الخدمة. في هذه الحالة ، لا! كانت المهمة الرئيسية هي اختبار قدرات TimescaleDB. اتضح مثل هذا الرقم: 120 ألف قيمة في الثانية.
هناك أيضًا أمثلة في "المجتمع":
قام الشخص أيضًا بتشغيل TimescaleDB وانخفض الحمل على استخدام io.weight على المعالج ؛ كما تم تقليل استخدام عناصر العملية الداخلية من خلال تضمين TimescaleDB. وهذه أقراص فطيرة عادية ، أي آلة افتراضية عادية على الأقراص العادية (وليس SSD)!
بالنسبة لبعض الإعدادات الصغيرة التي يحدها أداء القرص ، يبدو لي TimescaleDB أنه حل جيد جدًا. من الجيد الاستمرار في العمل قبل الترحيل إلى أجهزة قاعدة بيانات أسرع.
أدعوكم جميعًا إلى أحداثنا: مؤتمر - في موسكو ، قمة - في ريغا. استخدم قنواتنا - Telegram، forum، IRC. إذا كان لديك أي أسئلة ، تعال إلى مكتبنا ، يمكننا التحدث عن كل شيء.
أسئلة الجمهور
سؤال من الجمهور (يُشار إليه فيما يلي - أ): - إذا كان إعداد TimescaleDB سهلًا جدًا ، ويعطي دفعة قوية للأداء ، فربما يجب استخدام هذا كأفضل ممارسة لإعداد Zabbix مع Postgres؟ وهل هناك أي عيوب أو مساوئ لهذا الحل ، أو لا يزال ، إذا قررت أن أجعل Zabbix بنفسي ، يمكنني أخذ Postgres بأمان ، ووضع Timescale هناك على الفور ، واستخدامه وعدم التفكير في أي مشاكل؟
اي جي: - نعم ، أود أن أقول إنها توصية جيدة لاستخدام Postgres على الفور مع امتداد TimescaleDB. كما قلت ، هناك الكثير من المراجعات الجيدة ، على الرغم من حقيقة أن هذه "الميزة" تجريبية. لكن في الواقع تظهر الاختبارات أنه حل رائع (مع TimescaleDB) وأعتقد أنه سيتطور! نحن نراقب كيفية تطور هذا الامتداد وسنصحح ما هو مطلوب.
حتى أننا اعتمدنا على إحدى "ميزاتها" المعروفة أثناء التطوير: كان من الممكن العمل مع الأجزاء بشكل مختلف قليلاً هناك. ولكن بعد ذلك قاموا بقصها في الإصدار التالي ، ولم يعد علينا الاعتماد على هذا الرمز. أوصي باستخدام هذا الحل في العديد من الإعدادات. إذا كنت تستخدم MySQL ... للإعدادات المتوسطة ، فإن أي من الحلين يعمل بشكل جيد.
أ: - في أحدث الرسوم البيانية من المجتمع ، كان هناك رسم بياني مع "مدبرة المنزل":
واصل العمل. ماذا تفعل مدبرة المنزل مع TimescaleDB؟
اي جي: - الآن لا أستطيع الجزم - سألقي نظرة على الكود وأخبرك بمزيد من التفاصيل. يستخدم استعلامات TimescaleDB ليس لإزالة الأجزاء ، ولكن المجاميع بطريقة أو بأخرى. بينما لست مستعدًا للإجابة على هذا السؤال الفني. في المنصة اليوم أو غدا سنوضح.
أ: - لدي سؤال مشابه - حول أداء عملية الحذف في Timescale.
أ (إجابة من الجمهور): - عند حذف البيانات من جدول ، إذا قمت بذلك من خلال الحذف ، فأنت بحاجة إلى استعراض الجدول - حذف وتنظيف ووضع علامة على كل شيء للفراغ في المستقبل. في Timescale ، نظرًا لأن لديك قطعًا ، يمكنك إسقاطها. بشكل تقريبي ، ما عليك سوى إخبار الملف الموجود في البيانات الضخمة: "حذف!"
يدرك المقياس الزمني ببساطة أنه لا يوجد مثل هذا الجزء بعد الآن. ونظرًا لأنه يتكامل مع مخطط الاستعلام ، فإنه يربط بين ظروفك في عمليات محددة أو في عمليات أخرى ويدرك على الفور أن هذا الجزء لم يعد موجودًا - "لن أذهب إلى هناك مرة أخرى!" (البيانات غير متوفرة). هذا كل شئ! بمعنى ، يتم استبدال فحص الجدول بحذف ملف ثنائي ، لذلك فهو سريع.
أ: - لقد تطرقنا بالفعل في الموضوع وليس SQL. بقدر ما أفهم ، لا يحتاج Zabbix حقًا إلى تعديل البيانات ، وكل هذا يشبه السجل. هل من الممكن استخدام قواعد بيانات متخصصة لا تستطيع تغيير بياناتها ، ولكن في نفس الوقت حفظ ، تراكم ، رد أسرع بكثير - Clickhouse ، على سبيل المثال ، شيء على شكل كافكا؟ .. كافكا هو أيضًا سجل! هل من الممكن دمجهم بطريقة أو بأخرى؟
اي جي: - يمكن أن يتم التفريغ. لدينا "ميزة" معينة منذ الإصدار 3.4: يمكنك كتابة جميع الملفات التاريخية والأحداث وكل شيء آخر في الملفات ؛ ثم أرسل بعض المعالج إلى أي قاعدة بيانات أخرى. في الواقع ، يقوم العديد من الأشخاص بإعادة العمل والكتابة مباشرة إلى قاعدة البيانات. أثناء التنقل ، يكتب عمال التاريخ كل هذا إلى الملفات ، ويقومون بتدوير هذه الملفات ، وما إلى ذلك ، ويمكنك نقل هذا إلى Clickhouse. لا أستطيع أن أقول ما هي الخطط ، ولكن ربما سيستمر المزيد من الدعم لحلول NoSQL (مثل Clickhouse).
أ: - بشكل عام ، اتضح أنه يمكنك التخلص تمامًا من postgres؟
اي جي: - بالطبع أصعب جزء في Zabbix هو الجداول التاريخية التي تخلق معظم المشاكل والأحداث. في هذه الحالة ، إذا لم تقم بتخزين الأحداث لفترة طويلة وقمت بتخزين السجل مع الاتجاهات في بعض وحدات التخزين السريعة الأخرى ، فعندئذ بشكل عام ، أعتقد أنه لن تكون هناك مشاكل.
أ: - هل يمكنك تقدير مدى سرعة عمل كل شيء إذا قمت بالتبديل إلى Clickhouse ، على سبيل المثال؟
اي جي: - أنا لم أختبره. أعتقد أنه يمكن تحقيق نفس الأرقام على الأقل بكل بساطة ، بالنظر إلى أن Clickhouse لها واجهتها الخاصة ، لكن لا يمكنني الجزم بذلك. من الأفضل اختباره. كل هذا يتوقف على التكوين: عدد المضيفين لديك وما إلى ذلك. الإدراج شيء ، لكنك تحتاج أيضًا إلى أخذ هذه البيانات - Grafana أو أي شيء آخر.
أ: - أي أننا نتحدث عن معركة متساوية ، وليس عن الميزة الكبيرة لقواعد البيانات السريعة هذه؟
اي جي: - أعتقد أنه عندما نتكامل ، ستكون هناك اختبارات أكثر دقة.
أ: أين ذهب RRD القديم الجيد؟ ما الذي جعلك تتحول إلى قواعد بيانات SQL؟ في البداية ، تم جمع جميع المقاييس على RRD.
اي جي: - في "Zabbix" RRD ، ربما في نسخة قديمة جدًا. لطالما كانت هناك قواعد بيانات SQL - وهي طريقة كلاسيكية. الأسلوب الكلاسيكي هو MySQL و PostgreSQL (وهما موجودان منذ فترة طويلة جدًا). لم نستخدم أبدًا واجهة مشتركة لقواعد بيانات SQL و RRD.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com