🥇عملکرد بالا و پارتیشن بندی بومی: Zabbix با پشتیبانی TimescaleDB

Zabbix یک سیستم مانیتورینگ است. مانند هر سیستم دیگری، این سیستم با سه مشکل اصلی همه سیستم های نظارتی مواجه است: جمع آوری و پردازش داده ها، ذخیره تاریخ و پاکسازی آن.

مراحل دریافت، پردازش و ثبت داده ها زمان بر است. زیاد نیست، اما برای یک سیستم بزرگ، این می تواند منجر به تاخیرهای زیادی شود. مشکل ذخیره سازی مربوط به دسترسی به اطلاعات است. آنها برای گزارش ها، بررسی ها و محرک ها استفاده می شوند. تأخیر در دسترسی به داده ها نیز بر عملکرد تأثیر می گذارد. هنگامی که پایگاه داده رشد می کند، داده های نامربوط باید حذف شوند. حذف یک عملیات سنگین است که برخی منابع را نیز می خورد.

مشکلات جمع آوری و تاخیر ذخیره سازی در Zabbix با کش حل می شوند: چندین نوع کش، کش در پایگاه داده. برای حل مشکل سوم، کش کردن مناسب نیست، بنابراین TimescaleDB در Zabbix استفاده شد. در مورد آن خواهد گفت آندری گوشچین - مهندس پشتیبانی فنی Zabbix SIA. آندری بیش از 6 سال است که از Zabbix حمایت می کند و مستقیماً در اجرا نقش دارد.

TimescaleDB چگونه کار می کند، چه عملکردی در مقایسه با PostgreSQL معمولی می تواند داشته باشد؟ Zabbix چه نقشی در TimescaleDB بازی می کند؟ چگونه از ابتدا شروع کنیم و چگونه از PostgreSQL مهاجرت کنیم و کدام عملکرد پیکربندی بهتر است؟ همه اینها زیر برش است.

چالش های عملکرد

هر سیستم نظارتی با چالش های عملکردی خاصی مواجه است. من در مورد سه مورد از آنها صحبت خواهم کرد: جمع آوری و پردازش داده ها، ذخیره سازی، پاکسازی تاریخ.

جمع آوری و پردازش سریع داده ها. یک سیستم مانیتورینگ خوب باید به سرعت تمام داده ها را دریافت کند و آنها را بر اساس عبارات ماشه پردازش کند - طبق معیارهای خودش. پس از پردازش، سیستم نیز باید به سرعت این داده ها را در پایگاه داده ذخیره کند تا بعداً از آن استفاده کند.

ذخیره سازی تاریخچه یک سیستم نظارت خوب باید تاریخچه را در یک پایگاه داده ذخیره کند و دسترسی آسان به معیارها را فراهم کند. تاریخچه برای استفاده در گزارش‌ها، نمودارها، محرک‌ها، آستانه‌ها و موارد هشدار محاسبه‌شده مورد نیاز است.

پاک کردن تاریخچه گاهی اوقات روزی فرا می رسد که نیازی به ذخیره معیارها ندارید. چرا به داده‌هایی نیاز دارید که 5 سال پیش، یک یا دو ماه جمع‌آوری شده‌اند: برخی از گره‌ها حذف شده‌اند، برخی از میزبان‌ها یا معیارها دیگر مورد نیاز نیستند، زیرا قدیمی هستند و دیگر جمع‌آوری نمی‌شوند. یک سیستم مانیتورینگ خوب باید داده های تاریخی را ذخیره کند و هر از چند گاهی آن ها را حذف کند تا پایگاه داده رشد نکند.

پاک کردن داده‌های قدیمی یک مسئله پیچیده است که تأثیر زیادی بر عملکرد پایگاه داده دارد.

ذخیره در Zabbix

در Zabbix، تماس های اول و دوم با استفاده از کش حل می شوند. RAM برای جمع آوری و پردازش داده ها استفاده می شود. برای ذخیره سازی - تاریخچه در محرک ها، نمودارها و موارد محاسبه شده. در سمت DB، مقداری کش برای انتخاب های اساسی، مانند نمودارها وجود دارد.

ذخیره سازی در کنار خود سرور Zabbix به شرح زیر است:

ConfigurationCache;
ValueCache;
HistoryCache;
TrendsCache.

جزئیات بیشتری را در نظر بگیرید.

ConfigurationCache

این حافظه پنهان اصلی است که در آن متریک ها، میزبان ها، آیتم های داده، محرک ها را ذخیره می کنیم - همه چیزهایی که برای PreProcessing و برای جمع آوری داده ها لازم است.

همه اینها در ConfigurationCache ذخیره می شود تا پرس و جوهای غیر ضروری در پایگاه داده ایجاد نشود. پس از راه اندازی سرور، ما این کش را به روز می کنیم، پیکربندی ها را ایجاد و به صورت دوره ای به روز می کنیم.

جمع آوری داده ها

این طرح بسیار بزرگ است، اما نکته اصلی در آن است کلکسیونرها. اینها "گردشگرها" مختلف هستند - فرآیندهای مونتاژ. آنها مسئول انواع مختلف مونتاژ هستند: آنها داده ها را از طریق SNMP، IPMI جمع آوری می کنند و همه آنها را به PreProcessing منتقل می کنند.

جمع کننده ها به رنگ نارنجی دایره شده اند.

Zabbix موارد تجمیع مورد نیاز برای تجمیع چک ها را محاسبه کرده است. اگر آنها را داشته باشیم، داده ها را مستقیماً از ValueCache می گیریم.

پیش پردازش History Cache

همه جمع کننده ها از ConfigurationCache برای دریافت کارها استفاده می کنند. سپس آنها را به PreProcessing منتقل می کنند.

PreProcessing از ConfigurationCache برای دریافت مراحل PreProcessing استفاده می کند. این داده ها را به روش های مختلف پردازش می کند.

پس از پردازش داده ها با PreProcessing، آن را در HistoryCache ذخیره می کنیم تا پردازش شود. این جمع آوری داده ها را کامل می کند و ما به فرآیند اصلی در Zabbix می رویم - همگام سازی تاریخ، زیرا یک معماری یکپارچه است.

توجه: پیش پردازش یک عملیات نسبتاً سنگین است. از نسخه 4.2 به یک پروکسی منتقل شده است. اگر یک Zabbix بسیار بزرگ با تعداد اقلام و فرکانس جمع آوری زیاد دارید، پس این کار را بسیار آسان تر می کند.

حافظه پنهان ValueCache، تاریخچه و روندها

همگام سازی تاریخچه فرآیند اصلی است که هر عنصر داده، یعنی هر مقدار را به صورت اتمی پردازش می کند.

History syncer مقادیر را از HistoryCache می گیرد و پیکربندی را برای محاسبات بررسی می کند. اگر آنها هستند - محاسبه می کند.

همگام‌سازی تاریخچه رویدادی را ایجاد می‌کند، در صورت نیاز پیکربندی، برای ایجاد هشدارها تشدید می‌شود و ثبت می‌کند. اگر محرک هایی برای پردازش بیشتر وجود داشته باشد، این مقدار را در ValueCache به خاطر می آورد تا به جدول تاریخچه مراجعه نکند. به این ترتیب ValueCache با داده هایی که برای محاسبه محرک ها، آیتم های محاسبه شده مورد نیاز است پر می شود.

History syncer تمام داده ها را در پایگاه داده می نویسد و روی دیسک می نویسد. فرآیند پردازش در اینجا به پایان می رسد.

ذخیره DB

هنگامی که می خواهید به نمودارها یا گزارش رویدادها نگاه کنید، کش های مختلفی در سمت DB وجود دارد:

Innodb_buffer_pool در سمت MySQL؛
shared_buffers در سمت PostgreSQL؛
effective_cache_size در سمت اوراکل؛
shared_pool در سمت DB2

بسیاری از کش های دیگر نیز وجود دارند، اما این موارد اصلی برای همه پایگاه های داده هستند. آنها به شما این امکان را می دهند که داده هایی را که اغلب برای پرس و جو مورد نیاز است در RAM نگهداری کنید. آنها فناوری خود را برای این کار دارند.

عملکرد پایگاه داده حیاتی است

سرور Zabbix دائما در حال جمع آوری داده ها و نوشتن آنها است. هنگام راه اندازی مجدد، از تاریخچه برای پر کردن ValueCache نیز می خواند. اسکریپت ها و گزارش ها استفاده می کند Zabbix API، که بر اساس رابط وب ساخته شده است. Zabbix API به پایگاه داده دسترسی پیدا می کند و داده های لازم را برای نمودارها، گزارش ها، لیست رویدادها و مسائل اخیر بازیابی می کند.

برای تجسم - گرافانا. این یک راه حل محبوب در بین کاربران ما است. او می تواند مستقیماً درخواست ها را از طریق Zabbix API و به پایگاه داده ارسال کند و همزمانی مشخصی را برای به دست آوردن داده ها ایجاد کند. بنابراین، تنظیم دقیق و بهتر پایگاه داده برای مطابقت با تحویل سریع نتایج و آزمایش لازم است.

خانه دار

سومین چالش اجرایی در Zabbix، تمیز کردن تاریخ با Housekeeper است. به تمام تنظیمات احترام می گذارد - عناصر داده نشان می دهد که چه مدت پویایی تغییرات (روندها) در روز ذخیره می شود.

TrendsCache ما در پرواز محاسبه می کنیم. وقتی داده‌ها وارد می‌شوند، آن‌ها را در یک ساعت جمع‌آوری می‌کنیم و در جداول برای پویایی تغییرات روند قرار می‌دهیم.

Housekeeper اطلاعات را از پایگاه داده با "انتخاب"های معمول شروع و حذف می کند. این همیشه کارآمد نیست، که از نمودارهای عملکرد فرآیندهای داخلی قابل درک است.

نمودار قرمز نشان می دهد که همگام سازی History دائما مشغول است. نمودار نارنجی رنگ در بالا Housekeeper است که دائماً در حال اجرا است. منتظر می ماند تا پایگاه داده تمام ردیف هایی را که مشخص کرده است حذف کند.

چه زمانی باید Housekeeper را غیرفعال کنید؟ به عنوان مثال، یک "Item ID" وجود دارد و شما باید 5 هزار خط آخر را در یک زمان مشخص حذف کنید. البته این اتفاق توسط شاخص ها می افتد. اما معمولاً مجموعه داده بسیار بزرگ است و پایگاه داده همچنان از روی دیسک می خواند و آن را در حافظه پنهان قرار می دهد. این همیشه یک عملیات بسیار گران برای پایگاه داده است و بسته به اندازه پایگاه داده می تواند منجر به مشکلات عملکرد شود.

غیرفعال کردن خانه داری ساده است. در رابط وب، تنظیماتی در "Administration general" برای Housekeeper وجود دارد. خانه داری داخلی را برای تاریخچه روند داخلی غیرفعال کنید و دیگر این را کنترل نمی کند.

Housekeeper غیرفعال شده است، گرافیک‌ها یکسان شده است - چه مشکلاتی در این مورد می‌تواند باشد و چه چیزی می‌تواند به حل چالش عملکرد سوم کمک کند؟

پارتیشن بندی - پارتیشن بندی یا پارتیشن بندی

پارتیشن بندی معمولاً در هر پایگاه داده رابطه ای که من لیست کرده ام به روشی متفاوت پیکربندی می شود. هر کدام فناوری خاص خود را دارند، اما به طور کلی شبیه به هم هستند. ایجاد یک پارتیشن جدید اغلب منجر به مشکلات خاصی می شود.

به طور معمول، پارتیشن ها بسته به "تنظیم" - مقدار داده ای که در یک روز ایجاد می شود - پیکربندی می شوند. به عنوان یک قاعده، پارتیشن بندی در یک روز تنظیم می شود، این حداقل است. برای روندهای جدید پارتیشن - 1 ماه.

مقادیر ممکن است در مورد یک "تنظیم" بسیار بزرگ تغییر کنند. اگر یک "تنظیم" کوچک تا 5 nvps (مقادیر جدید در ثانیه) باشد، یک "تنظیم" متوسط از 000 تا 5 است، آنگاه یک "بزرگ" بالای 000 nvps است. اینها نصب های بزرگ و بسیار بزرگی هستند که نیاز به پیکربندی دقیق خود پایگاه داده دارند.

در تاسیسات بسیار بزرگ، یک روز ممکن است بهینه نباشد. من پارتیشن های MySQL 40 گیگابایت یا بیشتر در روز را دیده ام. این حجم بسیار زیادی از داده است که می تواند منجر به مشکلات شود و باید کاهش یابد.

چه چیزی به پارتیشن بندی می دهد؟

جداول پارتیشن بندی. اغلب اینها فایل های جداگانه روی دیسک هستند. طرح پرس و جو یک پارتیشن را بهینه تر انتخاب می کند. معمولاً پارتیشن بندی توسط محدوده استفاده می شود - این برای Zabbix نیز صادق است. ما در آنجا از "مهر زمانی" استفاده می کنیم - زمان از آغاز دوران. ما شماره های منظم داریم. شما شروع و پایان روز را تنظیم می کنید - این یک پارتیشن است.

حذف سریع - DELETE. یک فایل/زیر جدول انتخاب شده است، نه مجموعه ای از ردیف ها برای حذف.

به طور قابل توجهی سرعت نمونه گیری داده ها را افزایش می دهد SELECT - از یک یا چند پارتیشن استفاده می کند، نه کل جدول. اگر به داده‌های دو روزه دسترسی دارید، آن‌ها را سریع‌تر از پایگاه داده دریافت می‌کنید، زیرا فقط باید آن‌ها را در حافظه پنهان بارگیری کنید و فقط یک فایل را برگردانید، نه یک جدول بزرگ.

اغلب بسیاری از پایگاه های داده نیز سرعت می بخشند INSERT - درج در جدول کودک.

TimescaleDB

برای نسخه 4.2 ما توجه خود را به TimescaleDB معطوف کردیم. این یک پسوند PostgreSQL با یک رابط بومی است. برنامه افزودنی به طور موثر با داده های سری زمانی بدون از دست دادن مزایای پایگاه های داده رابطه ای کار می کند. TimescaleDB همچنین به طور خودکار پارتیشن بندی می شود.

TimescaleDB یک مفهوم دارد هایپر جدول (hypertable) که شما ایجاد می کنید. در آن هستند تکه ها - پارتیشن ها تکه ها قطعات مدیریت شده به صورت خودکار از یک جدول فوق هستند که بر قطعات دیگر تأثیر نمی گذارند. هر قطعه دارای محدوده زمانی خاص خود است.

TimescaleDB در مقابل PostgreSQL

TimescaleDB واقعا کارآمد است. تولیدکنندگان برنامه افزودنی ادعا می کنند که از الگوریتم پردازش پرس و جو صحیح تری استفاده می کنند، به ویژه inserts . با افزایش اندازه مجموعه داده ها، الگوریتم عملکرد ثابتی را حفظ می کند.

پس از 200 میلیون ردیف، PostgreSQL معمولاً شروع به کاهش زیادی می‌کند و عملکرد را به 0 از دست می‌دهد. 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® E5-2630 v 4 @ 2.20GHz، 16 گیگابایت رم و یک درایو SSD با ظرفیت 200 گیگابایت.

من PostgreSQL 10.8 را با سیستم عامل Debian 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 است.

اولین نمودار آبی تعداد مقادیر در ثانیه است. نمودار دوم سمت راست در حال بارگیری فرآیندهای ساخت است. سومین بارگذاری فرآیندهای ساخت داخلی است: همگام‌سازی تاریخ و Housekeeper که برای مدت کافی در اینجا اجرا شده است.

نمودار چهارم استفاده از 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 را تنظیم کردم و به عملکرد قابل قبولی دست یافتم.

در واقع، این محدودیت عملکردی است که در آن باید کاری انجام شود.

timescaledb. 80 nvps

وظیفه اصلی من آزمایش قابلیت های TimescaleDB در برابر بار Zabbix است. 80 هزار مقدار در ثانیه، فراوانی جمع آوری معیارها (البته به جز Yandex) و "تنظیم" نسبتاً بزرگ بسیار است.

در هر نمودار یک شیب وجود دارد - این فقط یک انتقال داده است. پس از خرابی در سرور Zabbix، نمایه بارگیری همگام سازی تاریخ بسیار تغییر کرده است - سه بار سقوط کرد.

TimescaleDB به شما امکان می دهد تقریباً 3 برابر سریعتر داده ها را وارد کنید و از HistoryCache کمتری استفاده کنید.

بر این اساس، داده ها را به موقع دریافت خواهید کرد.

timescaledb. 120 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

عملکرد بالا و پارتیشن بندی بومی: Zabbix با پشتیبانی TimescaleDB