موږ به وګورو چې زبیکس څنګه د TimescaleDB ډیټابیس سره د شالید په توګه کار کوي. موږ به تاسو ته وښیو چې څنګه له سکریچ څخه پیل وکړو او څنګه د PostgreSQL څخه مهاجرت وکړو. موږ به د دوه تشکیلاتو پرتله کولو فعالیت ازموینې هم چمتو کړو.
HighLoad++ سایبریا 2019. تومسک هال. د جون 24، 16:00. مقالې او . راتلونکی HighLoad++ کنفرانس به د اپریل په 6 او 7، 2020 په سینټ پیټرزبورګ کې ترسره شي. تفصیلات او ټکټونه .
اندری ګوشین (له دې وروسته - AG): - زه د ZABBIX تخنیکي مالتړ انجینر یم (له دې وروسته د "زابکس" په نوم یادیږي)، یو روزونکی. زه د 6 کلونو څخه زیات په تخنیکي مالتړ کې کار کوم او د فعالیت سره مستقیم تجربه لرم. نن زه به د هغه فعالیت په اړه وغږیږم چې TimescaleDB کولی شي چمتو کړي کله چې د منظم PostgreSQL 10 سره پرتله شي. همدارنګه، ځینې ابتدايي برخه پدې اړه چې دا په عمومي توګه څنګه کار کوي.
د تولید لوړ ننګونې: د معلوماتو راټولولو څخه د معلوماتو پاکولو پورې
د پیل کولو لپاره، د فعالیت ځینې ننګونې شتون لري چې د څارنې هر سیسټم ورسره مخ دی. د تولید لومړۍ ننګونه په چټکۍ سره د معلوماتو راټولول او پروسس کول دي.
د څارنې یو ښه سیسټم باید ژر تر ژره ټول معلومات ترلاسه کړي، د محرک بیانونو سره سم پروسس کړي، دا د ځینو معیارونو سره سم پروسس کړي (دا په مختلفو سیسټمونو کې توپیر لري) او په ډیټابیس کې خوندي کړئ ترڅو دا ډاټا په ډیټابیس کې وکاروي. راتلونکی
دوهم فعالیت ننګونه د تاریخ ذخیره ده. ډیری وختونه په ډیټابیس کې ذخیره کړئ او دې میټریکونو ته ګړندي او اسانه لاسرسی ولرئ چې د یوې مودې په اوږدو کې راټول شوي. ترټولو مهمه خبره دا ده چې دا معلومات د ترلاسه کولو لپاره اسانه دي، په راپورونو، ګرافونو، محرکونو، په ځینو حدونو ارزښتونو کې، د خبرتیاو لپاره، او داسې نور.
د فعالیت دریمه ننګونه د تاریخ پاکول دي، دا دی، کله چې تاسو هغه ځای ته ورسیږئ چیرې چې تاسو اړتیا نلرئ کوم مفصل میټریکونه ذخیره کړئ چې په 5 کلونو کې راټول شوي وي (حتی میاشتې یا دوه میاشتې). د شبکې ځینې نوډونه حذف شوي ، یا ځینې کوربه ، میټریک ته نور اړتیا نشته ځکه چې دوی دمخه زاړه شوي او نور نه راټولیږي. دا ټول باید پاک شي ترڅو ستاسو ډیټابیس ډیر لوی نشي. په عموم کې، د تاریخ پاکول اکثرا د ذخیره کولو لپاره یو جدي ازموینه ده - دا ډیری وختونه په فعالیت خورا قوي اغیزه لري.
د کیشینګ ستونزې څنګه حل کړو؟
زه به اوس په ځانګړې توګه د زیبکس په اړه وغږیږم. په زیبکس کې، لومړی او دویم زنګونه د کیچنګ په کارولو سره حل کیږي.
د معلوماتو راټولول او پروسس کول - موږ د دې ټولو معلوماتو ذخیره کولو لپاره رام کاروو. دا معلومات به اوس په ډیر تفصیل سره بحث وشي.
همدارنګه د ډیټابیس اړخ کې د اصلي انتخابونو لپاره ځینې کیشینګ شتون لري - د ګرافونو او نورو شیانو لپاره.
پخپله د زیبکس سرور په اړخ کې کیچ کول: موږ ConfigurationCache، ValueCache، HistoryCache، TrendsCache لرو. دا څه شی دی؟
ConfigurationCache اصلي زیرمه ده په کوم کې چې موږ میټریکونه، کوربه، د ډاټا توکي، محرکات ذخیره کوو؛ هرڅه چې تاسو اړتیا لرئ د پری پروسس کولو پروسس کولو ته اړتیا لرئ، ډاټا راټول کړئ، له کوم کوربه څخه راټول کړئ، د کومې فریکونسۍ سره. دا ټول په ConfigurationCache کې زیرمه شوي ترڅو ډیټابیس ته لاړ نشي او غیر ضروري پوښتنې رامینځته کړي. وروسته له دې چې سرور پیل شي، موږ دا زیرمه تازه کوو (دا جوړ کړئ) او په وخت سره یې تازه کړئ (د ترتیب تنظیماتو پورې اړه لري).
په زبکس کې کیچ کول. د معلوماتو راټولول
دلته انځور خورا لوی دی:
په سکیم کې اصلي دا راټولونکي دي:
دا پخپله د مجلس پروسې دي، مختلف "رایه ورکوونکي" چې د مختلفو ډولونو د غونډو مسولیت لري. دوی د icmp، ipmi، او مختلف پروتوکولونو له لارې ډاټا راټولوي او دا ټول پری پروسس کولو ته لیږدوي.
مخکې پروسس کولو تاریخ کیچ
همچنان ، که موږ د ډیټا عناصر محاسبه کړي (هغه څوک چې د زیبکس سره آشنا دي) ، دا دی ، محاسبه شوي ، د راټولولو ډیټا عناصر ، موږ دوی مستقیم له ValueCache څخه اخلو. زه به تاسو ته ووایم چې دا څنګه وروسته ډک شوی. دا ټول راټولونکي د خپلو دندو ترلاسه کولو لپاره ConfigurationCache کاروي او بیا یې پری پروسس کولو ته لیږدوي.
پری پروسس کول د پری پروسس کولو مرحلو ترلاسه کولو لپاره ConfigurationCache هم کاروي او دا ډاټا په بیلابیلو لارو پروسس کوي. د 4.2 نسخه څخه پیل، موږ دا یو پراکسي ته لیږدول. دا خورا اسانه دی، ځکه چې مخکې پروسس کول پخپله یو ستونزمن عملیات دي. او که تاسو خورا لوی زیبکس لرئ ، د ډیټا عناصرو لوی شمیر او د راټولولو لوړې فریکونسۍ سره ، نو دا کار خورا ساده کوي.
په دې اساس، وروسته له دې چې موږ دا معلومات په یو ډول د پری پروسس کولو په کارولو سره پروسس کړو، موږ دا د نور پروسس کولو لپاره په HistoryCache کې خوندي کوو. دا د معلوماتو راټولول پای ته رسوي. موږ اصلي پروسې ته ځو.
د تاریخ ترکیب کار
په زیبکس کې اصلي پروسه (ځکه چې دا یو واحد معمار دی) د تاریخ ترکیب دی. دا اصلي پروسه ده چې په ځانګړي ډول د هر ډیټا عنصر اټومي پروسس کولو سره معامله کوي ، دا د هر ارزښت دی:
- ارزښت راځي (دا د تاریخ کیچ څخه اخلي)؛
- د کنفیګریشن سنسر کې چکونه: ایا د محاسبې لپاره کوم محرک شتون لري - دوی محاسبه کوي؛
که چیرې شتون ولري - پیښې رامینځته کوي ، د خبرتیا رامینځته کولو لپاره اضافې رامینځته کوي ، که اړتیا وي د ترتیب سره سم؛ - ریکارډونه د راتلونکی پروسس لپاره محرکات، راټولول؛ که تاسو په وروستي ساعت کې راټول کړئ او داسې نور، دا ارزښت د ValueCache لخوا په یاد ساتل کیږي ترڅو د تاریخ میز ته لاړ نشي؛ په دې توګه، ValueCache د اړین معلوماتو سره ډک شوی چې د محرکاتو، محاسبې عناصرو، او داسې نورو محاسبه کولو لپاره اړین دي؛
- بیا د تاریخ همغږي کونکي ډیټابیس ته ټول معلومات لیکي؛
- ډیټابیس دوی ډیسک ته لیکي - دا هغه ځای دی چې د پروسس پروسه پای ته رسیږي.
ډیټابیس. کیشینګ
د ډیټابیس اړخ کې، کله چې تاسو غواړئ ګرافونه یا د پیښو په اړه ځینې راپورونه وګورئ، مختلف کیچونه شتون لري. خو په دې راپور کې به یې په اړه خبرې ونه کړم.
د MySQL لپاره Inodb_buffer_pool شتون لري، او د مختلفو کیچونو یوه ډله چې هم ترتیب کیدی شي.
مګر دا اصلي دي:
- مشترک_بفرونه
- اغیزمن_کیچ_سایز؛
- شريک_پول.
د ټولو ډیټابیسونو لپاره ، ما وویل چې ځینې ځانګړي کیچونه شتون لري چې تاسو ته اجازه درکوي په رام کې هغه ډیټا ذخیره کړئ چې ډیری وختونه د پوښتنو لپاره اړین وي. دوی د دې لپاره خپل ټیکنالوژي لري.
د ډیټابیس فعالیت په اړه
په دې اساس، یو رقابتي چاپیریال شتون لري، دا دی، د زیبکس سرور ډاټا راټولوي او ثبتوي. کله چې بیا پیل شي، دا د ValueCache ډکولو لپاره د تاریخ څخه هم لوستل کیږي او داسې نور. دلته تاسو کولی شئ سکریپټونه او راپورونه ولرئ چې د Zabbix API کاروي، کوم چې په ویب انٹرفیس کې جوړ شوی. Zabbix API ډیټابیس ته ننوځي او د ګرافونو، راپورونو، یا د پیښو یو ډول لیست، وروستي ستونزې ترلاسه کولو لپاره اړین معلومات ترلاسه کوي.
همدارنګه د لید خورا مشهور حل ګرافانا دی ، کوم چې زموږ کارونکي یې کاروي. د زبکس API او ډیټابیس له لارې په مستقیم ډول د ننوتلو وړتیا. دا د معلوماتو ترلاسه کولو لپاره یو مشخص سیالي هم رامینځته کوي: د پایلو او ازموینې ګړندۍ تحویلۍ سره مطابقت لپاره د ډیټابیس خورا ښه ، غوره ټوننګ ته اړتیا ده.
د تاریخ پاکول. زبیکس د کور ساتونکی لري
دریم کال چې په زبکس کې کارول کیږي د کور کیپر په کارولو سره تاریخ پاکوي. کور کیپر ټول ترتیبات تعقیبوي، دا زموږ د معلوماتو عناصر په ګوته کوي چې څومره وخت ذخیره کول (په ورځو کې)، د رجحاناتو ذخیره کولو څومره وخت، او د بدلونونو متحرکات.
ما د TrendCache په اړه خبرې نه دي کړې، کوم چې موږ په الوتنه کې حساب کوو: ډاټا راځي، موږ یې د یو ساعت لپاره راټولوو (اکثره دا د وروستي ساعت لپاره شمیرې دي)، اندازه یې اوسط / لږترلږه ده او موږ یې په ساعت کې یو ځل ثبت کوو. د بدلونونو د تحرک جدول ("چلندونه"). "کور ساتونکی" د منظم انتخابونو په کارولو سره د ډیټابیس څخه ډاټا پیل او حذف کوي، کوم چې تل اغیزمن نه وي.
څنګه پوه شو چې دا غیر موثر دی؟ تاسو کولی شئ د داخلي پروسو د فعالیت ګراف کې لاندې انځور وګورئ:
ستاسو د تاریخ ترکیب په دوامداره توګه بوخت دی (سور ګراف). او "سرخ" ګراف چې په سر کې ځي. دا یو "کور ساتونکی" دی چې پیل کیږي او ډیټابیس ته انتظار کوي ترڅو ټول هغه قطارونه حذف کړي چې دا یې مشخص کړي.
راځئ چې یو څه توکي ID واخلو: تاسو اړتیا لرئ وروستي 5 زره حذف کړئ؛ البته، د شاخصونو له مخې. مګر معمولا ډیټاسیټ خورا لوی وي - ډیټابیس لاهم دا له ډیسک څخه لوستل کوي او کیچ ته یې اچوي ، او دا د ډیټابیس لپاره خورا ګران عملیات دي. د دې اندازې پورې اړه لري، دا کولی شي د ځینې فعالیت ستونزې رامینځته کړي.
تاسو کولی شئ په ساده ډول د کور کیپر غیر فعال کړئ - موږ یو پیژندل شوی ویب انٹرفیس لرو. د ادارې عمومي ترتیبات (د "کور ساتونکي" لپاره ترتیبات) موږ د داخلي تاریخ او رجحاناتو لپاره داخلي کور ساتنه غیر فعال کوو. په دې اساس، د کور ساتونکی نور دا کنټرول نه کوي:
تاسو نور څه کولی شئ؟ تاسو یې بند کړی، ستاسو ګرافونه لوړ شوي دي... په دې قضیه کې نورې کومې ستونزې رامنځته کیدی شي؟ څه مرسته کولی شي؟
ویشل (برخه کول)
معمولا دا په هر اړونده ډیټابیس کې چې ما لیست کړی په مختلف ډول تنظیم شوی. MySQL خپله ټیکنالوژي لري. مګر په ټولیز ډول دوی خورا ورته دي کله چې دا د PostgreSQL 10 او MySQL ته راځي. البته، په دې کې ډیری داخلي توپیرونه شتون لري چې دا ټول څنګه پلي کیږي او دا ټول څنګه په فعالیت اغیزه کوي. مګر په عموم کې، د نوي ویش جوړول ډیری وختونه د ځینو ستونزو لامل کیږي.
ستاسو په ترتیب پورې اړه لري (تاسو په یوه ورځ کې څومره ډیټا رامینځته کوئ) ، دوی معمولا لږترلږه ټاکي - دا د 1 ورځ / بیچ دی ، او د "سلوکونو" لپاره ، د بدلون متحرکات - 1 میاشت / نوې بسته. دا ممکن بدلون ومومي که تاسو خورا لوی ترتیب ولرئ.
راځئ چې سمدلاسه د سیټ اپ اندازې په اړه ووایو: په هر ثانیه کې تر 5 زره نوي ارزښتونو پورې (د Nvps په نوم) - دا به یو کوچنی "سیټ اپ" وګڼل شي. اوسط - په هره ثانیه کې له 5 څخه تر 25 زره ارزښتونو پورې. ټول هغه څه چې پورته دي دمخه لوی او خورا لوی تاسیسات دي چې د ډیټابیس خورا محتاط ترتیب ته اړتیا لري.
په خورا لوی تاسیساتو کې، 1 ورځ ممکن غوره نه وي. ما په شخصي توګه په MySQL کې هره ورځ د 40 ګیګابایټ برخې برخې لیدلي (او ممکن نور هم وي). دا د معلوماتو خورا لوی مقدار دی، کوم چې کولی شي د ځینو ستونزو لامل شي. دا باید کم شي.
تاسو ولې ویشلو ته اړتیا لرئ؟
هغه څه چې ویش چمتو کوي، زما په اند هرڅوک پوهیږي، د میز ویشل دي. ډیری وختونه دا په ډیسک او سپان غوښتنو کې جلا فایلونه دي. دا یو تقسیم په غوره توګه غوره کوي که چیرې دا د نورمال تقسیم کولو برخه وي.
د زیبکس لپاره، په ځانګړې توګه، دا د رینج په واسطه کارول کیږي، د رینج په واسطه، دا دی، موږ د مهال ویش کاروو (یو منظم شمیره، د دورې له پیل راهیسې وخت). تاسو د ورځې پیل / د ورځې پای مشخص کړئ، او دا ویش دی. په همدې اساس ، که تاسو د دوه ورځو زاړه معلوماتو غوښتنه کوئ ، نو هرڅه د ډیټابیس څخه ګړندي ترلاسه کیږي ، ځکه چې تاسو اړتیا لرئ یوازې یو فایل په کیچ کې بار کړئ او بیرته یې ورکړئ (د لوی میز پرځای).
ډیری ډیټابیس هم داخلول ګړندي کوي (د ماشوم په میز کې داخلول). زه د اوس لپاره په لنډ ډول خبرې کوم، مګر دا هم ممکنه ده. ویشل اکثرا مرسته کوي.
د NoSQL لپاره لچک لټون
په دې وروستیو کې، په 3.4 کې، موږ د NoSQL حل پلي کړ. په Elasticsearch کې د لیکلو وړتیا اضافه کړه. تاسو کولی شئ ځینې ډولونه ولیکئ: تاسو غوره کوئ - یا شمیرې یا ځینې نښې ولیکئ؛ موږ د تار متن لرو، تاسو کولی شئ د Elasticsearch ته لاګونه ولیکئ... په دې اساس، ویب انٹرفیس به Elasticsearch ته هم لاسرسی ومومي. دا په ځینو مواردو کې ښه کار کوي، مګر په اوس وخت کې دا کارول کیدی شي.
TimescaleDB. Hypertables
د 4.4.2 لپاره موږ یو شی ته پاملرنه وکړه لکه TimescaleDB. دا څه شی دی؟ دا د PostgreSQL لپاره توسیع دی، دا دی، دا د اصلي PostgreSQL انٹرفیس لري. برسیره پردې، دا تمدید تاسو ته اجازه درکوي چې د وخت لړۍ ډیټا سره ډیر اغیزمن کار وکړئ او اتوماتیک ویش ولرئ. دا څه ښکاري:
دا هایپرټبل دی - په Timescale کې داسې مفهوم شتون لري. دا یو هایپر میز دی چې تاسو یې جوړ کړئ، او دا ټوټې لري. ټوټې برخې دي، دا د ماشومانو میزونه دي، که زه غلط نه یم. دا واقعیا اغیزمنه ده.
TimescaleDB او PostgreSQL
لکه څنګه چې د TimescaleDB جوړونکي ډاډ ورکوي، دوی د پوښتنو پروسس کولو لپاره یو ډیر درست الګوریتم کاروي، په ځانګړي ډول داخلونو کې، کوم چې دوی ته اجازه ورکوي چې د ډیټاسیټ داخلولو زیاتیدونکي اندازې سره نږدې دوامداره فعالیت ولري. دا دی، د پوسټګریس د 200 ملیون قطارونو وروسته، معمول یو ډیر ټیټ پیل کوي او په لفظي توګه صفر ته فعالیت له لاسه ورکوي، پداسې حال کې چې ټایمزکل تاسو ته اجازه درکوي د هرډول ډیټا سره د امکان تر حده مؤثره داخل کړئ.
د TimescaleDB څنګه نصب کړئ؟ دا ساده ده!
دا په اسنادو کې دی، دا تشریح شوی - تاسو کولی شئ دا د هر ډول کڅوړو څخه نصب کړئ ... دا د رسمي پوسټګریس کڅوړو پورې اړه لري. په لاسي ډول تالیف کیدی شي. دا داسې پیښ شوي چې زه باید د ډیټابیس لپاره تالیف کړم.
په زبیکس کې موږ په ساده ډول توسیع فعالوو. زه فکر کوم هغه څوک چې په پوسټګریس کې توسیع کارولی ... تاسو په ساده ډول توسیع فعال کړئ، دا د زیبکس ډیټابیس لپاره جوړ کړئ چې تاسو یې کاروئ.
او وروستی ګام ...
TimescaleDB. د تاریخ میزونو مهاجرت
تاسو اړتیا لرئ یو هایپر میز جوړ کړئ. د دې لپاره یو ځانګړی فعالیت شتون لري - هایپرټبل جوړ کړئ. پدې کې ، لومړی پیرامیټر هغه جدول دی چې پدې ډیټابیس کې ورته اړتیا ده (د کوم لپاره چې تاسو اړتیا لرئ د هایپر میز رامینځته کړئ).
هغه ساحه چې د هغې په واسطه رامینځته کیږي، او د chunk_time_interval (دا د ټوټو وقفه ده (هغه برخې چې باید وکارول شي). 86 یوه ورځ ده.
د مهاجرت_ډاټا پیرامیټر: که تاسو ریښتیا ته داخل کړئ ، نو دا به ټول اوسني معلومات دمخه رامینځته شوي ټوټو ته مهاجر کړي.
ما پخپله migrate_data کارولی دی - دا یو مناسب وخت نیسي، پدې پورې اړه لري چې ستاسو ډیټابیس څومره لوی دی. ما له یو ټیرابایټ څخه ډیر درلود - د جوړولو لپاره یې له یو ساعت څخه ډیر وخت واخیست. په ځینو مواردو کې، د ازموینې په جریان کې، ما د متن (history_text) او تار (history_str) لپاره تاریخي معلومات حذف کړل ترڅو دوی یې انتقال نه کړي - دوی واقعیا زما لپاره په زړه پوري ندي.
او موږ وروستی تازه په خپل db_extention کې کوو: موږ timecaledb نصب کوو ترڅو ډیټابیس او په ځانګړي توګه زموږ زیبکس پوه شي چې db_extention شتون لري. هغه دا فعالوي او ډیټابیس ته سم ترکیب او پوښتنې کاروي ، د هغه "ځانګړو" په کارولو سره چې د TimescaleDB لپاره اړین دي.
د سرور ترتیب
ما دوه سرورونه کارولي. لومړی سرور یو کافي کوچنی مجازی ماشین دی، 20 پروسیسرونه، 16 ګیګابایټ RAM. ما پدې کې پوسټګریس 10.8 تنظیم کړ:
عملیاتي سیسټم دیبیان و، د فایل سیسټم xfs و. ما د دې ځانګړي ډیټابیس کارولو لپاره لږترلږه تنظیمات رامینځته کړي ، منفي هغه څه چې زبیکس پخپله به کاروي. په ورته ماشین کې د زبیبکس سرور، PostgreSQL او د بار اجنټان وو.
ما 50 فعال اجنټان کارولي دي چې د LoadableModule کاروي ترڅو ژر تر ژره مختلف پایلې رامینځته کړي. دوی هغه دي چې تارونه، شمیرې او داسې نور یې تولید کړي. ما ډیټابیس د ډیرو معلوماتو سره ډک کړ. په پیل کې، ترتیب په هر کوربه کې 5 زره ډیټا عناصر درلودل، او نږدې هر ډیټا عنصر یو محرک درلود - د دې لپاره چې دا یو ریښتینی ترتیب وي. ځینې وختونه تاسو حتی د کارولو لپاره له یو څخه ډیر محرک ته اړتیا لرئ.
ما د اپډیټ وقفه او بار پخپله نه یوازې د 50 اجنټانو (نور اضافه کولو) په کارولو سره تنظیم کړ ، بلکه د متحرک ډیټا عناصرو په کارولو او د تازه وقفې 4 ثانیو ته کمولو سره.
د فعالیت ازموینه. PostgreSQL: 36 زره NVPs
لومړی لانچ ، لومړی ترتیب چې ما درلود په دې هارډویر کې په خالص PostreSQL 10 کې و (په هره ثانیه کې 35 زره ارزښتونه). په عموم کې، لکه څنګه چې تاسو په سکرین کې لیدلی شئ، د معلوماتو داخلول د ثانیې برخې نیسي - هرڅه ښه او چټک دي، SSD ډرایو (200 ګیګابایټ). یوازینی شی دا دی چې 20 GB خورا ګړندی ډکوي.
په راتلونکي کې به دا ډول ګرافونه خورا ډیر وي. دا د معیاري زیبکس سرور فعالیت ډشبورډ دی.
لومړی ګراف په هر ثانیه کې د ارزښتونو شمیر دی (نیلي، پورتنۍ کیڼ)، پدې حالت کې 35 زره ارزښتونه. دا (پورته مرکز) د جوړونې پروسو بار کول دي، او دا (پورته ښیې) د داخلي پروسو بار کول دي: تاریخي همغږي کونکي او کور کیپر، کوم چې دلته (لاندې مرکز) د څه مودې لپاره روان دی.
دا ګراف (لاندې مرکز) د ValueCache کارول ښیې - څومره ValueCache د محرکاتو لپاره (په یوه ثانیه کې څو زره ارزښتونه). بل مهم ګراف څلورم دی (لاندې کیڼ لور ته)، کوم چې د HistoryCache کارول ښیې، کوم چې ما په اړه خبرې وکړې، کوم چې ډیټابیس ته د ننوتلو دمخه بفر دی.
د فعالیت ازموینه. PostgreSQL: 50 زره NVPs
بیا ، ما په ورته هارډویر کې په هر ثانیه کې 50 زره ارزښتونو ته بار لوړ کړ. کله چې د کور کیپر لخوا بار شوی، 10 زره ارزښتونه په 2-3 ثانیو کې د محاسبې سره ثبت شوي. څه، په حقیقت کې، په لاندې سکرین شاټ کې ښودل شوي:
"د کور ساتونکي" لا دمخه په کار کې مداخله پیل کړې، مګر په ټولیزه توګه، د تاریخي ډوبونکي جالونو بار لاهم د 60٪ په کچه کې دی (دریم ګراف، پورتنۍ ښي خوا). د تاریخ کیچ لا دمخه په فعاله توګه ډکول پیل کوي پداسې حال کې چې کور کیپر روان دی (لاندې کیڼ). دا شاوخوا نیم ګیګابایټ وه، 20٪ ډک.
د فعالیت ازموینه. PostgreSQL: 80 زره NVPs
بیا ما دا په هره ثانیه کې 80 زره ارزښتونو ته لوړ کړ:
دا تقریبا 400 زره ډیټا عناصر، 280 زره محرکونه وو. داخل کول، لکه څنګه چې تاسو لیدلی شئ، د تاریخ ډوبونکو بار په شرایطو کې (د دوی 30 شتون درلود) لا دمخه خورا لوړ و. بیا ما مختلف پیرامیټونه زیات کړل: د تاریخ ډوبونکي، کیچ ... په دې هارډویر کې، د تاریخ ډوبونکي بار تر اعظمي حد پورې زیاتیدل پیل کړل، نږدې "په شیلف" - په دې اساس، د تاریخ کیچ خورا لوړ بار ته لاړ:
پدې ټول وخت کې ما د سیسټم ټول پیرامیټونه وڅارل (څنګه پروسیسر کارول کیږي ، RAM) او وموندله چې د ډیسک کارول اعظمي و - ما پدې هارډویر کې ، پدې مجازی ماشین کې د دې ډیسک اعظمي ظرفیت ترلاسه کړ. "پوسټګریس" په دومره شدت کې په فعاله توګه ډیټا ډمپ کول پیل کړل ، او ډیسک نور د لیکلو ، لوستلو لپاره وخت نه درلود ...
ما یو بل سرور واخیست چې دمخه یې 48 پروسیسرونه او 128 ګیګابایټ رام درلود:
ما دا هم "ټیون" کړ - د تاریخ ترکیب نصب کړ (60 ټوټې) او د منلو وړ فعالیت یې ترلاسه کړ. په حقیقت کې ، موږ "په المارۍ کې" نه یو ، مګر دا شاید د تولید حد وي ، چیرې چې دمخه د دې په اړه یو څه کول اړین دي.
د فعالیت ازموینه. TimescaleDB: 80 زره NVPs
زما اصلي دنده د TimescaleDB کارول و. هر ګراف یو ډوب ښیي:
دا ناکامۍ دقیقا د معلوماتو مهاجرت دي. له هغې وروسته، په زبیبکس سرور کې، د تاریخ ډوبونکو بارولو پروفایل، لکه څنګه چې تاسو لیدلی شئ، ډیر بدلون موندلی. دا تاسو ته اجازه درکوي چې نږدې 3 ځله ګړندي ډیټا دننه کړئ او لږ HistoryCache وکاروئ - په وینا ، تاسو به په خپل وخت ډیټا تحویل کړئ. بیا بیا، په هر ثانیه کې 80 زره ارزښتونه خورا لوړ نرخ دی (البته، د Yandex لپاره نه). په ټولیز ډول دا یو خورا لوی ترتیب دی، د یو سرور سره.
PostgreSQL فعالیت ازموینه: 120 زره NVPs
بیا ، ما د ډیټا عناصرو شمیر نیم ملیون ته لوړ کړ او په هره ثانیه کې یې د 125 زره حساب شوي ارزښت ترلاسه کړ:
او ما دا ګرافونه ترلاسه کړل:
په اصل کې، دا یو کاري ترتیب دی، دا کولی شي د اوږدې مودې لپاره کار وکړي. مګر څنګه چې ما یوازې د 1,5 ټیرابایټ ډیسک درلود ، ما دا په څو ورځو کې وکارول. ترټولو مهمه خبره دا ده چې په ورته وخت کې په TimescaleDB کې نوې برخې رامینځته شوي، او دا د فعالیت لپاره په بشپړه توګه د پام وړ نه و، کوم چې د MySQL په اړه نشي ویل کیدی.
عموما، ویشونه د شپې رامینځته کیږي، ځکه چې دا عموما د میزونو سره داخلیدل او کار کول بندوي او کولی شي د خدماتو تخریب لامل شي. په دې حالت کې دا قضیه نه ده! اصلي دنده د TimescaleDB وړتیاو ازموینه وه. پایله لاندې شمیره وه: په هر ثانیه کې 120 زره ارزښتونه.
په ټولنه کې داسې مثالونه هم شته:
دغه کس TimescaleDB هم فعال کړ او د io.weight کارولو بار په پروسیسر کې راټیټ شو؛ او د داخلي پروسې عناصرو کارول هم د TimescaleDB شاملولو له امله کم شوي. سربیره پردې ، دا عادي پینکیک ډیسکونه دي ، دا په عادي ډیسکونو کې یو عادي مجازی ماشین دی (نه SSDs)!
د ځینې کوچني تنظیمونو لپاره چې د ډیسک فعالیت لخوا محدود دي ، TimescaleDB ، زما په نظر ، خورا ښه حل دی. دا به تاسو ته اجازه درکړي چې د ډیټابیس لپاره ګړندي هارډویر ته مهاجرت دمخه کار ته دوام ورکړئ.
زه تاسو ټولو ته زموږ پیښو ته بلنه ورکوم: په مسکو کې کنفرانس، په ریګا کې غونډه. زموږ چینلونه وکاروئ - ټیلیګرام، فورم، IRC. که تاسو کومه پوښتنه لرئ، زموږ میز ته راشئ، موږ کولی شو د هرڅه په اړه خبرې وکړو.
د اورېدونکو پوښتنې
د لیدونکو څخه پوښتنه (له دې وروسته - A): - که د TimescaleDB تنظیم کول خورا اسانه وي ، او دا ورته فعالیت ته وده ورکوي ، نو شاید دا باید د پوسټګریس سره د زبیکس تنظیم کولو لپاره د غوره تمرین په توګه وکارول شي؟ او ایا د دې حل کومې نیمګړتیاوې او زیانونه شتون لري ، یا په هرصورت ، که ما پریکړه وکړه چې د ځان لپاره زبیکس جوړ کړم ، زه کولی شم په اسانۍ سره پوسټګریس واخلم ، سمدلاسه هلته ټایمزکل نصب کړم ، وکاروئ او د کومې ستونزې په اړه فکر ونه کړئ؟
AG: - هو ، زه به ووایم چې دا یو ښه وړاندیز دی: د TimescaleDB توسیع سره سمدلاسه Postgres وکاروئ. لکه څنګه چې ما مخکې وویل، ډیری ښه بیاکتنې، سره له دې چې دا "ځانګړتیا" تجربه ده. مګر واقعیا ازموینې ښیې چې دا یو عالي حل دی (د TimescaleDB سره) او زه فکر کوم چې دا به وده وکړي! موږ څارنه کوو چې دا تمدید څنګه وده کوي او د اړتیا سره سم به بدلونونه رامینځته کړي.
حتی د پراختیا په جریان کې، موږ د دوی په یوه پیژندل شوي "ځانګړو" تکیه وکړه: دا ممکنه وه چې د ټوټو سره یو څه توپیر سره کار وکړو. مګر بیا دوی دا په راتلونکي ریلیز کې پرې کړل ، او موږ باید پدې کوډ تکیه کول بند کړو. زه به په ډیری ترتیبونو کې د دې حل کارولو وړاندیز وکړم. که تاسو MySQL کاروئ... د اوسط تنظیم کولو لپاره، هر حل ښه کار کوي.
مګر: - د ټولنې په وروستیو ګرافونو کې، د "کور ساتونکي" سره ګراف شتون درلود:
هغه کار ته دوام ورکړ. د کور ساتونکی د TimescaleDB سره څه کوي؟
AG: - اوس زه نشم کولی په ډاډ سره ووایم - زه به کوډ وګورم او تاسو ته به په ډیر تفصیل سره ووایم. دا د TimescaleDB پوښتنو څخه کار اخلي د ټوټو حذف کولو لپاره نه ، مګر په یو ډول د دوی راټولولو لپاره. زه لاهم چمتو نه یم چې دې تخنیکي پوښتنې ته ځواب ووایم. موږ به نن یا سبا په سټینډ کې نور معلومات ترلاسه کړو.
مګر: - زه ورته پوښتنه لرم - په Timescale کې د حذف کولو عملیاتو فعالیت په اړه.
الف (د لیدونکو څخه ځواب): - کله چې تاسو د میز څخه ډیټا حذف کوئ ، که تاسو دا د حذف کولو له لارې ترسره کوئ ، نو تاسو اړتیا لرئ د میز له لارې لاړشئ - حذف کړئ ، پاک کړئ ، د راتلونکي خلا لپاره هرڅه په نښه کړئ. په مهال ویش کې، ځکه چې تاسو ټوټې لرئ، تاسو کولی شئ پریږدئ. په لنډه توګه، تاسو په ساده ډول هغه فایل ته ووایاست چې په لوی ډیټا کې وي: "حذف کړئ!"
Timescale په ساده ډول پوهیږي چې دا ډول ټوټه نور شتون نلري. او له هغه وخته چې دا د پوښتنې پلانر کې مدغم شوی، دا د انتخاب یا نورو عملیاتو کې ستاسو د شرایطو د نیولو لپاره هک کاروي او سمدلاسه پوهیږي چې دا برخه نور شتون نلري - "زه به نور هلته نه ځم!" (ډیټا شتون نلري). بس نور څه نه! دا دی ، د میز سکین د بائنری فایل حذف کولو سره ځای په ځای شوی ، نو دا ګړندی دی.
مګر: - موږ دمخه د غیر SQL موضوع ته اشاره کړې. تر هغه ځایه چې زه پوهیږم، زبیبکس واقعیا اړتیا نلري چې ډاټا بدل کړي، او دا ټول د لاګ په څیر یو څه دي. ایا دا ممکنه ده چې ځانګړي ډیټابیسونه وکاروئ چې نشي کولی خپل ډیټا بدل کړي ، مګر په ورته وخت کې خورا ګړندي خوندي کوي ، راټولوي او توزیع کوي - کلیک هاوس ، د مثال په توګه ، د کافکا په څیر یو څه؟... کافکا هم یو لاګ دی! ایا دا ممکنه ده چې دوی یو څه یوځای کړئ؟
AG: - کښته کول کیدی شي. موږ د 3.4 نسخه راهیسې یو ځانګړی "خصوصیت" لرو: تاسو کولی شئ ټول تاریخي فایلونه، پیښې، هرڅه په فایلونو کې ولیکئ؛ او بیا یې د ځینې هینډلر په کارولو سره کوم بل ډیټابیس ته واستوئ. په حقیقت کې، ډیری خلک بیا کار کوي او مستقیم ډیټابیس ته لیکي. په الوتنه کې، د تاریخ ډوبونکي دا ټول په فایلونو کې لیکي، دا فایلونه وګرځوي، او داسې نور، او تاسو کولی شئ دا کلیک هاوس ته انتقال کړئ. زه نشم کولی د پلانونو په اړه ووایم، مګر شاید د NoSQL حلونو لپاره نور ملاتړ (لکه Clickhouse) به دوام ومومي.
مګر: - په عموم کې ، دا معلومه شوه چې تاسو کولی شئ په بشپړ ډول د پوسټګریس څخه خلاص شئ؟
AG: - البته، په زبکس کې ترټولو ستونزمن برخه تاریخي میزونه دي، کوم چې ډیری ستونزې او پیښې رامینځته کوي. په دې حالت کې، که تاسو د اوږدې مودې لپاره پیښې ذخیره نه کړئ او تاریخ په ځینو نورو ګړندۍ ذخیره کې د رجحاناتو سره ذخیره کړئ، نو په عموم کې، زه فکر کوم، کومه ستونزه به نه وي.
مګر: - ایا تاسو اټکل کولی شئ چې هر څه به څومره ګړندي کار وکړي که تاسو کلیک هاوس ته لاړشئ ، د مثال په توګه؟
AG: - ما دا ازموینه نه ده کړې. زه فکر کوم چې لږترلږه ورته شمیرې په ساده ډول ترلاسه کیدی شي ، دې ته په پام سره چې کلیک هاوس خپل انٹرفیس لري ، مګر زه په ډاډ سره نه شم ویلای. دا غوره ده چې ازموینه وکړئ. دا ټول په ترتیب پورې اړه لري: تاسو څومره کوربه لرئ، او داسې نور. داخلول یو شی دی، مګر تاسو اړتیا لرئ چې دا ډاټا بیرته ترلاسه کړئ - ګرافانا یا بل څه.
مګر: - نو موږ د مساوي مبارزې په اړه خبرې کوو ، او نه د دې ګړندي ډیټابیسونو لوی ګټې په اړه؟
AG: - زه فکر کوم کله چې موږ مدغم شو ، نو ډیرې دقیقې ازموینې به وي.
مګر: - ښه زوړ RRD چیرته لاړ؟ څه شی تاسو د SQL ډیټابیسونو ته اړولی؟ په پیل کې، ټول میټریکونه په RRD کې راټول شوي.
AG: - زبیکس RRD درلود، شاید په خورا پخوانی نسخه کې. دلته تل د SQL ډیټابیسونه شتون لري - یو کلاسیک چلند. کلاسیک چلند MySQL، PostgreSQL دی (دوی د ډیر وخت لپاره شتون لري). موږ تقریبا هیڅکله د SQL او RRD ډیټابیسونو لپاره یو عام انٹرفیس نه دی کارولی.
ځینې اعلانونه 🙂
له موږ سره د پاتې کیدو لپاره مننه. ایا تاسو زموږ مقالې خوښوي؟ غواړئ نور په زړه پورې مینځپانګه وګورئ؟ د امر په ورکولو یا ملګرو ته وړاندیز کولو سره زموږ ملاتړ وکړئ ، , د ننوتلو کچې سرورونو یو ځانګړی انلاګ ، کوم چې زموږ لخوا ستاسو لپاره اختراع شوی و: (د RAID1 او RAID10 سره شتون لري، تر 24 کور پورې او تر 40GB DDR4 پورې).
ډیل R730xd په امستردام کې د Equinix Tier IV ډیټا مرکز کې 2 ځله ارزانه؟ یوازې دلته په هالنډ کې! ډیل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - له $ 99 څخه! په اړه ولولئ
سرچینه: www.habr.com