زیبکس د څارنې سیسټم دی. د بل هر سیسټم په څیر، دا د ټولو څارنې سیسټمونو درې اصلي ستونزې سره مخ دي: د معلوماتو راټولول او پروسس کول، د تاریخ ذخیره کول، او پاکول.
د معلوماتو ترلاسه کولو، پروسس کولو او ثبتولو پړاوونه وخت نیسي. ډیر نه، مګر د لوی سیسټم لپاره دا کولی شي د لوی ځنډ لامل شي. د ذخیره کولو ستونزه د معلوماتو لاسرسي مسله ده. دوی د راپورونو، چکونو او محرکاتو لپاره کارول کیږي. معلوماتو ته لاسرسي کې ځنډ هم په فعالیت اغیزه کوي. کله چې ډیټابیسونه وده کوي، غیر اړونده معلومات باید حذف شي. لرې کول یو ستونزمن عملیات دی چې ځینې سرچینې هم خوري.
په زبکس کې د راټولولو او ذخیره کولو پرمهال د ځنډ ستونزې د کیچ کولو له لارې حل کیږي: د کیچ ډیری ډولونه ، په ډیټابیس کې کیچ کول. د دریمې ستونزې حل کولو لپاره ، کیچ کول مناسب ندي ، نو زبیکس د TimescaleDB کارولی. هغه به تاسو ته د هغې په اړه ووایي اندری ګوشین - تخنیکي ملاتړ انجنیر . انډری د 6 کلونو څخه ډیر وخت لپاره د زیبکس ملاتړ کوي او د فعالیت سره مستقیم تجربه لري.
TimescaleDB څنګه کار کوي، دا د منظم PostgreSQL په پرتله کوم فعالیت ورکولی شي؟ Zabbix د TimescaleDB ډیټابیس لپاره کوم رول لوبوي؟ څنګه له سکریچ څخه پیل کول او څنګه د PostgreSQL څخه مهاجرت کول او کوم ترتیب غوره فعالیت لري؟ د دې ټولو په اړه د کټ لاندې.
د تولید ننګونې
د څارنې هر سیسټم د ځانګړو کړنو ننګونو سره مخ دی. زه به د دوی د دریو په اړه وغږیږم: د معلوماتو راټولول او پروسس کول، ذخیره کول، او د تاریخ پاکول.
د معلوماتو چټک راټولول او پروسس کول. د څارنې یو ښه سیسټم باید ژر تر ژره ټول معلومات ترلاسه کړي او د محرک څرګندونو سره سم پروسس کړي - د دې معیارونو سره سم. د پروسس کولو وروسته، سیسټم باید ژر تر ژره دا ډاټا په ډیټابیس کې د وروسته کارولو لپاره خوندي کړي.
د تاریخ ذخیره. د څارنې یو ښه سیسټم باید تاریخ په ډیټابیس کې ذخیره کړي او میټریکونو ته اسانه لاسرسی چمتو کړي. تاریخ ته اړتیا ده چې په راپورونو، ګرافونو، محرکونو، حدونو، او حساب شوي خبرتیا ډاټا توکو کې وکارول شي.
د تاریخ پاکول. ځینې وختونه داسې ورځ راځي کله چې تاسو اړتیا نلرئ د میټریک ذخیره کړئ. تاسو ولې ډیټا ته اړتیا لرئ چې 5 کاله دمخه راټول شوي ، یوه یا دوه میاشتې: ځینې نوډونه حذف شوي ، ځینې کوربه یا میټریک نور اړتیا نلري ځکه چې دوی زاړه شوي او نور نه راټول شوي. د څارنې یو ښه سیسټم باید تاریخي معلومات ذخیره کړي او وخت په وخت یې حذف کړي ترڅو ډیټابیس وده ونه کړي.
د پخوانیو معلوماتو پاکول یوه مهمه مسله ده چې د ډیټابیس فعالیت خورا اغیزمن کوي.
په زبکس کې کیچ کول
په زیبکس کې، لومړی او دویم زنګونه د کیچنګ په کارولو سره حل کیږي. RAM د معلوماتو راټولولو او پروسس کولو لپاره کارول کیږي. د ذخیره کولو لپاره - تاریخ په محرکونو، ګرافونو او حساب شوي ډاټا عناصرو کې. د ډیټابیس اړخ کې د لومړني انتخابونو لپاره ځینې کیشینګ شتون لري ، د مثال په توګه ، ګرافونه.
د زیبکس سرور په اړخ کې کیچ کول پخپله دا دي:
- کنفیگریشن کیچ;
- ValueCache;
- د تاریخ کیچ؛
- TrendsCache.
دوی په تفصیل سره په پام کې ونیسئ.
ConfigurationCache
دا اصلي زیرمه ده چیرې چې موږ میټریکونه ، کوربه ، ډیټا توکي ، محرکونه ذخیره کوو - هرڅه چې موږ د پری پروسس کولو او د معلوماتو راټولولو لپاره ورته اړتیا لرو.
دا ټول په ConfigurationCache کې زیرمه شوي ترڅو په ډیټابیس کې غیر ضروري پوښتنې رامینځته نشي. وروسته له دې چې سرور پیل شي، موږ دا زیرمه تازه کوو، په منظم ډول ترتیبونه جوړ او تازه کوو.
د معلوماتو راټولول
انځور خورا لوی دی، مګر اصلي شی دا دی راټولونکي. دا مختلف "رایه ورکوونکي" دي - د مجلس پروسې. دوی د مختلف ډولونو مجلس لپاره مسؤل دي: دوی د SNMP، IPMI له لارې ډاټا راټولوي او دا ټول پری پروسس کولو ته لیږدوي.
راټولونکي په نارنجي رنګ کې بیان شوي.
Zabbix د راټولولو توکي محاسبه کړي چې د چکونو د راټولولو لپاره اړین دي. که موږ دوی ولرو، موږ د دوی لپاره مستقیم د ValueCache څخه ډاټا راوړو.
مخکې پروسس کولو تاریخ کیچ
ټول راټولونکي د دندو ترلاسه کولو لپاره ConfigurationCache کاروي. بیا دوی پری پروسس کولو ته لیږدوي.
PreProcessing د پری پروسس کولو مرحلو ترلاسه کولو لپاره ConfigurationCache کاروي. دا معلومات په مختلفو لارو پروسس کوي.
د PreProcessing په کارولو سره د معلوماتو پروسس کولو وروسته، موږ دا د پروسس کولو لپاره په HistoryCache کې خوندي کوو. دا د معلوماتو راټولول پای ته رسوي او موږ په زیبکس کې اصلي پروسې ته ځو - تاریخ همغږي کوونکيځکه چې دا یو واحد معمار دی.
یادونه: پری پروسس کول خورا ستونزمن عملیات دي. د v 4.2 راهیسې دا پراکسي ته لیږدول شوی. که تاسو د ډیری ډیټا عناصرو او راټولولو فریکونسۍ سره خورا لوی زیبکس ولرئ ، نو دا کار خورا اسانه کوي.
د ارزښت کیچ ، تاریخ او رجحانات کیچ
د تاریخ همغږي اصلي پروسه ده چې په اټومي ډول د هر ډیټا عنصر پروسس کوي ، دا هر ارزښت دی.
د تاریخ ترکیب د HistoryCache څخه ارزښتونه اخلي او د محاسبې لپاره د محرکاتو شتون لپاره ترتیب چیک کوي. که دوی شتون ولري، دا محاسبه کوي.
د تاریخ همغږي کونکي پیښه رامینځته کوي ، د خبرتیاو رامینځته کولو لپاره وده کوي که اړتیا وي د ترتیب او ریکارډونو لخوا. که چیرې د راتلونکي پروسس کولو لپاره محرکات شتون ولري ، نو دا دا ارزښت په ValueCache کې ساتي ترڅو د تاریخ میز ته لاسرسی ونلري. دا څنګه ValueCache د معلوماتو سره ډک شوی چې د محرکاتو او محاسبې عناصرو محاسبه کولو لپاره اړین دي.
د تاریخ ترکیب ټول ډیټابیس ته لیکي، او دا ډیسک ته لیکي. د پروسس کولو پروسه دلته پای ته رسیږي.
په ډیټابیس کې کیچ کول
د ډیټابیس اړخ کې مختلف کیچونه شتون لري کله چې تاسو غواړئ د پیښو ګرافونه یا راپورونه وګورئ:
Innodb_buffer_poolد MySQL اړخ کې؛shared_buffersد PostgreSQL اړخ کې؛effective_cache_sizeپه اوریکل اړخ کې؛shared_poolد DB2 اړخ کې.
ډیری نور کیچونه شتون لري، مګر دا د ټولو ډیټابیسونو لپاره اصلي دي. دوی تاسو ته اجازه درکوي په رام کې ډیټا ذخیره کړئ چې ډیری وختونه د پوښتنو لپاره اړین وي. دوی د دې لپاره خپل ټیکنالوژي لري.
د ډیټابیس فعالیت خورا مهم دی
د زیبکس سرور په دوامداره توګه معلومات راټولوي او لیکي. کله چې بیا پیل شي، دا د ValueCache ډکولو لپاره د تاریخ څخه هم لوستل کیږي. سکریپټونه او راپورونه کاروي Zabbix API، کوم چې په ویب انٹرفیس کې جوړ شوی. Zabbix API ډیټابیس ته لاسرسی لري او د ګرافونو ، راپورونو ، پیښو لیستونو او وروستي مسلو لپاره اړین معلومات ترلاسه کوي.
د لید لپاره - ګرافانا. دا زموږ د کاروونکو ترمنځ یو مشهور حل دی. دا کولی شي په مستقیم ډول د Zabbix API او ډیټابیس له لارې غوښتنې واستوي، او د معلوماتو ترلاسه کولو لپاره یو مشخص سیالي رامینځته کوي. له همدې امله، د پایلو او ازموینې ګړندۍ تحویلۍ سره سمون لپاره د ډیټابیس خورا ښه او غوره ټوننګ ته اړتیا ده.
housekeeper
په زیبکس کې دریم فعالیت ننګونه د کور کیپر په کارولو سره د تاریخ پاکول دي. دا ټول ترتیبات تعقیبوي - د ډیټا عناصر په ګوته کوي چې څومره وخت په ورځو کې د بدلونونو متحرکاتو (رجحاناتو) ذخیره کول.
موږ په الوتنه کې TrendsCache محاسبه کوو. کله چې ډاټا راشي، موږ یې د یو ساعت لپاره راټولوو او د رجحان بدلونونو متحرکاتو لپاره یې په جدولونو کې ثبت کوو.
کور کیپر د معمول "انتخاباتو" په کارولو سره له ډیټابیس څخه معلومات پیل او حذف کوي. دا تل اغیزمن نه وي، لکه څنګه چې د داخلي پروسو د فعالیت ګراف څخه لیدل کیدی شي.
سور ګراف ښیې چې د تاریخ ترکیب په دوامداره توګه بوخت دی. په پورتنۍ برخه کې نارنجي ګراف د کور ساتونکی دی چې په دوامداره توګه روان دی. هغه د ډیټابیس انتظار کوي ترڅو ټول هغه قطارونه حذف کړي چې هغه یې مشخص کړي.
کله باید د کور ساتونکی غیر فعال کړئ؟ د مثال په توګه ، د "توکي ID" شتون لري او تاسو اړتیا لرئ په ټاکلي وخت کې وروستي 5 زره قطارونه حذف کړئ. البته، دا د شاخص لخوا پیښیږي. مګر معمولا ډیټاسیټ خورا لوی وي ، او ډیټابیس لاهم له ډیسک څخه لوستل کیږي او کیچ ته یې اچوي. دا تل د ډیټابیس لپاره خورا ګران عملیات دي او د ډیټابیس اندازې پورې اړه لري، کولی شي د فعالیت ستونزې رامینځته کړي.
د کور ساتونکی د معلولیت لپاره اسانه دی. په ویب انټرفیس کې د کور ساتونکي لپاره د "ادارې عمومي" ترتیب شتون لري. موږ د داخلي رجحان تاریخ لپاره داخلي کور ساتنه غیر فعال کوو او دا نور دا اداره نه کوي.
د کور ساتونکی وتړل شو، ګرافونه پورته شول - پدې قضیه کې کومې ستونزې شتون لري او د دریم فعالیت ننګونې حل کولو کې څه مرسته کولی شي؟
Partitioning – Partitioning or partitioning
په عموم ډول، تقسیم کول په هر اړونده ډیټابیس کې په مختلف ډول تنظیم شوي چې ما لیست کړي دي. هر یو خپل ټیکنالوژي لري، مګر دوی په عمومي توګه ورته دي. د نوې برخې جوړول اکثرا د ځینې ستونزو لامل کیږي.
عموما، ویشونه د "سیټ اپ" پورې اړه لري - د ډیټا مقدار چې په یوه ورځ کې رامینځته کیږي. د یوې قاعدې په توګه، ویش په یوه ورځ کې صادریږي، دا لږترلږه دی. د نوې بستې د رجحاناتو لپاره - 1 میاشت.
ارزښتونه ممکن بدلون ومومي که چیرې "سیټ اپ" خورا لوی وي. که یو کوچنی "سیټ اپ" تر 5 nvps پورې وي (په یوه ثانیه کې نوي ارزښتونه) ، یو متوسط له 000 څخه تر 5 پورې وي ، بیا لوی یو له 000 nvps څخه پورته وي. دا لوی او خورا لوی تاسیسات دي چې د ډیټابیس محتاط ترتیب ته اړتیا لري.
په ډیرو لویو تاسیساتو کې، د یوې ورځې موده ممکن غوره نه وي. ما هره ورځ د 40 GB یا ډیر د MySQL برخې لیدلي دي. دا د ډیټا خورا لوی مقدار دی چې کولی شي ستونزې رامینځته کړي او کمولو ته اړتیا لري.
تقسیم څه ورکوي؟
د ویشلو میزونه. ډیری وختونه دا په ډیسک کې جلا جلا فایلونه دي. د پوښتنې پلان یوه برخه په غوره توګه غوره کوي. معمولا تقسیم کول د رینج لخوا کارول کیږي - دا د زیبکس لپاره هم ریښتیا ده. موږ هلته "ټایمپټامپ" کاروو - د دور له پیل راهیسې وخت. دا زموږ لپاره عادي شمیرې دي. تاسو د ورځې پیل او پای ټاکئ - دا یوه برخه ده.
چټک لرې کول - DELETE. یو فایل/ فرعي جدول د حذف کولو لپاره د قطارونو انتخاب پرځای غوره شوی.
د پام وړ د معلوماتو ترلاسه کول ګړندي کوي SELECT - د ټول جدول پرځای یو یا څو برخې کاروي. که تاسو دوه ورځې زاړه ډیټا ته لاسرسی ومومئ ، دا د ډیټابیس څخه ګړندي ترلاسه کیږي ځکه چې تاسو اړتیا لرئ یوازې یو فایل په کیچ کې بار کړئ او بیرته یې راوړئ ، نه لوی میز.
ډیری وختونه ډیری ډیټابیسونه هم ګړندي کیږي INSERT - د ماشومانو په میز کې داخلول.
د وخت نیټه
د v 4.2 لپاره، موږ خپل پام TimescaleDB ته واړوو. دا د اصلي انٹرفیس سره د PostgreSQL لپاره توسیع دی. تمدید د وخت لړۍ ډیټا سره په مؤثره توګه کار کوي پرته له دې چې د اړونده ډیټابیس ګټې له لاسه ورکړي. TimescaleDB هم په اوتومات ډول ویشل کیږي.
TimescaleDB یو مفهوم لري لوړ میز (hypertable) چې تاسو جوړ کړئ. دا لري ټوټې - تقسیمونه. ټوټې په اتوماتيک ډول اداره شوي هایپرټبل ټوټې دي چې په نورو برخو اغیزه نه کوي. هره ټوټه د خپل وخت حد لري.
TimescaleDB vs PostgreSQL
TimescaleDB واقعیا په مؤثره توګه کار کوي. د تمدید جوړونکي ادعا کوي چې دوی د پوښتنو ډیر درست پروسس کولو الګوریتم کاروي، په ځانګړي ډول inserts . لکه څنګه چې د ډیټاسیټ داخلولو اندازه وده کوي، الګوریتم ثابت فعالیت ساتي.
د 200 ملیون قطارونو وروسته ، PostgreSQL معمولا د پام وړ کمیدل پیل کوي او فعالیت 0 ته له لاسه ورکوي. TimescaleDB تاسو ته اجازه درکوي په مؤثره توګه د هر مقدار ډیټا لپاره "انسرټونه" داخل کړئ.
د جوړولو
د TimescaleDB نصب کول د هرې کڅوړې لپاره خورا اسانه دي. IN هرڅه په تفصیل سره بیان شوي - دا د رسمي PostgreSQL کڅوړو پورې اړه لري. TimescaleDB هم په لاسي ډول جوړ او تالیف کیدی شي.
د زبکس ډیټابیس لپاره موږ په ساده ډول توسیع فعالوو:
echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix
تاسو فعال کړئ extension او د زیبکس ډیټابیس لپاره یې جوړ کړئ. وروستی ګام د هایپر میز جوړول دي.
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 TB درلوده، کوم چې یو ساعت یې واخیست. حتی په ځینو قضیو کې ، د ازموینې پرمهال ، ما د کرکټر ډولونو تاریخي ډیټا حذف کړې چې د ذخیره کولو لپاره اړین ندي ، ترڅو د دوی لیږدولو ته اړتیا ونلري.
وروستی ګام - UPDATE: په db_extension واچول timescaledbد دې لپاره چې ډیټابیس پوه شي چې دا توسیع شتون لري. زیبکس دا فعالوي او ډیټابیس ته ترکیب او پوښتنې په سمه توګه کاروي - هغه ځانګړتیاوې چې د TimescaleDB لپاره اړین دي.
د هارډویر ترتیب
ما دوه سرورونه کارولي. لومړی - د VMware ماشین. دا خورا کوچنی دی: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz پروسیسرونه، د 16 GB رام او 200 GB SSD.
ما په دې کې د Debian 10.8-10.8.pgdg1+90 OS او xfs فایل سیسټم سره PostgreSQL 1 نصب کړ. ما هر څه لږترلږه د دې ځانګړي ډیټابیس کارولو لپاره تنظیم کړل، هغه څه چې زبیکس پخپله کاروي.
په ورته ماشین کې د زبیبکس سرور، PostgreSQL او شتون درلود د بارولو اجنټان. ما 50 فعال اجنټان درلودل چې کارول یې LoadableModuleپه چټکۍ سره د مختلفو پایلو تولید لپاره: شمیرې، تارونه. ما ډیټابیس د ډیرو معلوماتو سره ډک کړ.
په پیل کې ترتیب شامل دی 5 عناصر په هر کوربه کې ډاټا. نږدې هر عنصر یو محرک لري ترڅو دا د اصلي تاسیساتو سره ورته کړي. په ځینو مواردو کې له یو څخه زیات محرک شتون درلود. د یوې شبکې نوډ لپاره شتون درلود 3-000 محرکونه.
د ډاټا توکي تازه کولو وقفه - 4-7 ثانوي. ما نه یوازې د 50 اجنټانو په کارولو سره بار پخپله تنظیم کړ ، مګر نور اضافه کول. همچنان ، د ډیټا عناصرو په کارولو سره ، ما په متحرک ډول بار تنظیم کړ او د تازه کولو وقفه یې 4 s ته کمه کړه.
PostgreSQL. 35 nvps
په دې هارډویر کې زما لومړی چل په خالص PostgreSQL کې و - په هر ثانیه کې 35 زره ارزښتونه. لکه څنګه چې تاسو لیدلی شئ، د معلوماتو داخلول د ثانیې برخې نیسي - هرڅه ښه او چټک دي. یوازینی شی دا دی چې د 200 GB SSD ډیسک په چټکۍ سره ډکیږي.
دا د معیاري زیبکس سرور فعالیت ډشبورډ دی.
لومړی نیلي ګراف په هر ثانیه کې د ارزښتونو شمیر دی. په ښي خوا کې دوهم ګراف د جوړونې پروسې بار کول دي. دریم د داخلي جوړونې پروسې بار کول دي: د تاریخ همغږي کونکي او د کور ساتونکي ، کوم چې دلته د څه مودې راهیسې روان دي.
څلورم ګراف د تاریخ کیچ کارول ښیې. دا یو ډول بفر دی مخکې له دې چې ډیټابیس ته داخل شي. شنه پنځم ګراف د ValueCache کارول ښیې، دا دی چې څومره ValueCache د محرکاتو لپاره هټ کوي - دا په هر ثانیه کې څو زره ارزښتونه دي.
PostgreSQL. 50 nvps
بیا ما په ورته هارډویر کې په هر ثانیه کې 50 زره ارزښتونو ته بار لوړ کړ.
کله چې د کور کیپر څخه بار کول ، د 10 زره ارزښتونو دننه کول 2-3 ثانیې وخت نیسي.
د کور ساتونکي لا دمخه په کار کې مداخله پیل کړې.
دریم ګراف ښیي چې په ټولیزه توګه، د ټریپرانو او تاریخي ترکیبونو بار لاهم په 60٪ کې دی. په څلورم ګراف کې، HistoryCache لا دمخه د کور کیپر عملیاتو په جریان کې په فعاله توګه ډکولو پیل کوي. دا 20٪ ډک دی، کوم چې د 0,5 GB په اړه دی.
PostgreSQL. 80 nvps
بیا ما بار په هر ثانیه کې 80 زره ارزښتونو ته لوړ کړ. دا نږدې 400 زره ډیټا عناصر او 280 زره محرکونه دي.
د دېرش تاریخي ترکیب کونکو بارولو لګښت دمخه خورا لوړ دی.
ما مختلف پیرامیټونه هم زیات کړل: د تاریخ ترکیبونه، کیچونه.
زما په هارډویر کې ، د تاریخ ترکیبونو بار کول اعظمي حد ته لوړ شوي. د تاریخ کیچ په چټکۍ سره د معلوماتو څخه ډک شوی - د پروسس کولو لپاره ډاټا په بفر کې راټول شوي.
دا ټول وخت ما ولیدل چې څنګه پروسیسر، رام او نور سیسټم پیرامیټونه کارول شوي، او وموندل چې د ډیسک کارول په اعظمي حد کې و.
ما کارول ترلاسه کړل د ډیسک اعظمي وړتیاوې په دې هارډویر او دې مجازی ماشین کې. د داسې شدت سره، PostgreSQL په فعاله توګه د معلوماتو فلش کول پیل کړل، او ډیسک نور د لیکلو او لوستلو وخت نه درلود.
دوهم سرور
ما یو بل سرور واخیست ، کوم چې دمخه 48 پروسیسرونه او 128 GB رام درلود. ما دا ټون کړ - دا یې د 60 تاریخ ترکیب ته وټاکه، او د منلو وړ فعالیت یې ترلاسه کړ.
په حقیقت کې، دا دمخه د تولید حد دی چیرې چې یو څه باید ترسره شي.
TimescaleDB. 80 nvps
زما اصلي دنده د Zabbix بار په وړاندې د TimescaleDB وړتیاوې ازمول دي. په هره ثانیه کې 80 زره ارزښتونه خورا ډیر دي، د میټریکونو راټولولو فریکوینسي (د Yandex پرته، البته) او په کافي اندازه لوی "سیټ اپ".
په هر ګراف کې ډوب شتون لري - دا دقیقا د معلوماتو مهاجرت دی. د زبیبکس سرور کې د ناکامۍ وروسته، د تاریخ سنسر د بارولو پروفایل ډیر بدل شو - دا درې ځله راټیټ شو.
TimescaleDB تاسو ته اجازه درکوي چې نږدې 3 ځله ګړندي ډیټا دننه کړئ او لږ HistoryCache وکاروئ.
په دې اساس، تاسو به په وخت سره معلومات ترلاسه کړئ.
TimescaleDB. 120 nvps
بیا ما د ډیټا عناصرو شمیر 500 زره ته لوړ کړ اصلي دنده د TimescaleDB وړتیا ازمول وو - ما په هره ثانیه کې د 125 زره ارزښتونو حساب شوي ارزښت ترلاسه کړ.
دا یو کاري "سیټ اپ" دی چې کولی شي د اوږدې مودې لپاره کار وکړي. مګر څنګه چې زما ډیسک یوازې 1,5 TB و ، ما دا په څو ورځو کې ډک کړ.
ترټولو مهمه خبره دا ده چې په ورته وخت کې د TimescaleDB نوي برخې جوړې شوې.
دا د فعالیت لپاره په بشپړ ډول د پام وړ نه دی. کله چې په MySQL کې پارټیشنونه جوړ شي، د بیلګې په توګه، هرڅه توپیر لري. دا معمولا د شپې پیښیږي ځکه چې دا د عمومي داخلیدو مخه نیسي ، د میزونو سره کار کوي او د خدماتو تخریب رامینځته کولی شي. دا د TimescaleDB سره قضیه نده.
د مثال په توګه، زه به په ټولنه کې د ډیری څخه یو ګراف وښیم. په عکس کې، TimescaleDB فعال شوی، مننه چې په پروسیسر کې د io.weight کارولو بار راټیټ شوی. د داخلي پروسې عناصرو کارول هم کم شوي. سربیره پردې ، دا په عادي پینکیک ډیسکونو کې یو عادي مجازی ماشین دی ، نه SSD.
موندنو
TimescaleDB د کوچني "سیټ اپ" لپاره ښه حل دی، کوم چې د ډیسک فعالیت اغیزه کوي. دا به تاسو ته اجازه درکړي چې ښه کار ته دوام ورکړئ تر هغه چې ډیټابیس ژر تر ژره هارډویر ته لیږدول کیږي.
TimescaleDB تنظیم کول اسانه دي ، د فعالیت لاسته راوړنې ورکوي ، د زیبکس او سره ښه کار کوي په PostgreSQL کې ګټې لري.
که تاسو PostgreSQL کاروئ او د دې بدلولو پلان نلرئ ، زه وړاندیز کوم د Zabbix سره په ګډه د TimescaleDB توسیع سره PostgreSQL وکاروئ. دا حل په مؤثره توګه د منځنۍ "سیټ اپ" پورې کار کوي.
کله چې موږ وایو "لوړ فعالیت" زموږ معنی ده . تاسو به د ټیکنالوژیو او عملونو په اړه زده کولو لپاره اوږد انتظار ونه کړئ چې د ملیونونو کاروونکو ته خدمت کولو وړتیا ورکوي. لیست د نومبر د 7 او 8 لپاره موږ لا دمخه تالیف کړی، مګر دلته نور وړاندیز کیدی شي.
زموږ سره ګډون وکړئ и ، په کوم کې چې موږ د راتلونکي کنفرانس ځانګړتیاوې څرګندوو، او ومومئ چې څنګه له دې څخه ډیره ګټه ترلاسه کړو.
سرچینه: www.habr.com