VictoriaMetrics ۾ اصلاح ڏانهن وڃو. اليگزينڊر Valyalkin

منهنجو مشورو آهي ته توهان 2019 جي آخر ۾ اليگزينڊر ويلالڪن جي رپورٽ جو ٽرانسڪرپٽ پڙهو ”وڪٽوريا ميٽرڪس ۾ اصلاح ڏانهن وڃو“

وڪٽوريا ميٽرڪس - هڪ تيز ۽ اسپيبلبل ڊي بي ايم ايس ڊيٽا کي محفوظ ڪرڻ ۽ پروسيسنگ ڪرڻ لاءِ ٽائيم سيريز جي صورت ۾ (ريڪارڊ وقت ٺاهي ٿو ۽ هن وقت سان لاڳاپيل قدرن جو هڪ سيٽ، مثال طور، سينسرز جي حيثيت جي وقتي پولنگ ذريعي حاصل ڪيل يا گڏ ڪرڻ. ميٽرڪس).

هن رپورٽ جي وڊيو جي لنڪ هي آهي- https://youtu.be/MZ5P21j_HLE

سلائيڊ

اسان کي پنهنجي باري ۾ ٻڌايو. مان اليگزينڊر ويلالڪين آهيان. هتي منهنجو GitHub اڪائونٽ. مان وڃ ۽ ڪارڪردگي جي اصلاح بابت پرجوش آهيان. مون ڪيتريون ئي ڪارآمد لئبرريون لکيون ۽ نه ئي ڪارآمد. اهي ٻئي سان شروع ڪن ٿا fast، يا سان گڏ quick اڳوڻو.

مان هن وقت VictoriaMetrics تي ڪم ڪري رهيو آهيان. اهو ڇا آهي ۽ مان اتي ڇا ڪري رهيو آهيان؟ مان هن پريزنٽيشن ۾ ان بابت ڳالهائيندس.

رپورٽ جو خاڪو هن ريت آهي:

• پهرين، مان توهان کي ٻڌائيندس VictoriaMetrics ڇا آهي.
• پوءِ مان توهان کي ٻڌايان ٿو ته ڪهڙيون سيريز آهن.
• پوءِ مان توهان کي ٻڌايان ٿو ته ٽائيم سيريز ڊيٽابيس ڪيئن ڪم ڪندو آهي.
• اڳيون، مان توهان کي ٻڌايان ٿو ڊيٽابيس آرڪيٽيڪچر بابت: اهو ڇا تي مشتمل آهي.
• ۽ پوءِ اچو ته اڳتي وڌون انھن اصلاحن ڏانھن جيڪي VictoriaMetrics وٽ آھن. هي انڊيڪس انڊيڪس لاءِ هڪ اصلاح آهي ۽ گو ۾ بٽ سيٽ عمل درآمد لاءِ هڪ اصلاح آهي.

ڇا سامعين ۾ ڪنهن کي خبر آهي ته VictoriaMetrics ڇا آهي؟ واه، ڪيترائي ماڻهو اڳ ۾ ئي ڄاڻن ٿا. اها هڪ سٺي خبر آهي. انهن لاءِ جيڪي نه ٿا ڄاڻن، هي هڪ ٽائيم سيريز ڊيٽابيس آهي. اهو ClickHouse فن تعمير تي ٻڌل آهي، ClickHouse جي عمل جي ڪجهه تفصيلن تي. مثال طور، جهڙوڪ: MergeTree، سڀني موجود پروسيسر ڪور تي متوازي حساب ڪتاب ۽ پروسيسر ڪيش ۾ رکيل ڊيٽا بلاڪ تي ڪم ڪندي ڪارڪردگي جي اصلاح.

VictoriaMetrics ٻين ٽائيم سيريز ڊيٽابيس جي ڀيٽ ۾ بهتر ڊيٽا ڪمپريشن مهيا ڪري ٿي.

اهو عمودي اسڪيل آهي - اهو آهي، توهان هڪ ڪمپيوٽر تي وڌيڪ پروسيسر، وڌيڪ رام شامل ڪري سگهو ٿا. VictoriaMetrics انهن دستياب وسيلن کي ڪاميابيءَ سان استعمال ڪندي ۽ لڪير جي پيداوار کي بهتر بڻائي سگهندي.

VictoriaMetrics پڻ افقي طور تي ماپ ڪري ٿو - اھو آھي، توھان VictoriaMetrics ڪلستر ۾ اضافي نوڊس شامل ڪري سگھو ٿا، ۽ ان جي ڪارڪردگي تقريبا لڪير ۾ وڌندي.

جيئن توهان اندازو لڳايو، VictoriaMetrics هڪ تيز ڊيٽابيس آهي، ڇاڪاڻ ته مان ٻين کي نٿو لکي سگهان. ۽ اهو گو ۾ لکيل آهي، تنهنڪري مان هن ميٽنگ ۾ ان بابت ڳالهائي رهيو آهيان.

ڪير ڄاڻي ٿو ته ٽائيم سيريز ڇا آهي؟ هو ڪيترن ئي ماڻهن کي به ڄاڻي ٿو. ٽائيم سيريز جوڑوں جو هڪ سلسلو آهي (timestamp, значение)، جتي اهي جوڙا وقت جي ترتيب سان ترتيب ڏنل آهن. قيمت هڪ سچل پوائنٽ نمبر آهي - float64.

هر دفعي سيريز منفرد طور تي هڪ ڪنجي طرفان سڃاڻپ ڪئي وئي آهي. هي ڪنجي ڇا تي مشتمل آهي؟ اهو هڪ غير خالي سيٽ تي مشتمل آهي اهم-قدر جوڑوں جي.

هتي هڪ ٽائيم سيريز جو هڪ مثال آهي. هن سيريز جي اهم جوڑوں جي هڪ فهرست آهي: __name__="cpu_usage" ميٽرڪ جو نالو آهي، instance="my-server" - ھي اھو ڪمپيوٽر آھي جنھن تي ھي ميٽرڪ گڏ ڪيو ويو آھي، datacenter="us-east" - هي آهي ڊيٽا سينٽر جتي هي ڪمپيوٽر واقع آهي.

اسان هڪ ٽائيم سيريز جو نالو ختم ڪيو جنهن ۾ ٽي اهم-قدر جوڙو شامل آهن. هي ڪنجي جوڙن جي فهرست سان ملندڙ جلندڙ آهي (timestamp, value). t1, t3, t3, ..., tN - اهي ٽائم اسٽيمپ آهن، 10, 20, 12, ..., 15 - ملندڙ قدر. هي سي پي يو استعمال آهي هڪ ڏنل سيريز لاءِ ڏنل وقت تي.

ٽائيم سيريز ڪٿي استعمال ڪري سگھجي ٿو؟ ڇا ڪنهن کي ڪو خيال آهي؟

• DevOps ۾، توھان ماپ ڪري سگھو ٿا سي پي يو، رام، نيٽ ورڪ، آر پي ايس، غلطين جو تعداد، وغيره.
• IoT - اسان ماپ ڪري سگهون ٿا درجه حرارت، دٻاء، جيو ڪوآرڊينيٽس ۽ ٻيو ڪجهه.
• پڻ فنانس - اسان سڀني قسمن جي اسٽاڪ ۽ ڪرنسي جي قيمتن جي نگراني ڪري سگھون ٿا.
• ان کان علاوه، ٽائيم سيريز فيڪٽريز ۾ پيداوار جي عمل جي نگراني ۾ استعمال ڪري سگھجي ٿو. اسان وٽ اهي صارف آهن جيڪي ونڊ ٽربائن جي نگراني ڪرڻ لاءِ VictoriaMetrics استعمال ڪندا آهن، روبوٽس لاءِ.
• ٽائيم سيريز مختلف ڊوائيسز جي سينسر کان معلومات گڏ ڪرڻ لاء پڻ ڪارائتو آهن. مثال طور، هڪ انجڻ لاء؛ ٽائر پريشر کي ماپڻ لاءِ؛ رفتار جي ماپ لاء، فاصلو؛ گيسولين جي استعمال کي ماپڻ لاءِ، وغيره.
• ٽائيم سيريز پڻ جهاز جي نگراني ڪرڻ لاء استعمال ڪري سگهجي ٿو. هر جهاز ۾ هڪ بليڪ باڪس هوندو آهي جيڪو جهاز جي صحت جي مختلف ماپن لاءِ ٽائيم سيريز گڏ ڪري ٿو. ٽائيم سيريز پڻ ايرو اسپيس انڊسٽري ۾ استعمال ٿيندا آهن.
• صحت جي سنڀال بلڊ پريشر، نبض، وغيره آهي.

ٿي سگھي ٿو وڌيڪ ايپليڪيشنون جيڪي مون کي وساري ڇڏيون، پر اميد اٿم ته توھان سمجھندا آھيو ته ٽائيم سيريز فعال طور تي جديد دنيا ۾ استعمال ڪيا ويا آھن. ۽ انهن جي استعمال جو مقدار هر سال وڌي رهيو آهي.

توهان کي ٽائيم سيريز ڊيٽابيس جي ضرورت ڇو آهي؟ توهان ٽائيم سيريز کي ذخيرو ڪرڻ لاء باقاعده لاڳاپو ڊيٽابيس ڇو نه استعمال ڪري سگهو ٿا؟

ڇاڪاڻ ته ٽائيم سيريز عام طور تي معلومات جي هڪ وڏي مقدار تي مشتمل آهي، جيڪا روايتي ڊيٽابيس ۾ محفوظ ڪرڻ ۽ پروسيس ڪرڻ ڏکيو آهي. تنهن ڪري، ٽائيم سيريز لاء خاص ڊيٽابيس ظاهر ٿيو. اهي بنيادن کي مؤثر طريقي سان پوائنٽن کي محفوظ ڪن ٿا (timestamp, value) ڏنل چاٻي سان. اهي هڪ API مهيا ڪن ٿا ذخيرو ٿيل ڊيٽا کي پڙهڻ لاءِ ڪي، هڪ واحد ڪي-ويل جوڙو، يا ڪيترن ئي اهم-قدر جوڙو، يا ريگ ايڪسپ ذريعي. مثال طور، توھان ڳولڻ چاھيو ٿا توھان جي سڀني خدمتن جي سي پي يو لوڊ آمريڪا ۾ ڊيٽا سينٽر ۾، پوء توھان کي استعمال ڪرڻ جي ضرورت آھي ھن pseudo-query.

عام طور تي ٽائيم سيريز ڊيٽابيس خاص سوالن جون ٻوليون مهيا ڪن ٿا ڇاڪاڻ ته ٽائيم سيريز SQL بلڪل مناسب نه آهي. جيتوڻيڪ اهڙا ڊيٽابيس آهن جيڪي SQL کي سپورٽ ڪن ٿا، اهو بلڪل مناسب ناهي. ٻوليون پڇڻ جهڙوڪ PromQL, InfluxQL, وهڪري, Q. مون کي اميد آهي ته ڪنهن کي گهٽ ۾ گهٽ انهن ٻولين مان هڪ ٻڌو آهي. ڪيترن ئي ماڻهن شايد PromQL بابت ٻڌو آهي. هي آهي Prometheus جي پڇاڙي جي ٻولي.

اھو اھو آھي جيڪو ھڪڙو جديد ٽائيم سيريز ڊيٽابيس آرڪيٽيڪچر ڏسڻ ۾ اچي ٿو VictoriaMetrics مثال طور استعمال ڪندي.

اهو ٻن حصن تي مشتمل آهي. هي انڊيڪس انڊيڪس لاءِ اسٽوريج آهي ۽ ٽائيم سيريز ويلز لاءِ اسٽوريج. اهي ذخيرا الڳ الڳ آهن.

جڏهن ڊيٽابيس ۾ هڪ نئون رڪارڊ اچي ٿو، اسان پهريون ڀيرو انڊيڪس تائين پهچون ٿا هڪ ڏنل سيٽ لاءِ ٽائيم سيريز جي سڃاڻپ ڪندڙ کي ڳولڻ لاءِ. label=value ڏنل ميٽرڪ لاء. اسان هن سڃاڻپ ڪندڙ کي ڳوليندا آهيون ۽ ڊيٽا اسٽور ۾ قيمت محفوظ ڪندا آهيون.

جڏهن هڪ درخواست TSDB کان ڊيٽا حاصل ڪرڻ لاء اچي ٿي، اسان پهريون ڀيرو انڊيڪس انڊيڪس ڏانهن وڃو. اچو ته سڀ ڪجهه حاصل ڪريون timeseries_ids رڪارڊ جيڪي هن سيٽ سان ملن ٿا label=value. ۽ پوء اسان ڊيٽا گودام مان تمام ضروري ڊيٽا حاصل ڪندا آهيون، ترتيب ڏنل timeseries_ids.

اچو ته هڪ مثال ڏسو ته ڪيئن ٽائيم سيريز ڊيٽابيس هڪ ايندڙ چونڊ سوال کي پروسيس ڪري ٿو.

• سڀ کان پهريان هوء سڀ ڪجهه حاصل ڪري ٿي timeseries_ids هڪ inverted index مان جنهن ۾ ڏنل جوڑوں تي مشتمل آهي label=value، يا ڏنل باقاعده اظهار کي پورو ڪريو.
• ان کان پوء اهو سڀني ڊيٽا پوائنٽ حاصل ڪري ٿو ڊيٽا اسٽوريج مان هڪ ڏنل وقت جي وقفي تي مليل ماڻهن لاء timeseries_ids.
• ان کان پوء، ڊيٽابيس انهن ڊيٽا پوائنٽن تي ڪجهه حسابن کي انجام ڏئي ٿو، صارف جي درخواست جي مطابق. ۽ ان کان پوء اهو جواب ڏئي ٿو.

هن پيشڪش ۾ آئون توهان کي پهرين حصي بابت ٻڌائيندس. هي هڪ ڳولا آهي timeseries_ids inverted index جي ذريعي. توھان ٻئي حصو ۽ ٽيون حصو بعد ۾ ڏسي سگھو ٿا VictoriaMetrics ذريعن، يا انتظار ڪريو جيستائين مان ٻيون رپورٽون تيار نه ڪريان :)

اچو ته انڊيڪس انڊيڪس ڏانهن وڃو. ڪيترن ئي سوچيو ته اهو سادو آهي. ڪير ڄاڻي ٿو ته هڪ انڊيڪس ڇا آهي ۽ اهو ڪيئن ڪم ڪري ٿو؟ ها، هاڻي گهڻا ماڻهو نه آهن. اچو ته سمجهڻ جي ڪوشش ڪريون ته اهو ڇا آهي.

اهو اصل ۾ سادو آهي. اهو صرف هڪ ڊڪشنري آهي جيڪو نقشي ۾ هڪ قدر جي ڪنجي آهي. هڪ چاٻي ڇا آهي؟ هي جوڙو label=valueڪٿي label и value - اهي سٽون آهن. ۽ قدر هڪ سيٽ آهن timeseries_ids، جنهن ۾ ڏنل جوڙو شامل آهي label=value.

Inverted index توهان کي جلدي هر شيء ڳولڻ جي اجازت ڏئي ٿي timeseries_ids، جيڪي ڏنيون آهن label=value.

اهو پڻ توهان کي جلدي ڳولڻ جي اجازت ڏئي ٿو timeseries_ids ڪيترن ئي جوڑوں لاء وقت سيريز label=value، يا جوڑوں لاءِ label=regexp. اهو ڪيئن ٿو ٿئي؟ سٽ جي چونڪ کي ڳولڻ سان timeseries_ids هر هڪ جوڙي لاء label=value.

اچو ته انڊيڪس جي مختلف عملن تي نظر رکون. اچو ته آسان ترين عمل سان شروع ڪريون. هوءَ ائين لڳندي آهي.

فعل getMetricIDs تارن جي لسٽ حاصل ڪري ٿي. هر قطار تي مشتمل آهي label=value. هي فنڪشن هڪ فهرست ڏئي ٿو metricIDs.

اهو ڪيئن ڪم ڪري ٿو؟ هتي اسان وٽ هڪ گلوبل variable سڏيو ويندو آهي invertedIndex. هي هڪ باقاعده لغت آهي (map)، جيڪو اسٽرنگ کي slice ints ڏانهن نقشي ڪندو. لائن تي مشتمل آهي label=value.

فنڪشن تي عملدرآمد: حاصل ڪريو metricIDs پهرين لاء label=value، پوءِ اسان هر شي ذريعي وڃون ٿا label=value، اسان حاصل ڪريون ٿا metricIDs انهن لاءِ. ۽ فنڪشن کي ڪال ڪريو intersectInts، جنهن تي هيٺ بحث ڪيو ويندو. ۽ هي فنڪشن انهن لسٽن جي چونڪ کي واپس ڪري ٿو.

جئين توهان ڏسي سگهو ٿا، هڪ انڊيڪس انڊيڪس کي لاڳو ڪرڻ تمام پيچيده ناهي. پر هي هڪ سادي عمل آهي. ان جا ڪهڙا نقصان آهن؟ سادي عمل جو بنيادي نقصان اهو آهي ته اهڙي هڪ انڊيڪس انڊيڪس رام ۾ ذخيرو ٿيل آهي. ايپليڪيشن کي ٻيهر شروع ڪرڻ کان پوء اسان هن انڊيڪس کي وڃائي ڇڏيو. ھن انڊيڪس جي ڊسڪ ۾ ڪا به بچت نه آھي. اهڙي هڪ انڊيڪس انڊيڪس ڊيٽابيس لاءِ موزون هجڻ ممڪن ناهي.

ٻيو خرابي پڻ ياداشت سان لاڳاپيل آهي. inverted index کي RAM ۾ فٽ ٿيڻ گھرجي. جيڪڏهن اهو ريم جي سائيز کان وڌيڪ آهي، پوء ظاهر آهي ته اسان حاصل ڪنداسين - ميموري جي غلطي کان ٻاهر. ۽ پروگرام ڪم نه ڪندو.

اهو مسئلو تيار ڪيل حل استعمال ڪندي حل ڪري سگهجي ٿو جهڙوڪ سطح جي ڊي بي، يا RocksDB.

مختصر ۾، اسان کي هڪ ڊيٽابيس جي ضرورت آهي جيڪا اسان کي ٽن عملن کي جلدي ڪرڻ جي اجازت ڏئي ٿي.

• پهريون آپريشن رڪارڊنگ آهي ключ-значение هن ڊيٽابيس ڏانهن. هوءَ هن تمام جلدي ڪري ٿي، جتي ключ-значение پاڻمرادو تار آهن.
• ٻيو آپريشن هڪ ڏنل چيڪ استعمال ڪندي قدر جي لاءِ جلدي ڳولا آهي.
• ۽ ٽيون آپريشن ڏنو ويو پريفڪس پاران سڀني قدرن لاءِ تڪڙو ڳولا آهي.

LevelDB ۽ RocksDB - اهي ڊيٽابيس ٺاهيا ويا هئا گوگل ۽ فيسبوڪ طرفان. پهريون ڀيرو آيو LevelDB. پوءِ فيس بوڪ جي ماڻهن LevelDB ورتو ۽ ان کي بهتر ڪرڻ شروع ڪيو، انهن RocksDB ٺاهيو. ھاڻي لڳ ڀڳ سڀئي اندروني ڊيٽابيس Facebook اندر RocksDB تي ڪم ڪن ٿا، جن ۾ اھي جيڪي RocksDB ۽ MySQL ڏانھن منتقل ڪيا ويا آھن. انهن کيس نالو ڏنو MyRocks.

هڪ انڊيڪس انڊيڪس LevelDB استعمال ڪندي لاڳو ڪري سگهجي ٿو. اهو ڪيئن ڪجي؟ اسان هڪ چاٻي جي طور تي بچايو label=value. ۽ قدر وقت جي سيريز جي سڃاڻپ ڪندڙ آھي جتي جوڙو موجود آھي label=value.

جيڪڏهن اسان وٽ ڏنل جوڙي سان ڪيترائي وقت سيريز آهن label=valueته پوءِ هن ڊيٽابيس ۾ ڪيتريون ئي قطارون ساڳيون ڪي ۽ مختلف هونديون timeseries_ids. سڀني جي فهرست حاصل ڪرڻ لاء timeseries_ids، جيڪو هن سان شروع ٿئي ٿو label=prefix، اسان هڪ رينج اسڪين ڪندا آهيون جنهن لاءِ هن ڊيٽابيس کي بهتر ڪيو ويو آهي. اھو آھي، اسان سڀني لائينن کي چونڊيو جيڪي شروع ڪندا آھن label=prefix ۽ ضروري حاصل ڪريو timeseries_ids.

هتي هڪ نموني تي عمل درآمد آهي ته اهو Go ۾ ڪهڙو نظر ايندو. اسان وٽ هڪ انڊيڪس انڊيڪس آهي. هي آهي LevelDB.

فنڪشن ساڳيو ئي آهي جيئن غير جانبدار عمل درآمد لاء. اهو لڪير جي لڳ ڀڳ لڪير تي عمل درآمد کي ورجائي ٿو. ڳالهه فقط اها آهي ته ان طرف رخ ڪرڻ بدران map اسان inverted index تائين پهچون ٿا. اسان سڀ کان پهريان سڀ قدر حاصل ڪندا آهيون label=value. ان کان پوء اسان سڀني باقي جوڑوں ذريعي وڃو label=value ۽ انھن لاءِ metricIDs جا لاڳاپيل سيٽ حاصل ڪريو. پوءِ اسان چونڪ ڳوليندا آهيون.

هر شي ٺيڪ ٿي لڳي، پر هن حل ۾ خرابيون آهن. VictoriaMetrics شروعاتي طور تي ليول ڊي بي جي بنياد تي هڪ انڊيڪس انڊيڪس لاڳو ڪيو. پر آخر ۾ مون کي ان کي ڇڏڻو پيو.

ڇو؟ ڇو ته LevelDB سست عمل کان وڌيڪ سست آهي. هڪ سادي عمل ۾، هڪ ڏنل چاٻي ڏني وئي، اسان فوري طور تي پوري سلائس کي حاصل ڪريون ٿا metricIDs. اهو هڪ تمام تيز آپريشن آهي - سڄو سلائس استعمال لاء تيار آهي.

LevelDB ۾، هر وقت هڪ فنڪشن سڏيو ويندو آهي GetValues توھان کي انھن سڀني لائينن ذريعي وڃڻو پوندو جيڪي شروع ٿين ٿيون label=value. ۽ هر لڪير جي قيمت حاصل ڪريو timeseries_ids. اهڙي timeseries_ids ان جو هڪ ٽڪرو گڏ ڪريو timeseries_ids. ظاهر آهي، اهو تمام گهڻو سست آهي صرف هڪ باقاعده نقشي تائين رسائي حاصل ڪرڻ کان.

ٻي خرابي اها آهي ته LevelDB C ۾ لکيل آهي. Go کان C افعال کي ڪال ڪرڻ تمام تيز نه آهي. اهو سوين nanoseconds وٺندو آهي. اهو تمام تيز نه آهي، ڇاڪاڻ ته گو ۾ لکيل هڪ باقاعده فنڪشن ڪال جي مقابلي ۾، جيڪو 1-5 نانو سيڪنڊ وٺندو آهي، ڪارڪردگي ۾ فرق ڏهه ڀيرا آهي. VictoriaMetrics لاءِ هي هڪ خطرناڪ نقص هو :)

تنهن ڪري مون لکيو آهي پنهنجو پاڻ تي لاڳو ٿيل انڊيڪس جو. ۽ هن کيس سڏيو ضم ڪرڻ.

Mergeset MergeTree ڊيٽا جي جوڙجڪ تي ٻڌل آهي. هي ڊيٽا جي جوڙجڪ ClickHouse کان قرض ورتو ويو آهي. ظاهر آهي، mergeset کي تيز ڳولا لاءِ بهتر ڪيو وڃي timeseries_ids ڏنل چاٻي جي مطابق. Mergeset مڪمل طور تي Go ۾ لکيل آهي. توهان ڏسي سگهو ٿا VictoriaMetrics ذريعن GitHub تي. mergeset جو نفاذ فولڊر ۾ آهي /lib/mergeset. توهان اهو معلوم ڪرڻ جي ڪوشش ڪري سگهو ٿا ته اتي ڇا ٿي رهيو آهي.

mergeset API ليول ڊي بي ۽ راڪس ڊي بي سان بلڪل ملندڙ جلندڙ آهي. اھو آھي، اھو توھان کي اجازت ڏئي ٿو تڪڙو تڪڙو اتي نوان رڪارڊ محفوظ ڪريو ۽ جلدي ھڪڙي ڏنل اڳڪٿي طرفان رڪارڊ چونڊيو.

اسان بعد ۾ mergeset جي نقصانن بابت ڳالهائينداسين. هاڻي اچو ته ان بابت ڳالهايون ته وڪٽوريا ميٽرڪس سان پيداوار ۾ ڪهڙا مسئلا پيدا ٿيا جڏهن هڪ انڊيڪس انڊيڪس کي لاڳو ڪيو.

اهي ڇو پيدا ٿيا؟

پهريون سبب اعلي ٻرندڙ شرح آهي. روسي ۾ ترجمو ڪيو ويو، هي وقت جي سيريز ۾ بار بار تبديلي آهي. اهو آهي جڏهن هڪ ٽائيم سيريز ختم ٿئي ٿي ۽ هڪ نئون سلسلو شروع ٿئي ٿو، يا ڪيترائي نوان سيريز شروع ٿين ٿا. ۽ اهو اڪثر ٿئي ٿو.

ٻيو سبب ٽائيم سيريز جو وڏو تعداد آهي. شروعات ۾، جڏهن نگراني مقبوليت حاصل ڪري رهي هئي، ٽائيم سيريز جو تعداد ننڍڙو هو. مثال طور، هر ڪمپيوٽر لاءِ توهان کي سي پي يو، ميموري، نيٽ ورڪ ۽ ڊسڪ لوڊ مانيٽر ڪرڻ جي ضرورت آهي. 4 ٽائيم سيريز في ڪمپيوٽر. اچو ته توهان وٽ 100 ڪمپيوٽرن ۽ 400 ٽائيم سيريز آهن. هي تمام ٿورڙو آهي.

وقت سان گڏ، ماڻهن کي اهو معلوم ٿيو ته اهي وڌيڪ گرينولر معلومات کي ماپ ڪري سگهن ٿا. مثال طور، پوري پروسيسر جي لوڊ نه، پر هر پروسيسر ڪور جي الڳ الڳ ماپ ڪريو. جيڪڏهن توهان وٽ 40 پروسيسر ڪور آهن، ته توهان وٽ پروسيسر لوڊ کي ماپڻ لاءِ 40 ڀيرا وڌيڪ ٽائيم سيريز آهي.

پر اهو سڀ ڪجهه ناهي. هر پروسيسر ڪور ۾ ڪيترائي رياستون ٿي سگهن ٿيون، جهڙوڪ بيڪار، جڏهن اهو بيڪار آهي. ۽ پڻ استعمال ڪندڙ اسپيس ۾ ڪم، ڪنييل اسپيس ۽ ٻين رياستن ۾ ڪم. ۽ هر اهڙي رياست کي الڳ وقت جي سيريز طور ماپي سگهجي ٿو. اهو اضافي طور تي قطارن جو تعداد وڌائي ٿو 7-8 ڀيرا.

ھڪڙي ميٽرڪ مان اسان حاصل ڪيو 40 x 8 = 320 ميٽرڪس صرف ھڪڙي ڪمپيوٽر لاءِ. 100 سان ضرب ڪريو، اسان کي 32 بدران 000 ملندا.

پوءِ ڪبرنيٽس گڏ آيو. ۽ اهو خراب ٿي ويو ڇو ته ڪبرنيٽس ڪيترن ئي مختلف خدمتن جي ميزباني ڪري سگھن ٿا. Kubernetes ۾ هر خدمت ڪيترن ئي پوڊن تي مشتمل آهي. ۽ اهو سڀ ڪجهه نگراني ڪرڻ جي ضرورت آهي. ان کان علاوه، اسان وٽ توهان جي خدمتن جي نئين نسخن جي مسلسل ترتيب آهي. هر نئين ورزن لاءِ، نئين ٽائيم سيريز ٺاهڻ لازمي آهي. نتيجي طور، وقت جي سيريز جو تعداد تيزي سان وڌي ٿو ۽ اسان کي وڏي تعداد جي ٽائيم سيريز جي مسئلي سان منهن ڏيڻو پوي ٿو، جنهن کي هاء-ڪارڊنيالٽي سڏيو ويندو آهي. VictoriaMetrics ان کي ڪاميابي سان نقل ڪري ٿو ٻين ٽائيم سيريز ڊيٽابيس جي مقابلي ۾.

اچو ته هڪ ويجھو نظر رکون ته اعلي چرن جي شرح تي. ڇا پيداوار ۾ هڪ اعلي چرن جي شرح جو سبب آهي؟ ڇو ته ليبل ۽ ٽيگ جا ڪي معنى مسلسل تبديل ٿيندا رهيا آهن.

مثال طور، ڪبرنيٽس وٺو، جنهن جو تصور آهي deployment، يعني جڏهن توهان جي ايپليڪيشن جو نئون ورزن رول آئوٽ ڪيو ويندو. ڪجهه سببن لاءِ، ڪبرنيٽس ڊولپرز فيصلو ڪيو ته ڊيپلائيمينٽ id کي ليبل ۾ شامل ڪيو وڃي.

اهو ڪهڙو سبب بڻيو؟ ان کان علاوه، هر نئين مقرري سان، سڀني پراڻي وقت جي سيريز ۾ مداخلت ڪئي وئي آهي، ۽ انهن جي بدران، نئين ٽائيم سيريز نئين ليبل جي قيمت سان شروع ٿيندي. deployment_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.

ڪهڙا نقصان آهن؟ Quadratic پيچيدگي ان جي بنيادي خرابي آهي. مثال طور، جيڪڏهن توهان جا طول و عرض سلائس آهن a и b هڪ وقت ۾ هڪ ملين، پوء هي فنڪشن ڪڏهن به توهان کي جواب نه ڏيندو. ڇاڪاڻ ته ان کي هڪ ٽريلين ورجائڻو پوندو، جيڪو جديد ڪمپيوٽرن لاءِ به تمام گهڻو آهي.

ٻيو عمل نقشي تي ٻڌل آهي. اسان نقشو ٺاھيو. اسان سلائس مان سڀئي قيمتون هن نقشي ۾ رکون ٿا a. ان کان پوء اسان هڪ الڳ لوپ ۾ سلائس ذريعي وڃو b. ۽ اسان چيڪ ڪريون ٿا ته ڇا هي قيمت سلائس مان آهي b نقشي ۾. جيڪڏهن اهو موجود آهي، پوء ان کي نتيجو ۾ شامل ڪريو.

ڪهڙا فائدا آهن؟ فائدو اهو آهي ته اتي رڳو لڪير پيچيدگي آهي. اهو آهي، فنڪشن وڏي سلائسن لاء تمام تيزيء سان عمل ڪندو. هڪ ملين-سائيز سلائس لاءِ، هي فنڪشن 2 ملين ورهاڱي ۾ عمل ڪندو، جيئن پوئين فنڪشن جي ٽريلين تکرارن جي مقابلي ۾.

نقصان اهو آهي ته هن فنڪشن کي هن نقشي کي ٺاهڻ لاء وڌيڪ ياداشت جي ضرورت آهي.

ٻيو خرابي هيشنگ لاءِ وڏو اوور هيڊ آهي. هي خرابي بلڪل واضح ناهي. ۽ اسان لاءِ اهو به بلڪل واضح نه هو، تنهنڪري پهريون ڀيرو وڪٽوريا ميٽرڪس ۾ چونڪ جو نفاذ نقشي ذريعي ڪيو ويو. پر پوءِ پروفائيلنگ ظاهر ڪيو ته مکيه پروسيسر جو وقت نقشي تي لکڻ ۽ هن نقشي ۾ قدر جي موجودگي جي جانچ ڪرڻ ۾ گذري ٿو.

انهن هنڌن تي سي پي يو جو وقت ڇو ضايع ڪيو وڃي ٿو؟ ڇو ته Go انهن لائينن تي هڪ هشنگ آپريشن ڪري ٿو. اهو آهي، اهو حساب ڪري ٿو چيڪ جي هيش کي انهي جي رسائي حاصل ڪرڻ لاءِ ان کي HashMap ۾ ڏنل انڊيڪس تي. هيش جي حساب سان آپريشن ڏهن نان سيڪنڊن ۾ مڪمل ڪيو ويو آهي. اهو سست آهي VictoriaMetrics لاءِ.

مون خاص طور تي هن ڪيس لاءِ بهتر ڪيل بٽ سيٽ لاڳو ڪرڻ جو فيصلو ڪيو. ھاڻي اھو آھي جيڪو ٻن سلائسن جو چونڪ جھڙو نظر اچي ٿو. هتي اسان هڪ bitset ٺاهي. اسان ان ۾ پهرين سلائس کان عناصر شامل ڪندا آهيون. ان کان پوء اسان ٻئي سلائس ۾ انهن عناصر جي موجودگي کي جانچيندا آهيون. ۽ انھن کي نتيجن ۾ شامل ڪريو. اهو آهي، اهو تقريبا اڳئين مثال کان مختلف ناهي. هتي صرف هڪ شيء آهي ته اسان نقشي تائين رسائي کي ڪسٽم افعال سان تبديل ڪيو add и has.

پهرين نظر ۾، اهو لڳي ٿو ته اهو سست ڪم ڪرڻ گهرجي، جيڪڏهن اڳ ۾ هڪ معياري نقشو استعمال ڪيو ويندو هو، ۽ پوء ڪجهه ٻيا ڪم ڪيا ويندا آهن، پر پروفائلنگ ڏيکاري ٿو ته اها شيء VictoriaMetrics جي صورت ۾ معياري نقشي کان 10 ڀيرا وڌيڪ تيز ڪم ڪري ٿي.

ان کان علاوه، اهو نقشي تي عمل درآمد جي مقابلي ۾ تمام گهٽ ياداشت استعمال ڪري ٿو. ڇو ته اسان هتي اٺ بائيٽ ويلن جي بدران بِٽ محفوظ ڪري رهيا آهيون.

هن عمل درآمد جو نقصان اهو آهي ته اهو ايترو واضح ناهي، معمولي ناهي.

هڪ ٻي خرابي جيڪا ڪيترن ئي کي نوٽيس نه ٿي سگھي ٿي ته اهو عمل ڪجهه ڪيسن ۾ سٺو ڪم نه ڪري سگھي. اهو آهي، اهو هڪ مخصوص ڪيس لاءِ بهتر ڪيو ويو آهي، VictoriaMetrics ٽائيم سيريز ids جي چونڪ جي هن ڪيس لاءِ. هن جو مطلب اهو ناهي ته اهو سڀني ڪيسن لاء مناسب آهي. جيڪڏهن اهو غلط استعمال ڪيو ويو آهي، اسان کي ڪارڪردگي ۾ واڌ نه ملندي، پر ميموري جي غلطي ۽ ڪارڪردگي ۾ سست رفتار.

اچو ته هن ساخت جي عمل تي غور ڪريو. جيڪڏھن توھان ڏسڻ چاھيو ٿا، اھو واقع آھي VictoriaMetrics ذريعن ۾، فولڊر ۾ lib/uint64set. اهو خاص طور تي VictoriaMetrics ڪيس لاءِ بهتر ڪيو ويو آهي، جتي timeseries_id هڪ 64-bit قدر آهي، جتي پهرين 32 بٽ بنيادي طور تي مستقل آهن ۽ صرف آخري 32 بٽ تبديل ٿيندا آهن.

هي ڊيٽا ڍانچي ڊسڪ تي محفوظ نه آهي، اهو صرف ميموري ۾ هلندو آهي.

هتي ان جي API آهي. اهو تمام پيچيده نه آهي. API خاص طور تي VictoriaMetrics استعمال ڪرڻ جي مخصوص مثال سان ٺهيل آهي. اهو آهي، هتي ڪي به غير ضروري ڪم نه آهن. هتي اهي فنڪشن آهن جيڪي واضح طور تي استعمال ڪيا ويا آهن 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 جي ٽائيم سيريز جي جوڙجڪ جي ڄاڻ جي ڄاڻ ڏني وئي، جيڪي VictoriaMetrics ۾ استعمال ڪيا ويا آهن. ۽ انهن جي جوڙجڪ اهڙي آهي ته مٿين 32 بٽ بنيادي طور تي مسلسل آهن. هيٺيون 32 بٽ تبديلي جي تابع آهن. گھٽ گھٽ، گھڻو ڪري اھو تبديل ٿي سگھي ٿو. تنهن ڪري، هي عمل درآمد خاص طور تي هن ڊيٽا جي جوڙجڪ لاء بهتر آهي. سي ++ عمل درآمد، جيترو مون کي خبر آهي، عام ڪيس لاءِ بهتر ڪيو ويو آهي. جيڪڏهن توهان عام ڪيس لاءِ بهتر ڪيو ٿا، ان جو مطلب اهو آهي ته اهو هڪ خاص ڪيس لاءِ سڀ کان وڌيڪ بهتر نه هوندو.

مان توهان کي صلاح ڏيان ٿو ته توهان Alexey Milovid جي رپورٽ کي ڏسو. اٽڪل هڪ مهينو اڳ، هن خاص ماهرن لاءِ ClickHouse ۾ اصلاح بابت ڳالهايو. هو صرف اهو چوي ٿو ته عام صورت ۾، هڪ C ++ عمل درآمد يا ڪجهه ٻيو عمل هڪ اسپتال ۾ سراسري طور تي ڪم ڪرڻ لاء ٺهيل آهي. اهو اسان جي ڄاڻ جي مخصوص عملن کان وڌيڪ خراب ٿي سگهي ٿو، جتي اسان ڄاڻون ٿا ته مٿين 32 بٽ اڪثر ڪري مسلسل آهن.

منهنجو هڪ ٻيو سوال آهي. InfluxDB کان بنيادي فرق ڇا آهي؟

اتي ڪيترائي بنيادي اختلاف آھن. ڪارڪردگي ۽ ميموري جي استعمال جي لحاظ کان، ٽيسٽ ۾ InfluxDB ڏيکاري ٿو 10 ڀيرا وڌيڪ ميموري واپرائڻ اعلي ڪارڊينلٽي ٽائيم سيريز لاءِ، جڏهن توهان وٽ تمام گهڻو آهي، مثال طور، لکين. مثال طور، VictoriaMetrics استعمال ڪري ٿو 1 GB في ملين فعال قطارون، جڏهن ته InfluxDB استعمال ڪري ٿو 10 GB. ۽ اھو ھڪڙو وڏو فرق آھي.

ٻيو بنيادي فرق اهو آهي ته InfluxDB وٽ عجيب سوال ٻوليون آهن - Flux ۽ InfluxQL. اهي وقت سيريز جي مقابلي ۾ ڪم ڪرڻ لاء تمام آسان نه آهن PromQL، جنهن جي حمايت ڪئي وئي آهي VictoriaMetrics. PromQL Prometheus کان هڪ سوال جي ٻولي آهي.

۽ ھڪڙو وڌيڪ فرق اھو آھي ته InfluxDB وٽ ھڪڙو ٿورڙو عجيب ڊيٽا ماڊل آھي، جتي ھر لڪير ڪيترن ئي فيلڊن کي مختلف ٽيگ سان گڏ ڪري سگھي ٿو. اهي سٽون اڳتي هلي مختلف جدولن ۾ ورهايل آهن. اهي اضافي پيچيدگيون هن ڊيٽابيس سان ايندڙ ڪم کي پيچيده ڪن ٿيون. ان جي حمايت ۽ سمجهڻ ڏکيو آهي.

VictoriaMetrics ۾ هر شي تمام آسان آهي. اتي، هر وقت سيريز هڪ اهم قدر آهي. قدر پوائنٽس جو هڪ سيٽ آهي - (timestamp, value)، ۽ اهم سيٽ آهي label=value. فيلڊ ۽ ماپن جي وچ ۾ ڪوبه فرق نه آهي. اهو توهان کي ڪنهن به ڊيٽا کي چونڊڻ جي اجازت ڏئي ٿو ۽ پوء گڏ ڪرڻ، شامل ڪرڻ، گھٽائڻ، ضرب، ورهائڻ، انفلوڪس ڊي بي جي برعڪس جتي مختلف قطارن جي وچ ۾ حساب ڪتاب اڃا تائين لاڳو نه ڪيا ويا آهن جيستائين مون کي ڄاڻ آهي. جيتوڻيڪ اهي لاڳو ڪيا ويا آهن، اهو ڏکيو آهي، توهان کي تمام گهڻو ڪوڊ لکڻو پوندو.

مون وٽ هڪ واضح سوال آهي. ڇا مان صحيح طور تي سمجھيو آھيان ته ڪجھھ قسم جو مسئلو آھي جنھن بابت توھان ڳالھايو آھي، اھو انڊيڪس انڊيڪس ميموري ۾ نٿو اچي، تنھنڪري اتي ورهاڱي آھي؟

پهرين، مون هڪ معياري گو نقشي تي هڪ انڊيڪس انڊيڪس جو هڪ غير معمولي عمل ڏيکاريو. اهو عمل ڊيٽابيس لاءِ موزون نه آهي ڇاڪاڻ ته هي انڊيڪس انڊيڪس ڊسڪ ۾ محفوظ نه ڪيو ويو آهي، ۽ ڊيٽابيس کي ڊسڪ ۾ محفوظ ڪرڻ گهرجي ته جيئن هي ڊيٽا ٻيهر شروع ٿيڻ تي دستياب رهي. هن عمل ۾، جڏهن توهان اپليڪيشن کي ٻيهر شروع ڪندا، توهان جي انڊيڪس انڊيڪس غائب ٿي ويندي. ۽ توهان سڀني ڊيٽا تائين رسائي وڃائي ڇڏيندؤ ڇو ته توهان ان کي ڳولڻ جي قابل نه هوندا.

سلام! رپورٽ لاءِ مهرباني! منهنجو نالو Pavel آهي. مان Wildberries مان آهيان. مون وٽ توھان لاءِ ڪجھ سوال آھن. سوال هڪ. ڇا توهان سوچيو ٿا ته جيڪڏهن توهان هڪ مختلف اصول چونڊيو ها جڏهن توهان پنهنجي ايپليڪيشن جي آرڪيٽيڪچر کي ٺاهيو ۽ وقت سان گڏ ڊيٽا کي ورهايو، ته پوء شايد توهان ڊيٽا کي ٽڪرائڻ جي قابل هوندا، جڏهن ته ڳولها، صرف ان حقيقت جي بنياد تي ته هڪ ورهاڱي ۾ هڪ لاء ڊيٽا شامل آهي. وقت جو عرصو، اهو آهي، هڪ وقت جي وقفي ۾ ۽ توهان کي ان حقيقت جي باري ۾ پريشان ٿيڻ جي ضرورت ناهي ته توهان جا ٽڪرا مختلف طور تي پکڙيل آهن؟ سوال نمبر 2 - جيئن ته توهان بٽ سيٽ ۽ هر شي سان هڪجهڙائي وارو الگورٿم لاڳو ڪري رهيا آهيو، پوءِ شايد توهان پروسيسر هدايتون استعمال ڪرڻ جي ڪوشش ڪئي؟ ٿي سگهي ٿو ته توهان اهڙي اصلاح جي ڪوشش ڪئي آهي؟

مان ٻئي کي فوري طور تي جواب ڏيندس. اسان اڃا تائين ان نقطي تي نه ويا آهيون. پر جيڪڏهن ضروري هجي ته، اسان اتي پهچي وينداسين. ۽ پهريون، سوال ڇا هو؟

توهان ٻن منظرنامي تي بحث ڪيو. ۽ انهن چيو ته انهن هڪ کان وڌيڪ پيچيده عمل سان ٻيو چونڊيو. ۽ انهن پهرين کي ترجيح نه ڏني، جتي ڊيٽا وقت سان ورهايل آهي.

ها. پهرين صورت ۾، انڊيڪس جو ڪل مقدار وڏو هوندو، ڇاڪاڻ ته هر ورهاڱي ۾ اسان کي انهن وقت جي سيريز لاء نقل ڪيل ڊيٽا کي ذخيرو ڪرڻو پوندو، جيڪو انهن سڀني حصن جي ذريعي جاري رهندو. ۽ جيڪڏهن توهان جي ٽائيم سيريز چرن ريٽ ننڍو آهي، يعني ساڳيو سلسلو مسلسل استعمال ڪيو وڃي ٿو، ته پوءِ پهرئين صورت ۾ اسان ٻئي صورت جي مقابلي ۾ ڊسڪ اسپيس تي قبضي جي مقدار ۾ گهڻو ڪجهه وڃائي ويهنداسين.

۽ ائين - ها، وقت جي ورهاڱي هڪ سٺو اختيار آهي. Prometheus ان کي استعمال ڪري ٿو. پر Prometheus هڪ ٻيو نقصان آهي. جڏهن ڊيٽا جي انهن ٽڪرن کي ضم ڪري، ان کي ميموري ميٽا معلومات ۾ رکڻ جي ضرورت آهي سڀني ليبلز ۽ ٽائيم سيريز لاءِ. تنهن ڪري، جيڪڏهن ڊيٽا جا ٽڪرا جيڪي ضم ڪري رهيا آهن وڏا آهن، پوء ضم ٿيڻ دوران ياداشت جو استعمال تمام گهڻو وڌي ٿو، VictoriaMetrics جي برعڪس. ضم ڪرڻ وقت، VictoriaMetrics ميموري کي استعمال نه ڪندو آهي؛ صرف چند ڪلو بائيٽ استعمال ڪيا ويندا آهن، قطع نظر ڊيٽا جي ضم ٿيل ٽڪرن جي سائيز جي.

الورورٿم جيڪو توهان استعمال ڪري رهيا آهيو ميموري استعمال ڪري ٿو. اهو ٽائم سيريز ٽيگ کي نشانو بڻائيندو آهي جنهن ۾ قدر شامل آهن. ۽ هن طريقي سان توهان هڪ ڊيٽا جي صف ۾ ۽ ٻئي ۾ جوڙيل موجودگي جي جانچ ڪريو. ۽ توهان سمجھو ٿا ته هڪ ٽڪرا واقع ٿيا يا نه. عام طور تي، ڊيٽابيس ڪرسر ۽ آئٽرٽر کي لاڳو ڪن ٿا جيڪي انهن جي موجوده مواد کي محفوظ ڪن ٿا ۽ انهن عملن جي سادي پيچيدگي جي ڪري ترتيب ڏنل ڊيٽا ذريعي هلن ٿا.

اسان ڊيٽا کي ٽريڪ ڪرڻ لاء ڪسر ڇو نه استعمال ڪندا آهيون؟

ها.

اسان ترتيب ڏنل قطارن کي LevelDB يا mergeset ۾ ذخيرو ڪندا آهيون. اسان ڪرسر کي منتقل ڪري سگھون ٿا ۽ چونڪ ڳولي سگھون ٿا. اسان ان کي ڇو نه استعمال ڪريون؟ ڇاڪاڻ ته اهو سست آهي. ڇو ته ڪسر جو مطلب آهي ته توهان کي هر لڪير لاء هڪ فنڪشن سڏڻ جي ضرورت آهي. هڪ فنڪشن ڪال 5 نانو سيڪنڊ آهي. ۽ جيڪڏهن توهان وٽ 100 لائينون آهن، ته پوء اهو ظاهر ٿئي ٿو ته اسان اڌ سيڪنڊ صرف فنڪشن کي سڏيندا آهيون.

اتي هڪ اهڙي شيء آهي، ها. ۽ منهنجو آخري سوال. سوال ٿورڙو عجيب آواز ٿي سگھي ٿو. اهو ممڪن ڇو نه آهي ته سڀني ضروري مجموعن کي پڙهڻ وقت جڏهن ڊيٽا اچي ٿي ۽ انهن کي گهربل فارم ۾ محفوظ ڪيو وڃي؟ ڪجهه سسٽم جهڙوڪ VictoriaMetrics، ClickHouse، وغيره ۾ وڏي مقدار کي ڇو بچايو، ۽ پوء انهن تي گهڻو وقت گذاريو؟

ان کي واضح ڪرڻ لاءِ مان هڪ مثال ڏيندس. اچو ته ٻڌايو ته هڪ ننڍڙو رانديڪو اسپيڊ ميٽر ڪيئن ڪم ڪندو آهي؟ اهو رڪارڊ ڪري ٿو جيڪو فاصلو توهان سفر ڪيو آهي، هر وقت ان کي هڪ قدر ۾ شامل ڪندي، ۽ ٻيو - وقت. ۽ ورهائي ٿو. ۽ سراسري رفتار حاصل ڪري ٿي. توهان ساڳئي شيء بابت ڪري سگهو ٿا. پرواز تي سڀ ضروري حقيقتون شامل ڪريو.

چڱو، مان سوال سمجھان ٿو. تنهنجو مثال پنهنجي جاءِ تي آهي. جيڪڏهن توهان کي خبر آهي ته توهان کي ڪهڙي مجموعي جي ضرورت آهي، پوء اهو بهترين عمل درآمد آهي. پر مسئلو اهو آهي ته ماڻهو انهن ميٽرڪس کي محفوظ ڪن ٿا، ڪجهه ڊيٽا ClickHouse ۾ ۽ اهي اڃا تائين نه ٿا ڄاڻن ته اهي ڪيئن گڏ ڪندا ۽ مستقبل ۾ فلٽر ڪندا، تنهنڪري انهن کي سڀني خام ڊيٽا کي بچائڻو پوندو. پر جيڪڏهن توهان کي خبر آهي ته توهان کي ڪنهن شيءِ کي اوسط ۾ ڳڻڻ جي ضرورت آهي، ته پوءِ اتي خام قدرن جو هڪ گروپ رکڻ بدران ان جو حساب ڇو نه ڪجي؟ پر اهو صرف آهي جيڪڏهن توهان ڄاڻو ٿا ته توهان کي ڪهڙي ضرورت آهي.

رستي جي ذريعي، وقت جي سيريز کي محفوظ ڪرڻ لاء ڊيٽابيس مجموعي جي ڳڻپ جي حمايت ڪن ٿا. مثال طور، Prometheus جي حمايت رڪارڊنگ ضابطا. اهو آهي، اهو ٿي سگهي ٿو جيڪڏهن توهان ڄاڻو ٿا ته توهان کي ڪهڙي يونٽ جي ضرورت پوندي. VictoriaMetrics وٽ اڃا تائين اهو ناهي، پر اهو عام طور تي Prometheus کان اڳ هوندو آهي، جنهن ۾ اهو ڪري سگهجي ٿو ريڪوڊنگ قاعدن ۾.

مثال طور، منهنجي پوئين نوڪريءَ ۾ مون کي ضرورت هئي ته گذريل ڪلاڪ دوران سلائيڊنگ ونڊو ۾ واقعن جو تعداد ڳڻڻ. مسئلو اهو آهي ته مون کي گو ۾ هڪ ڪسٽم لاڳو ڪرڻ هو، يعني هن شيء کي ڳڻڻ لاء هڪ خدمت. اها خدمت آخرڪار غير معمولي هئي، ڇاڪاڻ ته اهو حساب ڪرڻ ڏکيو آهي. عمل سادو ٿي سگهي ٿو جيڪڏهن توهان کي ڪجهه مجموعن کي مقرر وقت جي وقفن تي ڳڻڻ جي ضرورت آهي. جيڪڏھن توھان چاھيو ٿا واقعن کي سلائڊنگ ونڊو ۾ ڳڻڻ، پوءِ اھو ايترو سادو نه آھي جيترو لڳي ٿو. منهنجو خيال آهي ته اهو اڃا تائين ClickHouse يا Timeseries ڊيٽابيس ۾ لاڳو نه ڪيو ويو آهي، ڇاڪاڻ ته اهو لاڳو ڪرڻ ڏکيو آهي.

۽ هڪ وڌيڪ سوال. اسان صرف اوسط جي باري ۾ ڳالهائي رهيا هئاسين، ۽ مون کي ياد آهي ته هڪ ڀيرو ڪا اهڙي شيء هئي جيئن ڪاربان پس منظر سان گرافائٽ. ۽ هن کي خبر هئي ته پراڻي ڊيٽا کي ڪيئن ختم ڪجي، يعني هڪ پوائنٽ في منٽ، هڪ پوائنٽ في ڪلاڪ وغيره ڇڏي ڏيو. اصولي طور تي، اهو ڪافي آسان آهي جيڪڏهن اسان کي خام ڊيٽا جي ضرورت هجي، نسبتا ڳالهائڻ، هڪ مهيني لاءِ، ۽ ٻيو سڀ ڪجهه. پتلي ٿيڻ. پر Prometheus ۽ VictoriaMetrics هن فنڪشنلٽي کي سپورٽ نٿا ڪن. ڇا ان جي حمايت ڪرڻ جو منصوبو آهي؟ جيڪڏهن نه، ڇو نه؟

سوال لاءِ مهرباني. اسان جا صارف وقتي طور تي هي سوال پڇندا آهن. اهي پڇن ٿا جڏهن اسان نموني جي مدد لاءِ شامل ڪنداسين. هتي ڪيترائي مسئلا آهن. پهرين، هر صارف سمجهي ٿو downsampling ڪجھ مختلف: ڪو چاھي ٿو ڪنھن صوابديدي نقطي کي ڏنل وقفي تي، ڪو چاھي ٿو وڌ ۾ وڌ، گھٽ ۾ گھٽ، سراسري قدر. جيڪڏهن ڪيترائي سسٽم توهان جي ڊيٽابيس ۾ ڊيٽا لکندا آهن، پوء توهان ان کي گڏ نه ٿا ڪري سگهو. اهو ٿي سگهي ٿو ته هر نظام کي مختلف thinning جي ضرورت آهي. ۽ اهو عمل ڪرڻ ڏکيو آهي.

۽ ٻي ڳالهه اها آهي ته VictoriaMetrics، ClickHouse وانگر، وڏي مقدار ۾ خام ڊيٽا تي ڪم ڪرڻ لاءِ بهتر ڪيل آهي، تنهنڪري اهو هڪ سيڪنڊ کان به گهٽ وقت ۾ هڪ بلين لائينون ڦاڙي سگهي ٿو جيڪڏهن توهان وٽ توهان جي سسٽم ۾ ڪيترائي ڪور آهن. VictoriaMetrics ۾ اسڪيننگ ٽائيم سيريز پوائنٽس - 50 پوائنٽس في سيڪنڊ في ڪور. ۽ هي ڪارڪردگي موجوده ڪور تائين ماپ ڪري ٿو. اهو آهي، جيڪڏهن توهان وٽ 000 ڪور آهن، مثال طور، توهان في سيڪنڊ هڪ ارب پوائنٽ اسڪين ڪندا. ۽ VictoriaMetrics ۽ ClickHouse جي هي ملڪيت گھٽائڻ جي ضرورت کي گھٽائي ٿي.

ٻي خاصيت اها آهي ته VictoriaMetrics هن ڊيٽا کي مؤثر طريقي سان دٻائي ٿو. پيداوار ۾ اوسط تي ڪمپريشن 0,4 کان 0,8 بائيٽ في پوائنٽ تائين آهي. هر پوائنٽ هڪ ٽائم اسٽيمپ + قدر آهي. ۽ اهو اوسط تي هڪ بائيٽ کان گهٽ ۾ ٺهيل آهي.

سرجي. مون کي هڪ سوال آهي. گهٽ ۾ گهٽ رڪارڊنگ وقت جو مقدار ڇا آهي؟

هڪ ملي سيڪنڊ. اسان تازو ئي گفتگو ڪئي هئي ٻين ٽائيم سيريز ڊيٽابيس ڊولپرز سان. انهن جو گهٽ ۾ گهٽ وقت جو ٽڪرو هڪ سيڪنڊ آهي. ۽ Graphite ۾، مثال طور، اهو پڻ هڪ سيڪنڊ آهي. OpenTSDB ۾ اهو پڻ هڪ سيڪنڊ آهي. InfluxDB وٽ nanosecond درستگي آهي. VictoriaMetrics ۾ اهو هڪ ملي سيڪنڊ آهي، ڇاڪاڻ ته Prometheus ۾ اهو هڪ ملي سيڪنڊ آهي. ۽ VictoriaMetrics اصل ۾ Prometheus لاءِ ريموٽ اسٽوريج جي طور تي ترقي ڪئي وئي. پر هاڻي اهو ٻين سسٽم کان ڊيٽا محفوظ ڪري سگهي ٿو.

جنهن شخص سان مون ڳالهايو هو چوي ٿو ته انهن وٽ سيڪنڊ کان سيڪنڊ جي درستگي آهي - اهو انهن لاءِ ڪافي آهي ڇاڪاڻ ته اهو ان ڊيٽا جي قسم تي منحصر آهي جيڪو ٽائيم سيريز ڊيٽابيس ۾ محفوظ ڪيو پيو وڃي. جيڪڏهن اهو آهي DevOps ڊيٽا يا انفراسٽرڪچر مان ڊيٽا، جتي توهان ان کي گڏ ڪريو ٿا 30 سيڪنڊن جي وقفن تي، في منٽ، پوءِ سيڪنڊ جي درستگي ڪافي آهي، توهان کي ڪجهه به گهٽ نه گهرجي. ۽ جيڪڏھن توھان ھي ڊيٽا گڏ ڪندا آھيو اعلي تعدد واري واپاري نظام مان، پوء توھان کي ضرورت آھي نانو سيڪنڊ جي درستگي.

VictoriaMetrics ۾ مليسيڪنڊ جي درستگي پڻ DevOps ڪيس لاءِ موزون آهي، ۽ اڪثر ڪيسن لاءِ موزون ٿي سگهي ٿي جن جو مون رپورٽ جي شروعات ۾ ذڪر ڪيو آهي. صرف هڪ شيءِ جنهن لاءِ اهو مناسب نه ٿي سگهي آهي اعلي تعدد واري واپاري نظام.

تنهنجي مهرباني! ۽ ٻيو سوال. PromQL ۾ مطابقت ڇا آهي؟

مڪمل پسمانده مطابقت. VictoriaMetrics مڪمل طور تي PromQL کي سپورٽ ڪري ٿو. ان کان علاوه، اهو PromQL ۾ اضافي ترقي يافته ڪارڪردگي شامل ڪري ٿو، جنهن کي سڏيو ويندو آهي MetricsQL. ھن وڌايل ڪارڪردگي بابت يوٽيوب تي ڳالھ ٻولھ آھي. مون سينٽ پيٽرسبرگ ۾ بهار ۾ مانيٽرنگ ميٽ اپ ۾ ڳالهايو.

ٽيليگرام چينل وڪٽوريا ميٽرڪس.

صرف رجسٽرڊ استعمال ڪندڙ سروي ۾ حصو وٺي سگهن ٿا. سائن ان ڪريو، توهان جي مهرباني.

ڇا توهان کي VictoriaMetrics ڏانهن سوئچ ڪرڻ کان روڪيو آهي جيئن توهان جي Prometheus لاءِ ڊگهي مدي واري اسٽوريج؟ (تبصرن ۾ لکو، مان ان کي پول ۾ شامل ڪندس))

• 71,4٪مان استعمال نٿو ڪريان Prometheus5

• 28,6٪VictoriaMetrics2 بابت ڄاڻ نه هئي

7 صارفين ووٽ ڏنو. 12 استعمال ڪندڙن کي روڪيو ويو.

جو ذريعو: www.habr.com