په VictoriaMetrics کې اصلاح ته لاړ شئ. الکساندر ویلیالکین

زه وړاندیز کوم چې تاسو د الیګزانډر ویلیالکین لخوا د 2019 وروستي راپور نقل ولولئ "په ویکتوریا میټریکس کې اصلاح ته لاړشئ"

ویکتوریا میټریک - د وخت لړۍ په شکل کې د معلوماتو ذخیره کولو او پروسس کولو لپاره یو ګړندی او د توزیع وړ DBMS (ریکارډ وخت جوړوي او د دې وخت سره ورته ارزښتونو سیټ ، د مثال په توګه ، د سینسرونو حالت یا د راټولولو دوره کې د رایی ورکولو له لارې ترلاسه کیږي. میټریک).

د دې راپور د ویډیو لینک دلته اوریدلی شئ- https://youtu.be/MZ5P21j_HLE

سلایډونه

موږ ته د خپل ځان په اړه ووایه. زه الکساندر ویلیالکین یم. دلته زما د GitHub حساب. زه د Go او د فعالیت اصلاح کولو په اړه لیواله یم. ما ډیر ګټور او ډیر ګټور کتابتونونه لیکلي. دوی له یو سره پیل کوي fast، یا ورسره quick مخکینی

زه اوس مهال په VictoriaMetrics کې کار کوم. دا څه دي او زه هلته څه کوم؟ زه به پدې اړه پدې پریزنټشن کې خبرې وکړم.

د راپور بڼه په لاندې ډول ده:

• لومړی، زه به تاسو ته ووایم چې VictoriaMetrics څه شی دی.
• بیا به زه تاسو ته ووایم چې د وخت لړۍ څه دي.
• بیا به زه تاسو ته ووایم چې د وخت لړۍ ډیټابیس څنګه کار کوي.
• بل ، زه به تاسو ته د ډیټابیس جوړښت په اړه ووایم: دا څه شی لري.
• او بیا راځئ چې هغه اصلاحونو ته لاړ شو چې ویکتوریا میټریک لري. دا د بدل شوي شاخص لپاره اصلاح او په Go کې د بټ سیټ پلي کولو لپاره اصلاح دی.

ایا په لیدونکو کې څوک پوهیږي چې ویکتوریا میټریکس څه دی؟ واه، ډیری خلک لا دمخه پوهیږي. دا یو ښه خبر دی. د هغو کسانو لپاره چې نه پوهیږي، دا د وخت لړۍ ډیټابیس دی. دا د ClickHouse جوړښت پر بنسټ والړ دی، د ClickHouse پلي کولو ځینې توضیحاتو باندې. د مثال په توګه، لکه: MergeTree، په ټولو موجود پروسیسر کورونو کې موازي محاسبه او د ډیټا بلاکونو په کار کولو سره د فعالیت اصلاح کول چې د پروسیسر کیچ کې ځای په ځای شوي.

VictoriaMetrics د نورو وختونو لړۍ ډیټابیسونو په پرتله غوره ډیټا کمپریشن چمتو کوي.

دا عمودی اندازه کوي - دا دی، تاسو کولی شئ په یو کمپیوټر کې ډیر پروسیسرونه، ډیر RAM اضافه کړئ. VictoriaMetrics به په بریالیتوب سره دا موجودې سرچینې وکاروي او د خطي تولیداتو ته وده ورکړي.

VictoriaMetrics هم په افقي ډول اندازه کوي - دا دی، تاسو کولی شئ د VictoriaMetrics کلستر ته اضافي نوډونه اضافه کړئ، او د هغې فعالیت به تقریبا په خطي توګه لوړ شي.

لکه څنګه چې تاسو اټکل کړی، VictoriaMetrics یو ګړندی ډیټابیس دی، ځکه چې زه نشم کولی نور ولیکم. او دا په Go کې لیکل شوی ، نو زه پدې ناسته کې د هغې په اړه خبرې کوم.

څوک پوهیږي چې د وخت لړۍ څه ده؟ هغه هم ډیر خلک پیژني. د وخت لړۍ د جوړه جوړه لړۍ ده (timestamp, значение)، چیرې چې دا جوړه د وخت له مخې ترتیب شوي. ارزښت د تیر شوي نقطې شمیره ده - float64.

هر ځل لړۍ په ځانګړي ډول د کلیدي لخوا پیژندل کیږي. دا کلیمه څه شی لري؟ دا د کلیدي ارزښت جوړو غیر خالي سیټ څخه جوړ دی.

دلته د وخت لړۍ یوه بیلګه ده. د دې لړۍ کلیدي د جوړو لیست دی: __name__="cpu_usage" د میټریک نوم دی، instance="my-server" - دا هغه کمپیوټر دی چې په هغې کې دا میټریک راټول شوی، datacenter="us-east" - دا د معلوماتو مرکز دی چیرې چې دا کمپیوټر موقعیت لري.

موږ د وخت لړۍ نوم سره پای ته ورسیدو چې پکې درې کلیدي ارزښت لرونکي جوړه شامله وه. دا کلید د جوړو لیست سره مطابقت لري (timestamp, value). t1, t3, t3, ..., tN - دا مهال ویشونه دي، 10, 20, 12, ..., 15 - اړونده ارزښتونه. دا د ورکړل شوي لړۍ لپاره په ټاکل شوي وخت کې د cpu کارول دي.

د وخت لړۍ چیرته کارول کیدی شي؟ ایا څوک کوم نظر لري؟

• په DevOps کې، تاسو کولی شئ CPU، RAM، شبکه، rps، د غلطیو شمیر، او نور اندازه کړئ.
• IoT - موږ کولی شو د حرارت درجه، فشار، جیو همغږي او نور څه اندازه کړو.
• همدارنګه مالیه - موږ کولی شو د هر ډول سټاک او اسعارو نرخونه وڅیړو.
• سربیره پردې ، د وخت لړۍ په فابریکو کې د تولید پروسې نظارت کې کارول کیدی شي. موږ هغه کارونکي لرو چې د روبوټونو لپاره د باد توربینونو څارلو لپاره VictoriaMetrics کاروي.
• د وخت لړۍ د مختلفو وسیلو سینسرونو څخه د معلوماتو راټولولو لپاره هم ګټورې دي. د مثال په توګه، د انجن لپاره؛ د ټایر فشار اندازه کولو لپاره؛ د سرعت اندازه کولو لپاره، فاصله؛ د ګازو د مصرف اندازه کولو لپاره، او نور
• د وخت لړۍ هم د الوتکو څارلو لپاره کارول کیدی شي. هره الوتکه یو تور بکس لري چې د الوتکې د روغتیا مختلف پیرامیټونو لپاره د وخت لړۍ راټولوي. د وخت لړۍ هم د فضا صنعت کې کارول کیږي.
• روغتیایی پاملرنه د وینی فشار، نبض او نور دی.

ممکن ډیر غوښتنلیکونه شتون ولري چې ما یې هیر کړی ، مګر زه امید لرم چې تاسو پوهیږئ چې د وخت لړۍ په عصري نړۍ کې په فعاله توګه کارول کیږي. او د دوی د کارولو حجم هر کال وده کوي.

تاسو ولې د وخت لړۍ ډیټابیس ته اړتیا لرئ؟ ولې تاسو نشي کولی د وخت لړۍ ذخیره کولو لپاره منظم اړونده ډیټابیس وکاروئ؟

ځکه چې د وخت لړۍ معمولا د معلوماتو لوی مقدار لري، کوم چې په دودیز ډیټابیسونو کې ذخیره کول او پروسس کول ستونزمن دي. له همدې امله، د وخت لړۍ لپاره ځانګړي ډیټابیسونه ښکاره شول. دا اډې په مؤثره توګه ټکي ذخیره کوي (timestamp, value) د ورکړل شوي کیلي سره. دوی د کیلي په واسطه ذخیره شوي ډیټا لوستلو لپاره API چمتو کوي ، د یو واحد کلیدي ارزښت جوړه ، یا د څو کلیدي ارزښت جوړو لخوا ، یا د regexp لخوا. د مثال په توګه ، تاسو غواړئ د خپلو ټولو خدماتو CPU بار په متحده ایالاتو کې د ډیټا مرکز کې ومومئ ، نو تاسو اړتیا لرئ دا pseudo-query وکاروئ.

معمولا د وخت لړۍ ډیټابیسونه ځانګړي پوښتنې ژبې چمتو کوي ځکه چې د وخت لړۍ SQL ډیر مناسب نه دی. که څه هم داسې ډیټابیسونه شتون لري چې د SQL ملاتړ کوي، دا خورا مناسب نه دی. د پوښتنو ژبې لکه PromQL, InfluxQL, بهيږي, Q. زه امید لرم چې یو څوک لږترلږه یو له دې ژبو څخه اوریدلی وي. ډیری خلکو شاید د PromQL په اړه اوریدلي وي. دا د Prometheus پوښتنې ژبه ده.

دا هغه څه دي چې د عصري وخت لړۍ ډیټابیس جوړښت د مثال په توګه د VictoriaMetrics کارولو په څیر ښکاري.

دا د دوو برخو څخه جوړه ده. دا د بدل شوي شاخص لپاره ذخیره او د وخت لړۍ ارزښتونو لپاره ذخیره ده. دا ذخیره جلا شوي دي.

کله چې یو نوی ریکارډ ډیټابیس ته راشي، موږ لومړی د ورکړل شوي سیټ لپاره د وخت لړۍ پیژندونکي موندلو لپاره التهاب شوي شاخص ته لاسرسی ومومئ label=value د ورکړل شوي میټریک لپاره. موږ دا پیژندونکی پیدا کوو او د ډیټا ذخیره کې ارزښت خوندي کوو.

کله چې د TSDB څخه د معلوماتو بیرته ترلاسه کولو غوښتنه راځي، موږ لومړی د انډول شوي شاخص ته ځو. راځئ چې هرڅه ترلاسه کړو timeseries_ids هغه ریکارډونه چې د دې سیټ سره سمون لري label=value. او بیا موږ ټول اړین معلومات د ډیټا ګودام څخه ترلاسه کوو ، د لخوا ترتیب شوي timeseries_ids.

راځئ چې یو مثال وګورو چې څنګه د وخت لړۍ ډیټابیس د راتلونکي انتخاب پوښتنې پروسس کوي.

• لومړی هغه هرڅه ترلاسه کوي timeseries_ids د یو بدل شوي شاخص څخه چې ورکړل شوي جوړه لري label=value، یا ورکړل شوی منظم بیان مطمین کړئ.
• بیا دا د موندلو لپاره په ټاکل شوي وخت وقفه کې د ډیټا ذخیره کولو څخه ټول ډیټا ټکي ترلاسه کوي timeseries_ids.
• له دې وروسته، ډیټابیس د کاروونکو غوښتنې سره سم، د دې ډیټا ټکو په اړه ځینې محاسبې ترسره کوي. او له هغې وروسته دا ځواب بیرته راګرځوي.

پدې پریزنټشن کې به زه تاسو ته د لومړۍ برخې په اړه ووایم. دا یو لټون دی timeseries_ids د متغیر شاخص په واسطه. دوهمه برخه او دریمه برخه یې وروسته کتلای شئ د ویکتوریا میټریک سرچینې، یا انتظار وکړئ تر څو چې زه نور راپورونه چمتو کړم :)

راځئ چې د انډول شوي شاخص ته لاړ شو. ډیری شاید فکر وکړي چې دا ساده دی. څوک پوهیږي چې متوجه شاخص څه شی دی او دا څنګه کار کوي؟ او اوس دومره خلک نه دي. راځئ هڅه وکړو چې پوه شو چې دا څه دي.

دا واقعا ساده ده. دا په ساده ډول یو قاموس دی چې د ارزښت لپاره کلیدي نقشه کوي. کلیدي څه ده؟ دا جوړه label=valueچیرته label и value - دا کرښې دي. او ارزښتونه یوه جوړه ده timeseries_idsپه کوم کې چې ورکړل شوې جوړه شامله ده label=value.

بدل شوی شاخص تاسو ته اجازه درکوي ژر تر ژره هرڅه ومومئ timeseries_ids، کوم چې ورکړي دي label=value.

دا تاسو ته اجازه درکوي چې ژر تر ژره ومومئ timeseries_ids د څو جوړه لپاره د وخت لړۍ label=value، یا د جوړه لپاره label=regexp. دا څنګه کیږي؟ د سیټ د تقاطع په موندلو سره timeseries_ids د هرې جوړې لپاره label=value.

راځئ چې د بدل شوي شاخص مختلف تطبیقونه وګورو. راځئ چې د ساده ساده پلي کولو سره پیل وکړو. هغه داسې ښکاري.

دنده getMetricIDs د تارونو لیست ترلاسه کوي. هره کرښه لري label=value. دا فنکشن یو لیست بیرته راګرځوي metricIDs.

څنګه کار کوي؟ دلته موږ یو نړیوال متغیر لرو چې نوم یې دی invertedIndex. دا یو منظم قاموس دی (map)، کوم چې به د انټ ټوټې کولو لپاره تار نقشه کړي. کرښه لري label=value.

د فعالیت پلي کول: ترلاسه کړئ metricIDs د لومړي لپاره label=value، بیا موږ هر څه ته ځو label=value، موږ یې ترلاسه کوو metricIDs د هغوئ لپاره. او فنکشن ته زنګ ووهئ intersectInts، کوم چې به لاندې بحث وشي. او دا فنکشن د دې لیستونو تقاطع راګرځوي.

لکه څنګه چې تاسو لیدلی شئ، د بدل شوي شاخص پلي کول خورا پیچلي ندي. مګر دا یو ساده تطبیق دی. کوم زیانونه لري؟ د ساده پلي کولو اصلي نیمګړتیا دا ده چې دا ډول بدل شوی شاخص په رام کې زیرمه شوی. د غوښتنلیک بیا پیل کولو وروسته موږ دا شاخص له لاسه ورکوو. په ډیسک کې د دې شاخص خوندي کول شتون نلري. دا ډول بدل شوی شاخص د ډیټابیس لپاره مناسب نه دی.

دوهم نیمګړتیا هم د حافظې سره تړاو لري. بدل شوی شاخص باید په رام کې فټ شي. که دا د رام له اندازې څخه ډیر وي ، نو په څرګنده توګه به موږ ترلاسه کړو - د حافظې غلطۍ څخه بهر. او برنامه به کار ونکړي.

دا ستونزه د چمتو شوي حلونو په کارولو سره حل کیدی شي لکه کچه ډبلیو، یا RocksDB.

په لنډه توګه، موږ یو ډیټابیس ته اړتیا لرو چې موږ ته اجازه راکوي چې درې عملیات په چټکۍ سره ترسره کړو.

• لومړی عملیات ثبت کول دي ключ-значение دې ډیټابیس ته. هغه دا کار په چټکۍ سره کوي، چیرته ключ-значение خپلمنځي تارونه دي.
• دوهم عملیات د ورکړل شوي کیلي په کارولو سره د ارزښت لپاره ګړندي لټون دی.
• او دریم عملیات د ورکړل شوي مخفف لخوا د ټولو ارزښتونو لپاره ګړندي لټون دی.

LevelDB او RocksDB - دا ډیټابیسونه د ګوګل او فیسبوک لخوا رامینځته شوي. لومړی راغلی LevelDB. بیا د فیسبوک څخه هلکانو LevelDB واخیست او د هغې ښه کول یې پیل کړل، دوی RocksDB جوړ کړ. اوس نږدې ټول داخلي ډیټابیسونه په فېسبوک کې دننه په RocksDB کې کار کوي، په شمول هغه چې RocksDB او MySQL ته لیږدول شوي. دوی هغه نوم کړ MyRocks.

یو بدل شوی شاخص د LevelDB په کارولو سره پلي کیدی شي. دا څنګه وکړو؟ موږ د کیلي په توګه خوندي کوو label=value. او ارزښت د وخت لړۍ پیژندونکی دی چیرې چې جوړه شتون لري label=value.

که موږ د ورکړل شوي جوړه سره ډیری وخت لړۍ لرو label=valueبیا به په دې ډیټابیس کې د ورته کیلي او مختلف سره ډیری قطارونه وي timeseries_ids. د ټولو لیست ترلاسه کولو لپاره timeseries_ids، کوم چې له دې سره پیل کیږي label=prefix، موږ یو رینج سکین کوو د کوم لپاره چې دا ډیټابیس غوره شوی. دا دی، موږ ټول هغه کرښې غوره کوو چې پیل کیږي label=prefix او اړین ترلاسه کړئ timeseries_ids.

دلته د نمونې پلي کول دي چې دا به په Go کې څه ښکاري. موږ یو متوجه شاخص لرو. دا LevelDB دی.

فعالیت د ساده پلي کولو لپاره ورته دی. دا تقریبا په لیکه کې ساده پلي کول تکراروي. یوازینی ټکی دا دی چې د دې پرځای چې مخ واړوي map موږ متوجه شاخص ته لاسرسی لرو. موږ د لومړي لپاره ټول ارزښتونه ترلاسه کوو label=value. بیا موږ د ټولو پاتې جوړو له لارې ځو label=value او د دوی لپاره د میټریک IDs ورته سیټونه ترلاسه کړئ. بیا موږ تقاطع پیدا کوو.

هرڅه سم ښکاري، مګر پدې حل کې نیمګړتیاوې شتون لري. VictoriaMetrics په پیل کې د LevelDB پراساس یو بدل شوی شاخص پلي کړ. مګر په پای کې ما باید دا پریښوده.

ولې؟ ځکه چې LevelDB د ساده پلي کولو په پرتله ورو دی. په ساده پلي کولو کې ، ورکړل شوي کیلي ته ورکړل شوي ، موږ سمدلاسه ټوله ټوټه بیرته ترلاسه کوو metricIDs. دا یو ډیر چټک عملیات دی - ټوله ټوټه د کارونې لپاره چمتو ده.

په LevelDB کې، هرکله چې فنکشن ویل کیږي GetValues تاسو اړتیا لرئ د ټولو لینونو څخه تیر شئ چې پیل کیږي label=value. او د هرې کرښې لپاره ارزښت ترلاسه کړئ timeseries_ids. د داسې timeseries_ids د دې یوه ټوټه راټول کړئ timeseries_ids. په ښکاره ډول، دا د کیلي په واسطه منظم نقشې ته د لاسرسي په پرتله خورا ورو دی.

دویمه نیمګړتیا دا ده چې LevelDB په C کې لیکل شوی. له Go څخه د C فنکشن کال کول خورا ګړندي ندي. دا په سلګونو نانو ثانیې وخت نیسي. دا خورا ګړندی ندی ، ځکه چې په ګو کې لیکل شوي منظم فنکشن کال په پرتله ، کوم چې 1-5 نانو ثانیه نیسي ، په فعالیت کې توپیر لسګونه ځله دی. د VictoriaMetrics لپاره دا یوه وژونکې نیمګړتیا وه :)

نو ما د خپل انډول شوي شاخص پلي کول لیکلي. او هغه ورته غږ کړ یوځای کول.

Mergeset د MergeTree ډاټا جوړښت پر بنسټ والړ دی. د دې معلوماتو جوړښت د ClickHouse څخه پور اخیستل شوی. په ښکاره ډول، ضم کول باید د چټک لټون لپاره غوره شي timeseries_ids د ورکړل شوي کیلي مطابق. Mergeset په بشپړ ډول په Go کې لیکل شوی. تاسو لیدلی شئ په GitHub کې د VictoriaMetrics سرچینې. د mergeset تطبیق په فولډر کې دی /lib/mergeset. تاسو کولی شئ هڅه وکړئ معلومه کړئ چې هلته څه پیښیږي.

mergeset API د LevelDB او RocksDB سره ورته دی. دا دی، دا تاسو ته اجازه درکوي په چټکۍ سره نوي ریکارډونه خوندي کړئ او په چټکۍ سره د ورکړل شوي مخفف لخوا ریکارډونه غوره کړئ.

موږ به وروسته د ادغام د زیانونو په اړه وغږیږو. اوس راځئ چې په دې اړه وغږیږو چې په تولید کې د ویکتوریا میټریکس سره کومې ستونزې رامینځته شوې کله چې د بدل شوي شاخص پلي کول.

دوی ولې راپورته شول؟

لومړی دلیل د لوړ سوځیدنې کچه ده. په روسیه کې ژباړل شوی، دا د وخت په لړۍ کې پرله پسې بدلون دی. دا هغه وخت دی چې د وخت لړۍ پای ته رسیږي او نوې لړۍ پیل کیږي، یا ډیری نوي وخت لړۍ پیل کیږي. او دا ډیری وختونه پیښیږي.

دوهم دلیل د وخت لړۍ لوی شمیر دی. په پیل کې، کله چې څارنه د شهرت ترلاسه کول، د وخت لړۍ کوچنۍ وه. د مثال په توګه، د هر کمپیوټر لپاره تاسو اړتیا لرئ د CPU، حافظې، شبکې او ډیسک بار څارنه وکړئ. په هر کمپیوټر کې د 4 وخت لړۍ. راځئ چې ووایو تاسو 100 کمپیوټرونه او 400 وخت لړۍ لرئ. دا ډیر لږ دی.

د وخت په تیریدو سره، خلکو معلومه کړه چې دوی کولی شي نور دانه معلومات اندازه کړي. د مثال په توګه، د ټول پروسیسر بار نه، مګر د هر پروسیسر کور په جلا توګه اندازه کړئ. که تاسو 40 پروسیسر کورونه لرئ، نو تاسو د پروسیسر بار اندازه کولو لپاره 40 ځله ډیر وخت لړۍ لرئ.

مګر دا ټول نه دي. د هر پروسیسر کور کولی شي څو حالتونه ولري، لکه بیکاره، کله چې بې کاره وي. او د کارن ځای کې هم کار وکړئ ، د کرنل ځای او نورو ایالتونو کې کار وکړئ. او هر دا ډول حالت د جلا وخت لړۍ په توګه هم اندازه کیدی شي. دا سربیره پردې د قطارونو شمیر 7-8 ځله زیاتوي.

د یو میټریک څخه موږ یوازې د یو کمپیوټر لپاره 40 x 8 = 320 میټریکونه ترلاسه کړل. د 100 سره ضرب کړئ، موږ د 32 پر ځای 000 ترلاسه کوو.

بیا کبرنیټس هم راغی. او دا خراب شو ځکه چې کوبرنیټس کولی شي ډیری مختلف خدمات کوربه کړي. په Kubernetes کې هر خدمت ډیری پوډونه لري. او دا ټول باید وڅیړل شي. برسېره پردې، موږ ستاسو د خدماتو نوي نسخې په دوامداره توګه ځای پرځای کوو. د هرې نوې نسخې لپاره، د نوي وخت لړۍ باید رامینځته شي. د پایلې په توګه، د وخت لړۍ په چټکۍ سره وده کوي او موږ د ډیری وخت لړۍ له ستونزې سره مخ یو، کوم چې د لوړ کارډینالیت په نوم یادیږي. VictoriaMetrics د نورو وختونو لړۍ ډیټابیسونو په پرتله په بریالیتوب سره د دې سره کاپي کوي.

راځئ چې د لوړ غلظت نرخ ته نږدې وګورو. څه شی په تولید کې د لوړ غلظت نرخ لامل کیږي؟ ځکه چې د لیبلونو او ټګونو ځینې معنی په دوامداره توګه بدلیږي.

د مثال په توګه، Kubernetes واخلئ، کوم چې مفهوم لري deployment، د مثال په توګه کله چې ستاسو د غوښتنلیک نوې نسخه راپورته کیږي. د ځینو دلیلونو لپاره، د کوبرنیټس پراختیا کونکو پریکړه وکړه چې په لیبل کې د ځای پرځای کولو ID اضافه کړي.

دا څه لامل شو؟ سربیره پردې ، د هر نوي ځای په ځای کولو سره ، ټول زاړه وخت لړۍ مداخله کیږي ، او د دوی پرځای ، د نوي وخت لړۍ د نوي لیبل ارزښت سره پیل کیږي. deployment_id. دلته په سلګونو زره او حتی ملیونونه داسې قطارونه کیدی شي.

د دې ټولو په اړه مهم شی دا دی چې د وخت سلسلې شمیره وده کوي، مګر د وخت لړۍ شمیر چې اوس مهال فعال دي او ډاټا ترلاسه کوي ثابت پاتې دي. دې حالت ته د لوړ غلو نرخ ویل کیږي.

د لوړې کچې نرخ اصلي ستونزه دا ده چې د یو ټاکلي وخت وقفې په اوږدو کې د لیبلونو ټاکل شوي سیټ لپاره د هر وخت لړۍ لپاره د دوامداره لټون سرعت یقیني کړي. معمولا دا د وروستي ساعت یا وروستۍ ورځې لپاره د وخت وقفه ده.

دا ستونزه څنګه حل کړو؟ دلته لومړی اختیار دی. دا د وخت په تیریدو سره د بدلیدونکي شاخص په خپلواکو برخو ویشل دي. دا چې یو څه وخت وقفه تیریږي، موږ د اوسني بدل شوي شاخص سره کار پای ته ورسوو. او یو نوی بدل شوی شاخص جوړ کړئ. بل وخت وقفه تیریږي، موږ یو بل او بل جوړوو.

او کله چې د دې بدل شوي شاخصونو څخه نمونه اخلئ، موږ د انډول شوي شاخصونو یوه ټولګه پیدا کوو چې په ورکړل شوي وقفه کې راځي. او، په دې اساس، موږ له هغه ځایه د وخت لړۍ ID غوره کوو.

دا سرچینې خوندي کوي ځکه چې موږ اړتیا نلرو هغه برخې وګورو چې په ورکړل شوي وقفه کې نه راځي. دا، معمولا، که موږ د وروستي ساعت لپاره ډاټا وټاکو، نو د تیرو وخت وقفو لپاره موږ غوښتنې پریږدو.

د دې ستونزې د حل لپاره بله لاره شتون لري. دا د هرې ورځې لپاره د وخت لړۍ IDs جلا لیست ذخیره کول دي چې پدې ورځ پیښ شوي.

د پخوانۍ حل په پرتله د دې حل ګټه دا ده چې موږ د وخت لړۍ معلومات نه نقل کوو چې د وخت په تیریدو سره ورک نشي. دوی په دوامداره توګه شتون لري او بدلون نه کوي.

نیمګړتیا دا ده چې دا ډول حل پلي کول خورا ستونزمن دي او د ډیبګ کول خورا ستونزمن دي. او VictoriaMetrics دا حل غوره کړ. دا څنګه په تاریخي توګه پیښ شوي. دا حل هم د تیر په پرتله ښه فعالیت کوي. ځکه چې دا حل د دې حقیقت له امله پلي شوی نه و چې دا اړینه ده چې د وخت لړۍ لپاره په هره برخه کې ډیټا نقل کړي چې بدلون نه کوي ، د بیلګې په توګه د وخت په تیریدو سره ورک نشي. VictoriaMetrics په اصل کې د ډیسک ځای مصرف لپاره غوره شوی و، او پخوانی تطبیق د ډیسک ځای مصرف خراب کړ. مګر دا تطبیق د ډیسک ځای مصرف کمولو لپاره غوره دی، نو دا غوره شوی.

زه باید د هغې سره جګړه وکړم. مبارزه دا وه چې پدې پلي کولو کې تاسو لاهم اړتیا لرئ خورا لوی شمیر غوره کړئ timeseries_ids د ډیټا لپاره کله چې برعکس شاخص د وخت ویشل شوی وي.

موږ دا ستونزه څنګه حل کړه؟ موږ دا په اصلي طریقه حل کړه - د یو پیژندونکي پرځای په هر بدل شوي شاخص ننوتلو کې د څو ځله لړۍ پیژندونکو ذخیره کولو سره. دا، موږ یو کلی لرو label=value، کوم چې د هر وخت لړۍ کې پیښیږي. او اوس موږ څو خوندي کوو timeseries_ids په یوه داخله کې.

دلته یو مثال دی. پخوا موږ د N ننوتنې درلودې، مګر اوس موږ یو ننوت لرو چې مخکینی یې د نورو ټولو په څیر دی. د پخوانۍ ننوتلو لپاره، ارزښت د ټولو وختونو لړۍ IDs لري.

دا د دې امکان رامینځته کړی چې د داسې بدل شوي شاخص سکین کولو سرعت 10 ځله زیات کړي. او دا موږ ته اجازه راکړه چې د کیچ لپاره د حافظې مصرف کم کړو، ځکه چې اوس موږ تار ذخیره کوو label=value یوازې یو ځل په کیچ کې یوځای N ځله. او دا لاین لوی کیدی شي که تاسو په خپلو ټاګونو او لیبلونو کې اوږدې لینونه ذخیره کړئ ، کوم چې کوبرنیټس خوښوي چې هلته وغورځوي.

په بدل شوي شاخص کې د لټون ګړندي کولو لپاره بل اختیار شارډینګ دی. د یو پر ځای د څو متضاد شاخصونو رامینځته کول او د کیلي په واسطه د دوی ترمینځ ډیټا شریکول. دا یوه جوړه ده key=value بخار دا دی، موږ ډیری خپلواک انډول شوي شاخصونه ترلاسه کوو، کوم چې موږ کولی شو په څو پروسیسرونو موازي پوښتنې وکړو. مخکیني تطبیق یوازې په واحد پروسیسر حالت کې د عملیاتو اجازه درلوده، د بیلګې په توګه، یوازې په یوه کور کې د ډاټا سکین کول. دا حل تاسو ته اجازه درکوي په یوځل کې په څو کورونو کې ډیټا سکین کړئ ، لکه څنګه چې کلیک هاوس یې خوښوي. دا هغه څه دي چې موږ یې د پلي کولو پلان لرو.

اوس راځو خپلو پسونو ته - د تقاطع فعالیت ته timeseries_ids. راځئ چې په پام کې ونیسو چې کوم پلي کول ممکن وي. دا فنکشن تاسو ته د موندلو اجازه درکوي timeseries_ids د ورکړل شوي سیټ لپاره label=value.

لومړی اختیار یو ساده تطبیق دی. دوه ځړول شوي لوپونه. دلته موږ د فنکشن ان پټ ترلاسه کوو intersectInts دوه ټوټې - a и b. په محصول کې، دا باید موږ ته د دې ټوټو تقاطع بیرته راشي.

یو ساده تطبیق داسې ښکاري. موږ د ټوټې څخه ټول ارزښتونه تکرار کوو a، د دې لوپ دننه موږ د ټوټې ټول ارزښتونو ته ځو b. او موږ دوی پرتله کوو. که دوی سره سمون ولري، نو موږ یو تقاطع موندلی دی. او په کې یې خوندي کړئ result.

زیانونه یې څه دي؟ د څلور اړخیز پیچلتیا اصلي نیمګړتیا ده. د مثال په توګه، که ستاسو ابعاد ټوټه ټوټه وي a и b په یو وخت کې یو ملیون، نو دا فعالیت به هیڅکله تاسو ته ځواب بیرته نه راوړي. ځکه چې دا به یو ټریلیون تکرارونو ته اړتیا ولري، کوم چې حتی د عصري کمپیوټرونو لپاره خورا ډیر دی.

دوهم تطبیق د نقشې پر بنسټ دی. موږ نقشه جوړوو. موږ ټول ارزښتونه له ټوټې څخه په دې نقشه کې واچوو a. بیا موږ په جلا لوپ کې د ټوټې له لارې ځو b. او موږ ګورو چې ایا دا ارزښت د سلائس څخه دی b په نقشه کې که دا شتون ولري، نو بیا یې پایلې ته اضافه کړئ.

ګټې څه دي؟ ګټه دا ده چې یوازې خطي پیچلتیا شتون لري. دا دی، فنکشن به د لویو ټوټو لپاره خورا ګړندی اجرا کړي. د یو ملیون اندازې ټوټې لپاره، دا فنکشن به په 2 ملیون تکرارونو کې اجرا شي، لکه څنګه چې د تیر فعالیت ټریلیون تکرارونو سره مخالف دی.

منفي اړخ دا دی چې دا فنکشن د دې نقشې جوړولو لپاره ډیرې حافظې ته اړتیا لري.

دوهم نیمګړتیا د هش کولو لپاره لوی سر دی. دا نیمګړتیا ډیره څرګنده نه ده. او زموږ لپاره دا هم خورا څرګند نه و ، نو په لومړي سر کې په ویکتوریا میټریک کې د تقاطع پلي کول د نقشې له لارې و. مګر بیا پروفایل وښودله چې اصلي پروسیسر وخت نقشې ته لیکلو او پدې نقشه کې د ارزښت شتون چیک کولو کې مصرف کیږي.

ولې په دې ځایونو کې د CPU وخت ضایع کیږي؟ ځکه چې Go په دې لینونو کې د هیشینګ عملیات ترسره کوي. دا دی، دا د کیلي هش محاسبه کوي ترڅو بیا په HashMap کې ورکړل شوي شاخص ته لاسرسی ومومي. د هش محاسبه عملیات په لسګونو نانو ثانیو کې بشپړ شوي. دا د VictoriaMetrics لپاره ورو دی.

ما پریکړه وکړه چې د دې قضیې لپاره په ځانګړي ډول مطلوب بټ سیټ پلي کړم. دا هغه څه دي چې د دوه سلیزو تقاطع اوس داسې ښکاري. دلته موږ یو بټ سیټ جوړوو. موږ دې ته د لومړۍ ټوټې څخه عناصر اضافه کوو. بیا موږ په دویمه ټوټه کې د دې عناصرو شتون وګورو. او په پایله کې یې اضافه کړئ. دا دی، دا تقریبا د تیر مثال څخه توپیر نلري. دلته یوازینی شی دا دی چې موږ نقشې ته لاسرسی د دودیز افعال سره بدل کړ add и has.

په لومړي نظر کې، داسې ښکاري چې دا باید ورو کار وکړي، که مخکې هلته یو معیاري نقشه کارول شوې وي، او بیا ځینې نور فعالیتونه بلل کیږي، مګر پروفایل کول ښیې چې دا شی د ویکتوریا میټریک په قضیه کې د معیاري نقشې په پرتله 10 ځله ګړندی کار کوي.

سربیره پردې ، دا د نقشې پلي کولو په پرتله خورا لږ حافظه کاروي. ځکه چې موږ دلته د اتو بایټ ارزښتونو پرځای بټونه ذخیره کوو.

د دې پلي کولو نیمګړتیا دا ده چې دا دومره څرګند نه دی، نه کوچنی.

یو بل نیمګړتیا چې ډیری یې پام نه کوي دا دی چې دا پلي کول ممکن په ځینو مواردو کې ښه کار ونکړي. دا دی، دا د یوې ځانګړې قضیې لپاره مطلوب دی، د دې قضیې لپاره د ویکتوریا میټریک وخت لړۍ ids تقاطع. دا پدې معنی ندي چې دا د ټولو قضیو لپاره مناسب دی. که دا په غلطه توګه وکارول شي، موږ به د فعالیت زیاتوالی ترلاسه نکړو، مګر د حافظې څخه بهر تېروتنه او په فعالیت کې سست.

راځئ چې د دې جوړښت پلي کولو ته پام وکړو. که تاسو غواړئ وګورئ، دا د VictoriaMetrics سرچینې په فولډر کې موقعیت لري lib/uint64set. دا په ځانګړي ډول د ویکتوریا میټریکس قضیې لپاره مطلوب دی ، چیرې چې timeseries_id د 64-bit ارزښت دی، چیرې چې لومړی 32 بټونه اساسا ثابت دي او یوازې وروستي 32 بټونه بدلیږي.

دا ډاټا جوړښت په ډیسک کې نه ساتل کیږي، دا یوازې په حافظه کې کار کوي.

دلته د هغې API دی. دا ډیر پیچلی ندی. API په ځانګړې توګه د VictoriaMetrics کارولو ځانګړي مثال سره سمون لري. دا دی، دلته هیڅ غیر ضروري دندې شتون نلري. دلته هغه دندې دي چې په ښکاره ډول د ویکتوریا میټریک لخوا کارول کیږي.

دندې شتون لري add، کوم چې نوي ارزښتونه اضافه کوي. یو فعالیت شتون لري has، کوم چې د نوي ارزښتونو لپاره چک کوي. او فعالیت شتون لري del، کوم چې ارزښتونه لرې کوي. یو مرستندویه فعالیت شتون لري len، کوم چې د سیټ اندازه بیرته راګرځوي. فعالیت clone ډیر کلون کوي. او فعالیت appendto دا سیټ په ټوټه بدلوي timeseries_ids.

دا هغه څه دي چې د دې ډاټا جوړښت پلي کول ورته ښکاري. سیټ دوه عناصر لري:

• ItemsCount یو مرستندویه ساحه ده چې ژر تر ژره په یوه سیټ کې د عناصرو شمیر بیرته راستانه کړي. دا به ممکنه وي چې د دې مرستندویه ساحې پرته ترسره شي، مګر دا باید دلته اضافه شي ځکه چې VictoriaMetrics ډیری وختونه په خپل الګوریتم کې د بټ سیټ اوږدوالی پوښتنه کوي.

• دوهم ډګر دی buckets. دا د جوړښت څخه ټوټه ده bucket32. هر جوړښت ذخیره کوي hi میدان دا پورتنۍ 32 بټونه دي. او دوه ټوټې - b16his и buckets د bucket16 جوړښتونه

د 16-bit جوړښت د دویمې برخې پورته 64 بټونه دلته زیرمه شوي. او دلته بټ سیټونه د هر بایټ ټیټ 16 بټونو لپاره زیرمه شوي.

Bucket64 له یوه صف څخه جوړه ده uint64. اوږدوالی د دې ثابتو په کارولو سره محاسبه کیږي. په یوه کې bucket16 اعظمي ذخیره کیدی شي 2^16=65536 بټ که تاسو دا په 8 ویشئ، نو دا 8 کیلوبایټ دی. که تاسو بیا په 8 ویشئ، دا 1000 دی uint64 معنی هغه دی Bucket16 - دا زموږ د 8 کیلوبایټ جوړښت دی.

راځئ وګورو چې د نوي ارزښت اضافه کولو لپاره د دې جوړښت یوه میتود څنګه پلي کیږي.

دا ټول سره پیل کیږي uint64 معنی موږ پورتنۍ 32 بټونه محاسبه کوو، موږ ټیټ 32 بټونه محاسبه کوو. راځئ چې د هرڅه له لارې لاړ شو buckets. موږ په هر بالټ کې پورته 32 بټونه د ارزښت اضافه کولو سره پرتله کوو. او که دوی سره سمون ولري، نو موږ فنکشن بولو add په جوړښت کې b32 buckets. او هلته ښکته 32 بټونه اضافه کړئ. او که بیرته راستانه شو true، نو دا پدې مانا ده چې موږ هلته داسې ارزښت اضافه کړ او موږ داسې ارزښت نه درلود. که بیرته راشي falseنو بیا دا ډول معنی لا دمخه شتون لري. بیا موږ په جوړښت کې د عناصرو شمیر ډیروو.

که موږ هغه څوک ونه موندلو چې تاسو ورته اړتیا لرئ bucket د اړتیا وړ لوړ ارزښت سره، بیا موږ فنکشن ته زنګ وهو addAlloc، کوم چې به یو نوی تولید کړي bucket، دا د بالټ جوړښت ته اضافه کول.

دا د فعالیت پلي کول دي b32.add. دا د تیر تطبیق سره ورته دی. موږ خورا مهم 16 بټونه محاسبه کوو، لږترلږه د پام وړ 16 بټونه.

بیا موږ ټولو پورتنیو 16 بټونو ته ځو. موږ میچونه پیدا کوو. او که چیرې لوبه وي، موږ د اضافې طریقه بولو، کوم چې موږ به یې په راتلونکې پاڼه کې په پام کې ونیسو bucket16.

او دلته ترټولو ټیټه کچه ده، کوم چې باید د امکان تر حده اصلاح شي. موږ لپاره محاسبه کوو uint64 د id ارزښت په ټوټه ټوټه او همدارنګه bitmask. دا د ورکړل شوي 64-bit ارزښت لپاره ماسک دی ، کوم چې د دې بټ شتون چیک کولو لپاره کارول کیدی شي ، یا یې تنظیم کړئ. موږ وګورو چې ایا دا بټ ترتیب شوی او تنظیم یې کړی، او شتون بیرته راګرځوي. دا زموږ تطبیق دی، کوم چې موږ ته اجازه راکړه چې د دودیزو نقشو په پرتله د 10 ځله د وخت لړۍ د قطع کولو ids عملیات ګړندی کړو.

د دې اصلاح سربیره، VictoriaMetrics ډیری نور اصلاحونه لري. ډیری دا اصلاحات د یو دلیل لپاره اضافه شوي، مګر په تولید کې د کوډ پروفایل کولو وروسته.

دا د اصلاح کولو اصلي قاعده ده - د اصلاح کولو اضافه مه کوئ فرض کړئ چې دلته به یو خنډ وي، ځکه چې دا به وګرځي چې هلته به خنډ شتون ونلري. اصلاح کول معمولا د کوډ کیفیت خرابوي. له همدې امله ، دا یوازې د پروفایل کولو وروسته او په غوره توګه په تولید کې د مطلوب کولو ارزښت لري ، نو دا ریښتیني معلومات دي. که څوک علاقه لري، تاسو کولی شئ د VictoriaMetrics سرچینې کوډ وګورئ او نور اصلاحونه وپلټئ چې هلته شتون لري.

زه د bitset په اړه پوښتنه لرم. د C++ ویکتور بول پلي کولو ته ورته، مطلوب بټ سیټ. ایا تاسو له هغه ځایه تطبیق کړی؟

نه، له هغه ځایه نه. کله چې د دې بټ سیټ پلي کول، زه د دې ids مهال ویشونو جوړښت په اړه د پوهې لخوا لارښود شوی وم، کوم چې په ویکتوریا میټریک کې کارول کیږي. او د دوی جوړښت داسې دی چې پورتنۍ 32 بټونه اساسا ثابت دي. ټیټ 32 بټونه د بدلون تابع دي. هرڅومره چې ټیټ وي، ډیر ځله دا بدلیدلی شي. له همدې امله، دا تطبیق په ځانګړې توګه د دې ډاټا جوړښت لپاره غوره شوی. د C++ تطبیق، تر هغه چې زه پوهیږم، د عمومي قضیې لپاره مطلوب دی. که تاسو د عمومي قضیې لپاره غوره کړئ، دا پدې مانا ده چې دا به د یوې ځانګړې قضیې لپاره خورا غوره نه وي.

زه تاسو ته هم مشوره درکوم چې د الیکسي میلوویډ راپور وګورئ. شاوخوا یوه میاشت دمخه، هغه د ځانګړو تخصصونو لپاره په ClickHouse کې د اصلاح کولو په اړه خبرې وکړې. هغه یوازې وايي چې په عمومي حالت کې، د C++ تطبیق یا کوم بل تطبیق په روغتون کې په اوسط ډول د ښه کار کولو لپاره مناسب دی. دا ممکن زموږ په څیر د پوهې ځانګړي پلي کولو څخه بد ترسره کړي ، چیرې چې موږ پوهیږو چې پورته 32 بټونه اکثرا ثابت دي.

زه دویمه پوښتنه لرم. د InfluxDB څخه بنسټیز توپیر څه دی؟

ډیری بنسټیز توپیرونه شتون لري. د فعالیت او حافظې مصرف شرایطو کې ، په ازموینو کې InfluxDB د لوړ کارتینالیټي وخت لړۍ لپاره 10 ځله ډیر حافظه مصرف ښیې ، کله چې تاسو ډیری لرئ ، د مثال په توګه ، ملیونونه. د مثال په توګه، VictoriaMetrics په هر ملیون فعال قطارونو کې 1 GB مصرفوي، پداسې حال کې چې InfluxDB 10 GB مصرفوي. او دا یو لوی توپیر دی.

دوهم بنسټیز توپیر دا دی چې InfluxDB د عجیب پوښتنو ژبې لري - Flux او InfluxQL. دوی په پرتله د وخت لړۍ سره د کار کولو لپاره خورا اسانه ندي PromQL، کوم چې د VictoriaMetrics لخوا ملاتړ کیږي. PromQL د Prometheus څخه د پوښتنې ژبه ده.

او یو بل توپیر دا دی چې InfluxDB یو څه عجیب ډیټا ماډل لري ، چیرې چې هره کرښه کولی شي ډیری ساحې د مختلف ټاګونو سره ذخیره کړي. دا کرښې بیا په مختلفو جدولونو ویشل شوي دي. دا اضافي پیچلتیاوې د دې ډیټابیس سره راتلونکی کار پیچلی کوي. دا ستونزمنه ده چې ملاتړ او پوه شي.

په ویکتوریا میټریکس کې هرڅه خورا ساده دي. هلته، هر ځل لړۍ یو کلیدي ارزښت دی. ارزښت د ټکو یوه مجموعه ده - (timestamp, value)، او کلیدي سیټ دی label=value. د ساحو او اندازه کولو تر مینځ هیڅ توپیر شتون نلري. دا تاسو ته اجازه درکوي کوم معلومات وټاکئ او بیا یوځای کړئ، اضافه کړئ، کم کړئ، ضرب کړئ، تقسیم کړئ، د InfluxDB برعکس چیرې چې د مختلف قطارونو تر مینځ حسابونه لاهم نه پلي کیږي تر هغه چې زه پوهیږم. حتی که دوی پلي شي، دا ستونزمنه ده، تاسو باید ډیری کوډ ولیکئ.

زه یوه روښانه پوښتنه لرم. ایا زه په سمه توګه پوهیدم چې دلته یو ډول ستونزه وه چې تاسو یې په اړه خبرې کولې، دا بدل شوی شاخص په حافظه کې مناسب نه دی، نو هلته ویشل کیږي؟

لومړی ، ما په معیاري Go نقشه کې د بدل شوي شاخص ساده پلي کول وښودل. دا پلي کول د ډیټابیس لپاره مناسب ندي ځکه چې دا بدل شوی شاخص ډیسک ته نه دی خوندي شوی ، او ډیټابیس باید ډیسک ته خوندي کړي ترڅو دا ډاټا د بیا پیل کولو پرمهال شتون ولري. پدې پلي کولو کې ، کله چې تاسو غوښتنلیک بیا پیل کړئ ، نو ستاسو بدل شوی شاخص به ورک شي. او تاسو به ټولو معلوماتو ته لاسرسی له لاسه ورکړئ ځکه چې تاسو به یې ونه موندل شي.

سلام! د راپور لپاره مننه! زما نوم پاول دی. زه د Wildberries څخه یم زه ستاسو لپاره یو څو پوښتنې لرم. یوه پوښتنه. ایا تاسو فکر کوئ چې که تاسو د خپل غوښتنلیک جوړښت رامینځته کولو پرمهال مختلف اصول غوره کړي وي او د وخت په تیریدو سره ډیټا ویشل شوي وي ، نو شاید تاسو به وکولی شئ د لټون کولو پرمهال ډیټا قطع کړئ ، یوازې د دې حقیقت پراساس چې یوه برخه د یو لپاره ډیټا لري. د وخت موده، دا دی، په یو وخت وقفه کې او تاسو به د دې حقیقت په اړه اندیښنه ونلرئ چې ستاسو ټوټې په مختلف ډول ویشل شوي؟ پوښتنه نمبر 2 - له هغه ځایه چې تاسو د بټ سیټ او نورو هرڅه سره ورته الګوریتم پلي کوئ ، نو شاید تاسو د پروسیسر لارښوونو کارولو هڅه کړې؟ شاید تاسو د داسې اصلاح کولو هڅه کړې وي؟

زه به سمدلاسه دوهم ځواب ورکړم. موږ تر اوسه دې ټکي ته نه یو رسېدلي. مګر که اړتیا وي، موږ به هلته ورسیږو. او لومړی، پوښتنه څه وه؟

تاسو په دوه سناریوګانو بحث وکړ. او دوی وویل چې دوی دوهم یې د خورا پیچلي پلي کولو سره غوره کړ. او دوی لومړی ته ترجیح نه ورکوله، چیرې چې ډاټا د وخت سره ویشل کیږي.

هو. په لومړي حالت کې، د شاخص ټول حجم به لوی وي، ځکه چې په هره برخه کې موږ باید د هغه وخت لړۍ لپاره نقل شوي ډاټا ذخیره کړو چې د دې ټولو برخو له لارې دوام لري. او که ستاسو د وخت لړۍ د مینځلو کچه ټیټه وي ، د بیلګې په توګه ورته لړۍ په دوامداره توګه کارول کیږي ، نو په لومړي حالت کې به موږ د دوهم حالت په پرتله د نیول شوي ډیسک ځای په مقدار کې ډیر له لاسه ورکړو.

او همداسې - هو، د وخت ویش یو ښه انتخاب دی. Prometheus دا کاروي. خو Prometheus یو بل نیمګړتیا لري. کله چې د ډیټا دا ټوټې یوځای کول، دا اړتیا لري چې د ټولو لیبلونو او مهال ویشونو لپاره د حافظې میټا معلومات وساتي. له همدې امله ، که د ډیټا ټوټې چې دا یوځای کوي لوی وي ، نو د ویکتوریا میټریکس برعکس ، د ادغام پرمهال د حافظې مصرف خورا ډیریږي. کله چې ضمیمه کیږي، ویکتوریا میټریکس په هیڅ ډول حافظه نه مصرفوي؛ یوازې یو څو کیلوبایټ مصرف کیږي، پرته له دې چې د ډیټا یوځای شوي ټوټو اندازه په پام کې ونیول شي.

هغه الګوریتم چې تاسو یې کاروئ حافظه کاروي. دا د وخت لړۍ ټاګونه په نښه کوي چې ارزښتونه لري. او پدې توګه تاسو په یوه ډیټا سري او بل کې د جوړه شتون لپاره چیک کړئ. او تاسو پوهیږئ چې آیا تقاطع واقع شوی یا نه. عموما، ډیټابیسونه کرسرونه او تکرارونکي پلي کوي چې خپل اوسني مینځپانګې ذخیره کوي او د دې عملیاتو ساده پیچلتیا له امله د ترتیب شوي ډیټا له لارې پرمخ ځي.

ولې موږ د معلوماتو د تیرولو لپاره کرسر نه کاروو؟

هو.

موږ ترتیب شوي قطارونه په LevelDB یا مرجیسټ کې ذخیره کوو. موږ کولی شو کرسر حرکت وکړو او تقاطع پیدا کړو. ولې یې نه کاروو؟ ځکه چې دا سست دی. ځکه چې کرسر پدې معنی دي چې تاسو اړتیا لرئ د هرې کرښې لپاره فنکشن زنګ ووهئ. د فنکشن کال 5 نانو ثانیه دی. او که تاسو 100 لینونه لرئ، نو دا معلومه شوه چې موږ نیمه ثانیه یوازې د فنکشن زنګ وهو.

داسې یو شی شتون لري، هو. او زما وروستۍ پوښتنه. پوښتنه ممکن یو څه عجيب وي. ولې دا ممکنه نه ده چې ټول اړین مجموعې په هغه وخت کې ولولي چې ډاټا راشي او په اړین شکل کې یې خوندي کړي؟ ولې په ځینو سیسټمونو کې لوی حجمونه خوندي کړئ لکه ویکتوریا میټریک، کلیک هاؤس، او نور، او بیا په دوی ډیر وخت مصرف کړئ؟

زه به یې د روښانه کولو لپاره یو مثال وړاندې کړم. راځئ چې ووایو چې د لوبو کوچني سرعت میټر څنګه کار کوي؟ دا هغه فاصله ثبتوي چې تاسو سفر کړی، هر وخت دا یو ارزښت ته اضافه کوي، او دویم ځل. او تقسیموي. او اوسط سرعت ترلاسه کوي. تاسو د ورته شی په اړه کولی شئ. په الوتنه کې ټول اړین حقایق اضافه کړئ.

ښه، زه په پوښتنه پوهیږم. ستاسو مثال خپل ځای لري. که تاسو پوهیږئ چې کوم مجموعې ته اړتیا لرئ، نو دا غوره تطبیق دی. مګر ستونزه دا ده چې خلک دا میټریکونه خوندي کوي، ځینې ډاټا په ClickHouse کې او دوی لا تر اوسه نه پوهیږي چې دوی به په راتلونکي کې څنګه راټول او فلټر کړي، نو دوی باید ټول خام معلومات خوندي کړي. مګر که تاسو پوهیږئ چې تاسو اړتیا لرئ په اوسط ډول یو څه محاسبه کړئ، نو بیا ولې هلته د خامو ارزښتونو د ذخیره کولو پرځای دا حساب نه کوئ؟ مګر دا یوازې هغه وخت دی چې تاسو واقعیا پوهیږئ چې تاسو ورته اړتیا لرئ.

په هرصورت، د وخت لړۍ ذخیره کولو لپاره ډیټابیسونه د مجموعو شمیرل ملاتړ کوي. د مثال په توګه، Prometheus ملاتړ کوي د ثبت کولو قواعد. دا دی، دا ترسره کیدی شي که تاسو پوهیږئ کوم واحدونو ته اړتیا لرئ. VictoriaMetrics لا تر اوسه دا نه لري، مګر دا معمولا د پرومیتیوس لخوا وړاندې کیږي، په کوم کې چې دا د بیاکتنې قواعدو کې ترسره کیدی شي.

د مثال په توګه، زما په پخوانۍ دنده کې ما اړتیا درلوده چې په وروستي ساعت کې په سلایډینګ کړکۍ کې د پیښو شمیر حساب کړم. ستونزه دا ده چې ما باید په Go کې دودیز پلي کول رامینځته کړي ، د بیلګې په توګه د دې شیانو شمیرلو لپاره خدمت. دا خدمت په نهایت کې غیر معمولی و، ځکه چې دا محاسبه ستونزمنه ده. پلي کول ساده کیدی شي که تاسو اړتیا لرئ په ټاکلي وخت وقفو کې ځینې مجموعې حساب کړئ. که تاسو غواړئ پیښې په سلایډینګ کړکۍ کې حساب کړئ ، نو دا دومره ساده ندي لکه څنګه چې ښکاري. زه فکر کوم چې دا لا تر اوسه په ClickHouse یا د ټایمریز ډیټابیسونو کې ندي پلي شوي، ځکه چې پلي کول ستونزمن دي.

او یوه بله پوښتنه. موږ یوازې د اوسط کولو په اړه خبرې کولې، او زما په یاد ول چې یو وخت د کاربن بیکینډ سره د ګرافیت په څیر یو شی شتون درلود. او هغه پوهیده چې څنګه زاړه ډیټا کم کړي ، دا په یوه دقیقه کې یو ټکی پریږدئ ، په ساعت کې یو ټکی ، او داسې نور. په اصولو کې ، دا خورا اسانه دی که موږ خام ډیټا ته اړتیا لرو ، په نسبي ډول د یوې میاشتې لپاره ، او نور هرڅه کولی شي. پتلی شي مګر Prometheus او VictoriaMetrics د دې فعالیت ملاتړ نه کوي. ایا دا د ملاتړ لپاره پلان شوی؟ که نه، ولې نه؟

د پوښتنې لپاره مننه. زموږ کاروونکي دا پوښتنه په وخت سره کوي. دوی پوښتنه کوي کله چې موږ به د نمونې ښکته کولو لپاره ملاتړ اضافه کړو. دلته ډیری ستونزې شتون لري. لومړی، هر کاروونکي پوهیږي downsampling یو څه توپیر: یو څوک غواړي په ټاکل شوي وقفه کې هر ډول خپلمنځي نقطه ترلاسه کړي، څوک غواړي اعظمي، لږترلږه، اوسط ارزښتونه. که ډیری سیسټمونه ستاسو ډیټابیس ته ډاټا لیکي، نو تاسو نشئ کولی دا ټول یوځای کړئ. دا ممکن وي چې هر سیسټم مختلف پتلی کولو ته اړتیا ولري. او دا پلي کول ستونزمن دي.

او دوهم شی دا دی چې VictoriaMetrics، لکه ClickHouse، د لوی مقدار خام ډیټا کار کولو لپاره مطلوب دی، نو دا کولی شي د یوې ثانیې څخه لږ وخت کې یو ملیارد لینونه تیر کړي که تاسو په خپل سیسټم کې ډیری کورونه لرئ. په ویکتوریا میټریکس کې د سکین کولو وخت لړۍ ټکي - په هر کور کې 50 ټکي په ثانیه کې. او دا فعالیت موجوده کورونو ته اندازه کوي. دا دی، که تاسو 000 کورونه لرئ، د بیلګې په توګه، تاسو به په هر ثانیه کې یو ملیارد پوائنټونه سکین کړئ. او د VictoriaMetrics او ClickHouse دا ملکیت د ښکته کولو اړتیا کموي.

بله ځانګړتیا دا ده چې VictoriaMetrics دا ډاټا په مؤثره توګه فشاروي. په تولید کې په اوسط ډول کمپریشن په هر نقطه کې له 0,4 څخه تر 0,8 بایټ پورې دی. هر ټکی د مهال ویش + ارزښت دی. او دا په اوسط ډول له یو بایټ څخه کم فشار شوی.

سرګي. زه یوه پوښتنه لرم. د ثبت کولو لږترلږه وخت څومره دی؟

یو ملی ثانیه. موږ پدې وروستیو کې د نورو وخت لړۍ ډیټابیس پراختیا کونکو سره خبرې اترې درلودې. د دوی لږترلږه وخت یوه ثانیه ده. او په ګرافیټ کې، د بیلګې په توګه، دا هم یوه ثانیه ده. په OpenTSDB کې دا هم یوه ثانیه ده. InfluxDB د nanosecond دقیقیت لري. په VictoriaMetrics کې دا یو ملی ثانوي دی، ځکه چې په Prometheus کې دا یو ملی ثانوي دی. او ویکتوریا میټریکس په اصل کې د پرومیټیوس لپاره د ریموټ ذخیره په توګه رامینځته شوی و. مګر اوس دا کولی شي د نورو سیسټمونو ډاټا خوندي کړي.

هغه څوک چې ما ورسره خبرې وکړې وايي دوی له دویم څخه تر دویم دقیقیت لري - دا د دوی لپاره کافي دی ځکه چې دا د ډیټا ډول پورې اړه لري چې د وخت لړۍ ډیټابیس کې زیرمه کیږي. که دا د DevOps ډیټا یا د زیربنا څخه ډیټا وي ، چیرې چې تاسو دا د 30 ثانیو په وقفه کې په یوه دقیقه کې راټول کړئ ، نو دوهم دقیقیت کافي دی ، تاسو لږ څه ته اړتیا نلرئ. او که تاسو دا معلومات د لوړې فریکونسۍ سوداګرۍ سیسټمونو څخه راټول کړئ ، نو تاسو د نانو ثانیه دقت ته اړتیا لرئ.

په VictoriaMetrics کې د ملیسیکنډ درستیت د DevOps قضیې لپاره هم مناسب دی، او کیدای شي د ډیری قضیو لپاره مناسب وي چې ما د راپور په پیل کې یادونه وکړه. یوازینی شی چې دا ممکن مناسب نه وي د لوړې فریکونسۍ سوداګرۍ سیسټمونه دي.

له تاسو مننه! او بله پوښتنه. په PromQL کې مطابقت څه شی دی؟

بشپړ شاته مطابقت. VictoriaMetrics په بشپړه توګه د PromQL ملاتړ کوي. برسېره پردې، دا په PromQL کې اضافي پرمختللي فعالیت اضافه کوي، کوم چې ویل کیږي MetricsQL. د دې پراخ شوي فعالیت په اړه په یوټیوب کې خبرې روانې دي. ما په پسرلي کې په سینټ پیټرزبورګ کې د څارنې په غونډه کې خبرې وکړې.

د ټیلیګرام چینل ویکتوریا میټریک.

یوازې راجستر شوي کاروونکي کولی شي په سروې کې برخه واخلي. ننوزئمهرباني وکړئ

څه شی تاسو د پرومیټیوس لپاره ستاسو د اوږدې مودې ذخیره کولو په توګه ویکتوریا میټریکس ته د بدلولو مخه نیسي؟ (په نظرونو کې ولیکئ، زه به یې په ټولپوښتنه کې اضافه کړم))

• ۸۵٪زه Prometheus5 نه کاروم

• ۸۵٪د VictoriaMetrics2 په اړه نه پوهیدل

7 کاروونکو رایه ورکړه. 12 کاروونکي منع شوي.

سرچینه: www.habr.com