وکٹوریہ میٹرکس میں آپٹیمائزیشن پر جائیں۔ الیگزینڈر ویلیالکن

میرا مشورہ ہے کہ آپ الیگزینڈر ویلالکن کی 2019 کے آخر کی رپورٹ کا ٹرانسکرپٹ پڑھیں "VictoriaMetrics میں آپٹیمائزیشن پر جائیں"

وکٹوریہ میٹرکس - ٹائم سیریز کی شکل میں ڈیٹا کو ذخیرہ کرنے اور اس پر کارروائی کرنے کے لیے ایک تیز رفتار اور توسیع پذیر DBMS (ریکارڈ وقت اور اس وقت کے مطابق اقدار کا ایک سیٹ بناتا ہے، مثال کے طور پر، سینسرز کی حیثیت کی متواتر پولنگ یا جمع کرنے کے ذریعے حاصل کیا جاتا ہے۔ میٹرکس)۔

اس رپورٹ کی ویڈیو کا لنک یہ ہے- https://youtu.be/MZ5P21j_HLE

سلائیڈز

کچھ اپنے بارے میں بتائیں. میں الیگزینڈر ویلیالکن ہوں۔ یہاں میرا GitHub اکاؤنٹ. میں گو اور کارکردگی کی اصلاح کے بارے میں پرجوش ہوں۔ میں نے بہت ساری مفید اور بہت مفید لائبریریاں لکھیں۔ وہ دونوں سے شروع کرتے ہیں۔ fast، یا کے ساتھ quick سابقہ

میں فی الحال VictoriaMetrics پر کام کر رہا ہوں۔ یہ کیا ہے اور میں وہاں کیا کر رہا ہوں؟ میں اس پریزنٹیشن میں اس کے بارے میں بات کروں گا۔

رپورٹ کا خاکہ درج ذیل ہے:

• پہلے، میں آپ کو بتاؤں گا کہ VictoriaMetrics کیا ہے۔
• پھر میں آپ کو بتاؤں گا کہ ٹائم سیریز کیا ہیں۔
• پھر میں آپ کو بتاؤں گا کہ ٹائم سیریز کا ڈیٹا بیس کیسے کام کرتا ہے۔
• اگلا، میں آپ کو ڈیٹا بیس کے فن تعمیر کے بارے میں بتاؤں گا: یہ کس چیز پر مشتمل ہے۔
• اور پھر آئیے ان اصلاحوں کی طرف بڑھتے ہیں جو وکٹوریہ میٹرکس کے پاس ہیں۔ یہ الٹا انڈیکس کے لیے ایک اصلاح ہے اور Go میں بٹ سیٹ کے نفاذ کے لیے ایک اصلاح ہے۔

کیا سامعین میں سے کوئی جانتا ہے کہ وکٹوریہ میٹرکس کیا ہے؟ واہ، بہت سے لوگ پہلے ہی جانتے ہیں۔ یہ ایک اچھی خبر ہے۔ ان لوگوں کے لیے جو نہیں جانتے، یہ ٹائم سیریز کا ڈیٹا بیس ہے۔ یہ ClickHouse کے فن تعمیر پر مبنی ہے، ClickHouse کے نفاذ کی کچھ تفصیلات پر۔ مثال کے طور پر، جیسے کہ: MergeTree، تمام دستیاب پروسیسر کور پر متوازی حساب کتاب اور پروسیسر کیشے میں رکھے گئے ڈیٹا بلاکس پر کام کرکے کارکردگی کی اصلاح۔

وکٹوریہ میٹرکس دیگر ٹائم سیریز ڈیٹا بیسز کے مقابلے بہتر ڈیٹا کمپریشن فراہم کرتا ہے۔

یہ عمودی طور پر پیمانہ ہے - یعنی آپ ایک کمپیوٹر پر مزید پروسیسرز، زیادہ RAM شامل کر سکتے ہیں۔ 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 میں، آپ CPU، RAM، نیٹ ورک، rps، غلطیوں کی تعداد وغیرہ کی پیمائش کر سکتے ہیں۔
• IoT - ہم درجہ حرارت، دباؤ، جیو کوآرڈینیٹ اور کچھ اور پیمائش کر سکتے ہیں۔
• مالیات بھی - ہم ہر قسم کے اسٹاک اور کرنسیوں کی قیمتوں کی نگرانی کر سکتے ہیں۔
• اس کے علاوہ، ٹائم سیریز کا استعمال فیکٹریوں میں پیداواری عمل کی نگرانی میں کیا جا سکتا ہے۔ ہمارے پاس ایسے صارفین ہیں جو روبوٹ کے لیے ونڈ ٹربائنز کی نگرانی کے لیے VictoriaMetrics کا استعمال کرتے ہیں۔
• ٹائم سیریز مختلف آلات کے سینسرز سے معلومات اکٹھی کرنے کے لیے بھی کارآمد ہیں۔ مثال کے طور پر، انجن کے لیے؛ ٹائر پریشر کی پیمائش کے لیے؛ رفتار، فاصلے کی پیمائش کے لیے؛ پٹرول کی کھپت وغیرہ کی پیمائش کے لیے
• ٹائم سیریز کو ہوائی جہاز کی نگرانی کے لیے بھی استعمال کیا جا سکتا ہے۔ ہر طیارے میں ایک بلیک باکس ہوتا ہے جو ہوائی جہاز کی صحت کے مختلف پیرامیٹرز کے لیے ٹائم سیریز جمع کرتا ہے۔ ٹائم سیریز ایرو اسپیس انڈسٹری میں بھی استعمال ہوتی ہیں۔
• ہیلتھ کیئر بلڈ پریشر، نبض وغیرہ ہے۔

ہو سکتا ہے اور بھی ایپلی کیشنز ہوں جن کے بارے میں میں بھول گیا ہوں، لیکن مجھے امید ہے کہ آپ سمجھ گئے ہوں گے کہ جدید دنیا میں ٹائم سیریز فعال طور پر استعمال ہوتی ہے۔ اور ان کے استعمال کا حجم ہر سال بڑھ رہا ہے۔

آپ کو ٹائم سیریز ڈیٹا بیس کی ضرورت کیوں ہے؟ آپ ٹائم سیریز کو ذخیرہ کرنے کے لیے باقاعدہ متعلقہ ڈیٹا بیس کیوں استعمال نہیں کر سکتے؟

کیونکہ ٹائم سیریز میں عام طور پر معلومات کی ایک بڑی مقدار ہوتی ہے، جسے روایتی ڈیٹا بیس میں محفوظ کرنا اور اس پر کارروائی کرنا مشکل ہوتا ہے۔ لہذا، ٹائم سیریز کے لئے خصوصی ڈیٹا بیس ظاہر ہوا. یہ اڈے مؤثر طریقے سے پوائنٹس کو محفوظ کرتے ہیں۔ (timestamp, value) دی گئی چابی کے ساتھ۔ وہ کلید کے ذریعے، ایک کلیدی قدر کے جوڑے کے ذریعے، یا متعدد کلیدی قدر کے جوڑوں کے ذریعے، یا regexp کے ذریعے ذخیرہ شدہ ڈیٹا کو پڑھنے کے لیے ایک API فراہم کرتے ہیں۔ مثال کے طور پر، آپ امریکہ میں ڈیٹا سینٹر میں اپنی تمام سروسز کا CPU لوڈ تلاش کرنا چاہتے ہیں، پھر آپ کو یہ چھدم استفسار استعمال کرنے کی ضرورت ہے۔

عام طور پر ٹائم سیریز ڈیٹا بیس خصوصی استفسار کی زبانیں فراہم کرتے ہیں کیونکہ ٹائم سیریز SQL بہت مناسب نہیں ہے۔ اگرچہ ایس کیو ایل کو سپورٹ کرنے والے ڈیٹا بیس موجود ہیں، لیکن یہ زیادہ موزوں نہیں ہے۔ سوالات کی زبانیں جیسے پروم کیو ایل, انفلوکس کیو ایل, بہاؤ, Q. مجھے امید ہے کہ کسی نے ان میں سے کم از کم ایک زبان سنی ہو گی۔ بہت سے لوگوں نے شاید PromQL کے بارے میں سنا ہوگا۔ یہ پرومیتھیس استفسار کی زبان ہے۔

یہ وہی ہے جو ایک جدید ٹائم سیریز ڈیٹا بیس فن تعمیر کی طرح دکھائی دیتا ہے جیسا کہ وکٹوریہ میٹرکس کو بطور مثال استعمال کرتے ہوئے۔

یہ دو حصوں پر مشتمل ہے۔ یہ الٹی انڈیکس کے لیے اسٹوریج اور ٹائم سیریز کی قدروں کے لیے اسٹوریج ہے۔ یہ ذخیرے الگ ہیں۔

جب ڈیٹا بیس میں ایک نیا ریکارڈ آتا ہے، تو ہم سب سے پہلے کسی مقررہ سیٹ کے لیے ٹائم سیریز شناخت کنندہ کو تلاش کرنے کے لیے الٹی انڈیکس تک رسائی حاصل کرتے ہیں۔ 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)، جو سٹرنگ کو ints کے ٹکڑے کرنے کے لیے نقشہ بنائے گا۔ لائن پر مشتمل ہے۔ label=value.

فنکشن کا نفاذ: حاصل کریں۔ metricIDs پہلے کے لیے label=value، پھر ہم ہر چیز سے گزرتے ہیں۔ label=value، ہم اسے حاصل کرتے ہیں۔ metricIDs ان کے لیے. اور فنکشن کو کال کریں۔ intersectInts، جس پر ذیل میں تبادلہ خیال کیا جائے گا۔ اور یہ فنکشن ان لسٹوں کا انٹرسیکشن لوٹاتا ہے۔

جیسا کہ آپ دیکھ سکتے ہیں، الٹی انڈیکس کو لاگو کرنا زیادہ پیچیدہ نہیں ہے۔ لیکن یہ ایک سادہ عمل ہے۔ اس کے کیا نقصانات ہیں؟ بولی نفاذ کا بنیادی نقصان یہ ہے کہ اس طرح کا الٹا انڈیکس RAM میں محفوظ ہے۔ ایپلیکیشن کو دوبارہ شروع کرنے کے بعد ہم اس انڈیکس کو کھو دیتے ہیں۔ اس انڈیکس کی ڈسک میں کوئی بچت نہیں ہے۔ اس طرح کا الٹا انڈیکس ڈیٹا بیس کے لیے موزوں ہونے کا امکان نہیں ہے۔

دوسری خرابی بھی یادداشت سے متعلق ہے۔ الٹا انڈیکس RAM میں فٹ ہونا چاہیے۔ اگر یہ RAM کے سائز سے زیادہ ہے، تو ظاہر ہے کہ ہم میموری کی خرابی سے باہر نکلیں گے۔ اور پروگرام کام نہیں کرے گا۔

یہ مسئلہ ریڈی میڈ حل جیسے کہ استعمال کرکے حل کیا جاسکتا ہے۔ لیول ڈی بییا راکس ڈی بی۔.

مختصراً، ہمیں ایک ڈیٹا بیس کی ضرورت ہے جو ہمیں تیزی سے تین آپریشن کرنے کی اجازت دیتا ہے۔

• پہلا آپریشن ریکارڈنگ ہے۔ ключ-значение اس ڈیٹا بیس میں۔ وہ یہ کام بہت جلد کرتی ہے، کہاں ключ-значение صوابدیدی تار ہیں۔
• دوسرا آپریشن دی گئی کلید کا استعمال کرتے ہوئے کسی قدر کی فوری تلاش ہے۔
• اور تیسرا آپریشن دیے گئے سابقہ ​​کے ذریعہ تمام اقدار کی فوری تلاش ہے۔

LevelDB اور RocksDB - یہ ڈیٹا بیس گوگل اور فیس بک نے تیار کیے تھے۔ پہلے لیول ڈی بی آیا۔ پھر فیس بک کے لڑکوں نے LevelDB لیا اور اسے بہتر کرنا شروع کر دیا، انہوں نے RocksDB بنایا۔ اب تقریباً تمام داخلی ڈیٹا بیس فیس بک کے اندر RocksDB پر کام کرتے ہیں، بشمول وہ جو RocksDB اور MySQL میں منتقل ہو چکے ہیں۔ انہوں نے اس کا نام رکھا مائی راکس.

لیول ڈی بی کا استعمال کرتے ہوئے الٹا انڈیکس لاگو کیا جاسکتا ہے۔ یہ کیسے کرنا ہے؟ ہم ایک کلید کے طور پر محفوظ کرتے ہیں۔ label=value. اور قدر وقت کی سیریز کا شناخت کنندہ ہے جہاں جوڑا موجود ہے۔ label=value.

اگر ہمارے پاس دی گئی جوڑی کے ساتھ کئی ٹائم سیریز ہیں۔ label=value، پھر اس ڈیٹا بیس میں ایک ہی کلید اور مختلف کے ساتھ بہت سی قطاریں ہوں گی۔ timeseries_ids. سب کی فہرست حاصل کرنے کے لیے timeseries_ids، جو اس سے شروع ہوتا ہے۔ label=prefix، ہم ایک رینج اسکین کرتے ہیں جس کے لیے یہ ڈیٹا بیس بہتر بنایا گیا ہے۔ یعنی ہم ان تمام لائنوں کو منتخب کرتے ہیں جو شروع ہوتی ہیں۔ label=prefix اور ضروری حاصل کریں timeseries_ids.

گو میں یہ کیسا نظر آئے گا اس کا ایک نمونہ نفاذ یہاں ہے۔ ہمارے پاس الٹا انڈیکس ہے۔ یہ لیول ڈی بی ہے۔

فنکشن وہی ہے جو بولی نفاذ کے لئے ہے۔ یہ بولی نفاذ کو تقریباً لائن بہ لائن دہراتا ہے۔ بات صرف یہ ہے کہ اس کی طرف رجوع کرنے کی بجائے map ہم الٹی انڈیکس تک رسائی حاصل کرتے ہیں۔ ہمیں پہلے کے لیے تمام اقدار مل جاتی ہیں۔ label=value. پھر ہم باقی تمام جوڑوں کے ذریعے جاتے ہیں label=value اور ان کے لیے metricIDs کے متعلقہ سیٹ حاصل کریں۔ پھر ہم چوراہا تلاش کرتے ہیں۔

سب کچھ ٹھیک لگ رہا ہے، لیکن اس حل میں خرابیاں ہیں. وکٹوریہ میٹرکس نے ابتدائی طور پر لیول ڈی بی پر مبنی ایک الٹا انڈیکس نافذ کیا۔ لیکن آخر کار مجھے اسے ترک کرنا پڑا۔

کیوں؟ کیونکہ لیول ڈی بی بولی نفاذ سے سست ہے۔ ایک سادہ عمل میں، ایک دی گئی کلید دی گئی، ہم فوری طور پر پورا ٹکڑا بازیافت کرتے ہیں۔ metricIDs. یہ ایک بہت تیز آپریشن ہے - پورا سلائس استعمال کے لیے تیار ہے۔

LevelDB میں، ہر بار ایک فنکشن بلایا جاتا ہے۔ GetValues آپ کو ان تمام لائنوں سے گزرنا ہوگا جو شروع ہوتی ہیں۔ label=value. اور ہر لائن کی قدر حاصل کریں۔ timeseries_ids. اس طرح کے timeseries_ids ان کا ایک ٹکڑا جمع کریں timeseries_ids. ظاہر ہے، یہ کلید کے ذریعے باقاعدہ نقشے تک رسائی سے کہیں زیادہ سست ہے۔

دوسری خرابی یہ ہے کہ لیول ڈی بی سی میں لکھا گیا ہے۔ گو سے سی فنکشنز کو کال کرنا بہت تیز نہیں ہے۔ اس میں سینکڑوں نینو سیکنڈ لگتے ہیں۔ یہ بہت تیز نہیں ہے، کیونکہ گو میں لکھی گئی باقاعدہ فنکشن کال کے مقابلے، جس میں 1-5 نینو سیکنڈ لگتے ہیں، کارکردگی میں فرق دسیوں گنا ہے۔ وکٹوریہ میٹرکس کے لیے یہ ایک مہلک خامی تھی :)

تو میں نے الٹا انڈیکس کا اپنا نفاذ لکھا۔ اور اس نے اسے بلایا ضم.

Mergeset MergeTree ڈیٹا ڈھانچے پر مبنی ہے۔ یہ ڈیٹا ڈھانچہ ClickHouse سے مستعار لیا گیا ہے۔ ظاہر ہے، تیزی سے تلاش کے لیے mergeset کو بہتر بنایا جانا چاہیے۔ timeseries_ids دی گئی کلید کے مطابق۔ مرج سیٹ مکمل طور پر گو میں لکھا گیا ہے۔ آپ دیکھ سکتے ہیں گٹ ہب پر وکٹوریہ میٹرکس کے ذرائع. mergeset کا نفاذ فولڈر میں ہے۔ /lib/mergeset. آپ یہ جاننے کی کوشش کر سکتے ہیں کہ وہاں کیا ہو رہا ہے۔

mergeset API LevelDB اور RocksDB سے بہت ملتا جلتا ہے۔ یعنی، یہ آپ کو وہاں نئے ریکارڈز کو تیزی سے محفوظ کرنے اور دیے گئے سابقہ ​​سے ریکارڈز کو تیزی سے منتخب کرنے کی اجازت دیتا ہے۔

ہم بعد میں انضمام کے نقصانات کے بارے میں بات کریں گے۔ اب آئیے اس بارے میں بات کرتے ہیں کہ الٹی انڈیکس کو لاگو کرتے وقت پیداوار میں وکٹوریہ میٹرکس کے ساتھ کیا مسائل پیدا ہوئے۔

وہ کیوں پیدا ہوئے؟

پہلی وجہ ہائی گرن ریٹ ہے۔ روسی میں ترجمہ کیا گیا، یہ وقت کی سیریز میں ایک بار بار تبدیلی ہے۔ یہ اس وقت ہوتا ہے جب ایک ٹائم سیریز ختم ہوتی ہے اور ایک نئی سیریز شروع ہوتی ہے، یا بہت سی نئی ٹائم سیریز شروع ہوتی ہیں۔ اور یہ اکثر ہوتا ہے۔

دوسری وجہ ٹائم سیریز کی بڑی تعداد ہے۔ شروع میں، جب مانیٹرنگ مقبولیت حاصل کر رہی تھی، ٹائم سیریز کی تعداد کم تھی۔ مثال کے طور پر، ہر کمپیوٹر کے لیے آپ کو CPU، میموری، نیٹ ورک اور ڈسک لوڈ کی نگرانی کرنے کی ضرورت ہے۔ فی کمپیوٹر 4 ٹائم سیریز۔ فرض کریں کہ آپ کے پاس 100 کمپیوٹرز اور 400 ٹائم سیریز ہیں۔ یہ بہت کم ہے۔

وقت گزرنے کے ساتھ، لوگوں کو معلوم ہوا کہ وہ مزید دانے دار معلومات کی پیمائش کر سکتے ہیں۔ مثال کے طور پر، پورے پروسیسر کا بوجھ نہیں بلکہ ہر پروسیسر کور کا الگ الگ پیمائش کریں۔ اگر آپ کے پاس 40 پروسیسر کور ہیں، تو آپ کے پاس پروسیسر بوجھ کی پیمائش کرنے کے لیے 40 گنا زیادہ ٹائم سیریز ہے۔

لیکن یہ سب کچھ نہیں ہے۔ ہر پروسیسر کور میں کئی حالتیں ہوسکتی ہیں، جیسے کہ بیکار، جب یہ بیکار ہو۔ اور یوزر اسپیس میں بھی کام کریں، کرنل اسپیس اور دیگر ریاستوں میں کام کریں۔ اور ایسی ہر ریاست کو ایک الگ ٹائم سیریز کے طور پر بھی ماپا جا سکتا ہے۔ اس کے علاوہ قطاروں کی تعداد میں 7-8 گنا اضافہ ہوتا ہے۔

ایک میٹرک سے ہمیں صرف ایک کمپیوٹر کے لیے 40 x 8 = 320 میٹرکس ملے۔ 100 سے ضرب کریں، ہمیں 32 کے بجائے 000 ملتے ہیں۔

پھر کبرنیٹس ساتھ آئے۔ اور یہ بدتر ہو گیا کیونکہ Kubernetes بہت سی مختلف خدمات کی میزبانی کر سکتا ہے۔ Kubernetes میں ہر سروس بہت سے pods پر مشتمل ہے. اور اس سب پر نظر رکھنے کی ضرورت ہے۔ اس کے علاوہ، ہمارے پاس آپ کی خدمات کے نئے ورژنز کی مستقل تعیناتی ہے۔ ہر نئے ورژن کے لیے، نئی ٹائم سیریز بنائی جانی چاہیے۔ نتیجے کے طور پر، ٹائم سیریز کی تعداد میں تیزی سے اضافہ ہوتا ہے اور ہمیں ٹائم سیریز کی ایک بڑی تعداد کے مسئلے کا سامنا کرنا پڑتا ہے، جسے ہائی کارڈنالٹی کہا جاتا ہے۔ وکٹوریہ میٹرکس دوسرے ٹائم سیریز ڈیٹا بیس کے مقابلے کامیابی سے اس کا مقابلہ کرتی ہے۔

آئیے ہائی گرن ریٹ پر گہری نظر ڈالیں۔ کیا پیداوار میں ایک اعلی churn کی شرح کا سبب بنتا ہے؟ کیونکہ لیبل اور ٹیگ کے کچھ معنی مسلسل بدلتے رہتے ہیں۔

مثال کے طور پر، Kubernetes لیں، جس کا تصور ہے۔ deployment، یعنی جب آپ کی ایپلیکیشن کا نیا ورژن رول آؤٹ ہوتا ہے۔ کسی وجہ سے، Kubernetes کے ڈویلپرز نے لیبل میں تعیناتی id شامل کرنے کا فیصلہ کیا۔

اس سے کیا ہوا؟ مزید برآں، ہر نئی تعیناتی کے ساتھ، تمام پرانی ٹائم سیریز میں خلل پڑتا ہے، اور ان کے بجائے، نئی ٹائم سیریز ایک نئی لیبل ویلیو کے ساتھ شروع ہوتی ہے۔ deployment_id. اس طرح کی قطاریں سیکڑوں ہزاروں اور لاکھوں بھی ہوسکتی ہیں۔

ان سب کے بارے میں اہم بات یہ ہے کہ ٹائم سیریز کی کل تعداد بڑھتی ہے، لیکن ٹائم سیریز کی تعداد جو فی الحال فعال ہیں اور ڈیٹا حاصل کر رہی ہیں، مستقل رہتی ہیں۔ اس حالت کو ہائی کرن ریٹ کہا جاتا ہے۔

ہائی کرن ریٹ کا بنیادی مسئلہ ایک مخصوص وقت کے وقفے پر لیبلز کے دیئے گئے سیٹ کے لیے تمام ٹائم سیریز کے لیے مستقل تلاش کی رفتار کو یقینی بنانا ہے۔ عام طور پر یہ آخری گھنٹے یا آخری دن کا وقفہ ہوتا ہے۔

اس مسئلے کو کیسے حل کیا جائے؟ یہاں پہلا آپشن ہے۔ یہ الٹی انڈیکس کو وقت کے ساتھ آزاد حصوں میں تقسیم کرنا ہے۔ یعنی کچھ وقت کا وقفہ گزرتا ہے، ہم موجودہ الٹی انڈیکس کے ساتھ کام ختم کرتے ہیں۔ اور ایک نیا الٹا انڈیکس بنائیں۔ ایک اور وقت کا وقفہ گزر جاتا ہے، ہم ایک اور اور دوسرا بناتے ہیں۔

اور جب ان الٹے اشاریوں سے نمونے لیتے ہیں، تو ہمیں الٹے اشاریہ جات کا ایک مجموعہ ملتا ہے جو دیے گئے وقفے کے اندر آتا ہے۔ اور، اس کے مطابق، ہم وہاں سے ٹائم سیریز کی آئی ڈی منتخب کرتے ہیں۔

اس سے وسائل کی بچت ہوتی ہے کیونکہ ہمیں ان حصوں کو دیکھنے کی ضرورت نہیں ہے جو دیئے گئے وقفے کے اندر نہیں آتے ہیں۔ یعنی، عام طور پر، اگر ہم آخری گھنٹے کے لیے ڈیٹا منتخب کرتے ہیں، تو پچھلے وقت کے وقفوں کے لیے ہم درخواستوں کو چھوڑ دیتے ہیں۔

اس مسئلے کو حل کرنے کے لیے ایک اور آپشن ہے۔ یہ ہر دن کے لیے اس دن پیش آنے والی ٹائم سیریز کی آئی ڈیز کی ایک الگ فہرست کو اسٹور کرنا ہے۔

پچھلے حل کے مقابلے اس حل کا فائدہ یہ ہے کہ ہم ٹائم سیریز کی معلومات کی نقل نہیں بناتے ہیں جو وقت کے ساتھ غائب نہیں ہوتی ہے۔ وہ مسلسل موجود ہیں اور تبدیل نہیں ہوتے ہیں۔

نقصان یہ ہے کہ اس طرح کے حل کو نافذ کرنا زیادہ مشکل اور ڈیبگ کرنا زیادہ مشکل ہے۔ اور وکٹوریہ میٹرکس نے اس حل کا انتخاب کیا۔ تاریخی طور پر ایسا ہی ہوا۔ یہ حل بھی پچھلے ایک کے مقابلے میں اچھی کارکردگی کا مظاہرہ کرتا ہے۔ کیونکہ اس حل کو اس حقیقت کی وجہ سے لاگو نہیں کیا گیا تھا کہ ہر پارٹیشن میں ٹائم سیریز کے لیے ڈیٹا کو ڈپلیکیٹ کرنا ضروری ہے جو تبدیل نہیں ہوتے، یعنی وقت کے ساتھ ساتھ غائب نہیں ہوتے۔ وکٹوریہ میٹرکس کو بنیادی طور پر ڈسک کی جگہ کی کھپت کے لیے بہتر بنایا گیا تھا، اور پچھلے نفاذ نے ڈسک کی جگہ کی کھپت کو بدتر بنا دیا تھا۔ لیکن یہ نفاذ ڈسک کی جگہ کی کھپت کو کم سے کم کرنے کے لیے بہتر ہے، اس لیے اس کا انتخاب کیا گیا۔

مجھے اس سے لڑنا پڑا۔ جدوجہد یہ تھی کہ اس عمل میں آپ کو ابھی بھی بہت بڑی تعداد کا انتخاب کرنا ہوگا۔ timeseries_ids ڈیٹا کے لیے اس وقت جب الٹا انڈیکس وقت تقسیم ہوتا ہے۔

ہم نے اس مسئلے کو کیسے حل کیا؟ ہم نے اسے اصل طریقے سے حل کیا - ایک شناخت کنندہ کے بجائے ہر الٹی انڈیکس اندراج میں کئی بار سیریز کے شناخت کنندگان کو ذخیرہ کرکے۔ یعنی ہمارے پاس ایک چابی ہے۔ label=value، جو ہر وقت کی سیریز میں ہوتا ہے۔ اور اب ہم کئی کو بچاتے ہیں۔ timeseries_ids ایک اندراج میں.

یہاں ایک مثال ہے۔ پہلے ہمارے پاس N اندراجات تھے، لیکن اب ہمارے پاس ایک اندراج ہے جس کا سابقہ ​​تمام باقیوں جیسا ہے۔ پچھلی اندراج کے لیے، قدر میں ہمہ وقتی سیریز کے id شامل ہیں۔

اس سے اس طرح کے الٹے انڈیکس کی اسکیننگ کی رفتار کو 10 گنا تک بڑھانا ممکن ہوا۔ اور اس نے ہمیں کیشے کے لیے میموری کی کھپت کو کم کرنے کی اجازت دی، کیونکہ اب ہم سٹرنگ کو اسٹور کرتے ہیں۔ label=value صرف ایک بار کیشے میں ایک ساتھ N بار۔ اور یہ لائن بڑی ہو سکتی ہے اگر آپ اپنے ٹیگز اور لیبلز میں لمبی لائنیں محفوظ کرتے ہیں، جسے Kubernetes وہاں ہلانا پسند کرتا ہے۔

الٹی انڈیکس پر تلاش کو تیز کرنے کا دوسرا آپشن شارڈنگ ہے۔ ایک کے بجائے کئی الٹی انڈیکس بنانا اور ان کے درمیان ڈیٹا کو کلید کے ذریعے شیئر کرنا۔ یہ ایک سیٹ ہے۔ key=value بھاپ یعنی، ہمیں کئی آزاد الٹے اشاریہ جات ملتے ہیں، جن سے ہم متعدد پروسیسرز پر متوازی طور پر استفسار کر سکتے ہیں۔ پچھلے نفاذ نے صرف سنگل پروسیسر موڈ میں کام کرنے کی اجازت دی تھی، یعنی صرف ایک کور پر ڈیٹا اسکین کرنا۔ یہ حل آپ کو ایک ساتھ کئی کور پر ڈیٹا اسکین کرنے کی اجازت دیتا ہے، جیسا کہ کلک ہاؤس کرنا پسند کرتا ہے۔ یہ وہی ہے جسے ہم لاگو کرنے کا ارادہ رکھتے ہیں.

اب آتے ہیں اپنی بھیڑوں کی طرف - انٹرسیکشن فنکشن کی طرف timeseries_ids. آئیے غور کریں کہ وہاں کیا نفاذ ہو سکتا ہے۔ یہ فنکشن آپ کو تلاش کرنے کی اجازت دیتا ہے۔ timeseries_ids دیئے گئے سیٹ کے لیے label=value.

پہلا آپشن ایک سادہ عمل ہے۔ دو نیسٹڈ لوپس۔ یہاں ہمیں فنکشن ان پٹ ملتا ہے۔ intersectInts دو ٹکڑے - a и b. آؤٹ پٹ پر، یہ ہمارے پاس ان سلائسوں کا چوراہا واپس آنا چاہیے۔

ایک بولی نفاذ اس طرح لگتا ہے۔ ہم سلائس سے تمام اقدار پر اعادہ کرتے ہیں۔ a، اس لوپ کے اندر ہم سلائس کی تمام اقدار سے گزرتے ہیں۔ b. اور ہم ان کا موازنہ کرتے ہیں۔ اگر وہ مماثل ہیں، تو ہمیں ایک چوراہا مل گیا ہے۔ اور اس میں محفوظ کریں۔ result.

نقصانات کیا ہیں؟ چوکور پیچیدگی اس کی بنیادی خرابی ہے۔ مثال کے طور پر، اگر آپ کے طول و عرض سلائس ہیں۔ a и b ایک وقت میں ایک ملین، پھر یہ فنکشن آپ کو کبھی جواب نہیں دے گا۔ کیونکہ اسے ایک ٹریلین تکرار کرنے کی ضرورت ہوگی، جو کہ جدید کمپیوٹرز کے لیے بھی بہت زیادہ ہے۔

دوسرا نفاذ نقشے پر مبنی ہے۔ ہم نقشہ بناتے ہیں۔ ہم اس نقشے میں سلائس سے تمام اقدار ڈالتے ہیں۔ a. پھر ہم ایک الگ لوپ میں سلائس سے گزرتے ہیں۔ b. اور ہم چیک کرتے ہیں کہ آیا یہ قدر سلائس سے ہے۔ b نقشے میں اگر یہ موجود ہے، تو اسے نتیجہ میں شامل کریں۔

فوائد کیا ہیں؟ فائدہ یہ ہے کہ صرف لکیری پیچیدگی ہے۔ یعنی، فنکشن بڑے سلائسز کے لیے بہت تیزی سے کام کرے گا۔ ایک ملین سائز کے ٹکڑے کے لیے، یہ فنکشن پچھلے فنکشن کے ٹریلین تکرار کے برخلاف، 2 ملین تکرار میں کام کرے گا۔

منفی پہلو یہ ہے کہ اس نقشے کو بنانے کے لیے اس فنکشن کو زیادہ میموری کی ضرورت ہوتی ہے۔

دوسری خرابی ہیشنگ کے لیے بڑا اوور ہیڈ ہے۔ یہ کمی بہت واضح نہیں ہے۔ اور ہمارے لیے یہ زیادہ واضح بھی نہیں تھا، اس لیے سب سے پہلے وکٹوریہ میٹرکس میں چوراہے کا نفاذ نقشے کے ذریعے ہوتا تھا۔ لیکن پھر پروفائلنگ نے ظاہر کیا کہ مرکزی پروسیسر کا وقت نقشہ پر لکھنے اور اس نقشے میں کسی قدر کی موجودگی کی جانچ کرنے میں صرف ہوتا ہے۔

ان جگہوں پر سی پی یو کا وقت کیوں ضائع ہوتا ہے؟ کیونکہ گو ان لائنوں پر ہیشنگ آپریشن کرتا ہے۔ یعنی، یہ کلید کے ہیش کا حساب لگاتا ہے تاکہ HashMap میں دیئے گئے انڈیکس پر اس تک رسائی حاصل کر سکے۔ ہیش کیلکولیشن کا عمل دسیوں نینو سیکنڈز میں مکمل ہوتا ہے۔ وکٹوریہ میٹرکس کے لیے یہ سست ہے۔

میں نے اس کیس کے لیے خاص طور پر آپٹمائزڈ بٹ سیٹ کو نافذ کرنے کا فیصلہ کیا۔ دو ٹکڑوں کا چوراہے اب ایسا لگتا ہے۔ یہاں ہم ایک بٹ سیٹ بناتے ہیں۔ ہم اس میں پہلے سلائس سے عناصر شامل کرتے ہیں۔ پھر ہم دوسرے سلائس میں ان عناصر کی موجودگی کو چیک کرتے ہیں۔ اور انہیں نتیجہ میں شامل کریں۔ یعنی یہ پچھلی مثال سے تقریباً مختلف نہیں ہے۔ یہاں صرف ایک چیز یہ ہے کہ ہم نے اپنی مرضی کے مطابق افعال کے ساتھ نقشہ تک رسائی کو تبدیل کر دیا add и has.

پہلی نظر میں ایسا لگتا ہے کہ یہ آہستہ کام کرنا چاہیے، اگر پہلے وہاں معیاری نقشہ استعمال کیا جاتا تھا، اور پھر کچھ اور فنکشنز کو کال کیا جاتا ہے، لیکن پروفائلنگ سے پتہ چلتا ہے کہ وکٹوریہ میٹرکس کے معاملے میں یہ چیز معیاری نقشے سے 10 گنا زیادہ تیزی سے کام کرتی ہے۔

اس کے علاوہ، یہ نقشہ کے نفاذ کے مقابلے میں بہت کم میموری استعمال کرتا ہے۔ کیونکہ ہم یہاں آٹھ بائٹ ویلیو کے بجائے بٹس اسٹور کر رہے ہیں۔

اس نفاذ کا نقصان یہ ہے کہ یہ اتنا واضح نہیں ہے، معمولی نہیں۔

ایک اور خرابی جو بہت سے لوگوں کو محسوس نہیں ہوسکتی ہے وہ یہ ہے کہ یہ عمل کچھ معاملات میں ٹھیک کام نہیں کرسکتا ہے۔ یعنی، یہ وکٹوریہ میٹرکس ٹائم سیریز کے ids کے انٹرسیکشن کے اس کیس کے لیے، ایک مخصوص کیس کے لیے موزوں ہے۔ اس کا مطلب یہ نہیں ہے کہ یہ تمام معاملات کے لیے موزوں ہے۔ اگر اسے غلط طریقے سے استعمال کیا جاتا ہے، تو ہمیں کارکردگی میں اضافہ نہیں ہوگا، بلکہ میموری کی خرابی اور کارکردگی میں سست روی ہوگی۔

آئیے اس ڈھانچے کے نفاذ پر غور کریں۔ اگر آپ دیکھنا چاہتے ہیں، تو یہ فولڈر میں VictoriaMetrics کے ذرائع میں واقع ہے۔ lib/uint64set. یہ خاص طور پر وکٹوریہ میٹرکس کیس کے لیے موزوں ہے، جہاں timeseries_id ایک 64 بٹ قدر ہے، جہاں پہلے 32 بٹس بنیادی طور پر مستقل ہوتے ہیں اور صرف آخری 32 بٹس تبدیل ہوتے ہیں۔

یہ ڈیٹا ڈھانچہ ڈسک پر محفوظ نہیں ہے، یہ صرف میموری میں کام کرتا ہے۔

یہاں اس کا API ہے۔ یہ بہت پیچیدہ نہیں ہے۔ API کو خاص طور پر VictoriaMetrics کے استعمال کی ایک مخصوص مثال کے مطابق بنایا گیا ہے۔ یعنی یہاں کوئی غیر ضروری افعال نہیں ہیں۔ یہاں وہ فنکشنز ہیں جو واضح طور پر وکٹوریہ میٹرکس کے ذریعہ استعمال ہوتے ہیں۔

فنکشنز ہیں۔ add، جو نئی اقدار کا اضافہ کرتا ہے۔ ایک فنکشن ہے۔ has، جو نئی اقدار کی جانچ کرتا ہے۔ اور ایک فنکشن ہے۔ del، جو اقدار کو ہٹاتا ہے۔ ایک مددگار فنکشن ہے۔ len، جو سیٹ کا سائز لوٹاتا ہے۔ فنکشن clone بہت کلون. اور فنکشن appendto اس سیٹ کو سلائس میں تبدیل کرتا ہے۔ timeseries_ids.

اس ڈیٹا ڈھانچے کا نفاذ ایسا لگتا ہے۔ سیٹ کے دو عناصر ہیں:

• ItemsCount سیٹ میں عناصر کی تعداد کو تیزی سے واپس کرنے کے لیے ایک مددگار فیلڈ ہے۔ اس معاون فیلڈ کے بغیر کرنا ممکن ہوگا، لیکن اسے یہاں شامل کرنا پڑا کیونکہ وکٹوریہ میٹرکس اکثر اپنے الگورتھم میں بٹ سیٹ کی لمبائی کے بارے میں سوال کرتا ہے۔

• دوسرا میدان ہے۔ buckets. یہ ساخت کا ٹکڑا ہے۔ bucket32. ہر ڈھانچہ اسٹور کرتا ہے۔ hi میدان یہ اوپری 32 بٹس ہیں۔ اور دو ٹکڑے - b16his и buckets کی bucket16 ڈھانچے

16 بٹ ڈھانچے کے دوسرے حصے کے اوپری 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 بٹ ویلیو کے لیے ایک ماسک ہے، جو اس بٹ کی موجودگی کو چیک کرنے یا اسے سیٹ کرنے کے لیے استعمال کیا جا سکتا ہے۔ ہم یہ دیکھنے کے لیے چیک کرتے ہیں کہ آیا یہ بٹ سیٹ ہے اور اسے سیٹ کریں، اور موجودگی واپس کریں۔ یہ ہمارا نفاذ ہے، جس نے ہمیں روایتی نقشوں کے مقابلے میں ٹائم سیریز کے ids کو 10 گنا زیادہ کاٹتے ہوئے آپریشن کو تیز کرنے کی اجازت دی۔

اس اصلاح کے علاوہ، VictoriaMetrics کے پاس بہت سی دوسری اصلاحیں ہیں۔ ان میں سے زیادہ تر اصلاح کو ایک وجہ سے شامل کیا گیا تھا، لیکن پروڈکشن میں کوڈ کی پروفائلنگ کے بعد۔

یہ اصلاح کا بنیادی اصول ہے - یہ فرض کرتے ہوئے اصلاح کو شامل نہ کریں کہ یہاں کوئی رکاوٹ ہو گی، کیونکہ ہو سکتا ہے کہ وہاں کوئی رکاوٹ نہ ہو۔ اصلاح عام طور پر کوڈ کے معیار کو گرا دیتی ہے۔ لہذا، یہ صرف پروفائلنگ کے بعد اور ترجیحی طور پر پیداوار میں بہتر بنانے کے قابل ہے، تاکہ یہ حقیقی ڈیٹا ہو۔ اگر کوئی دلچسپی رکھتا ہے، تو آپ VictoriaMetrics کے سورس کوڈ کو دیکھ سکتے ہیں اور وہاں موجود دیگر اصلاحات کو تلاش کر سکتے ہیں۔

میرے پاس بٹ سیٹ کے بارے میں ایک سوال ہے۔ C++ ویکٹر بول کے نفاذ سے بہت ملتا جلتا، آپٹمائزڈ بٹ سیٹ۔ کیا آپ نے وہاں سے عمل درآمد کیا؟

نہیں، وہاں سے نہیں۔ اس بٹ سیٹ کو لاگو کرتے وقت، مجھے ان ids ٹائم سیریز کی ساخت کے علم سے رہنمائی ملی، جو VictoriaMetrics میں استعمال ہوتی ہیں۔ اور ان کی ساخت ایسی ہے کہ اوپری 32 بٹس بنیادی طور پر مستقل ہیں۔ نچلے 32 بٹس تبدیلی کے تابع ہیں۔ تھوڑا سا کم، زیادہ کثرت سے یہ تبدیل ہوسکتا ہے. لہذا، اس عمل کو خاص طور پر اس ڈیٹا ڈھانچے کے لیے بہتر بنایا گیا ہے۔ C++ نفاذ، جہاں تک میں جانتا ہوں، عمومی صورت کے لیے موزوں ہے۔ اگر آپ عام کیس کے لیے بہتر بناتے ہیں، تو اس کا مطلب ہے کہ یہ کسی مخصوص کیس کے لیے سب سے زیادہ موزوں نہیں ہوگا۔

میں آپ کو الیکسی میلوڈ کی رپورٹ دیکھنے کا مشورہ بھی دیتا ہوں۔ تقریباً ایک ماہ قبل، اس نے مخصوص تخصص کے لیے ClickHouse میں اصلاح کے بارے میں بات کی۔ وہ صرف یہ کہتا ہے کہ عام صورت میں، ایک C++ کا نفاذ یا کوئی اور نفاذ ہسپتال میں اوسطاً بہتر کام کرنے کے لیے تیار کیا گیا ہے۔ یہ ہمارے جیسے علم سے متعلق مخصوص نفاذ سے بھی بدتر کارکردگی کا مظاہرہ کر سکتا ہے، جہاں ہم جانتے ہیں کہ ٹاپ 32 بٹس زیادہ تر مستقل ہوتے ہیں۔

میرا دوسرا سوال ہے۔ InfluxDB سے بنیادی فرق کیا ہے؟

بہت سے بنیادی اختلافات ہیں۔ کارکردگی اور میموری کی کھپت کے لحاظ سے، ٹیسٹوں میں InfluxDB ہائی کارڈینیلیٹی ٹائم سیریز کے لیے 10 گنا زیادہ میموری کی کھپت کو ظاہر کرتا ہے، جب آپ کے پاس ان میں سے بہت کچھ ہے، مثال کے طور پر، لاکھوں۔ مثال کے طور پر، VictoriaMetrics 1 GB فی ملین فعال قطار استعمال کرتا ہے، جبکہ InfluxDB 10 GB استعمال کرتا ہے۔ اور یہ ایک بڑا فرق ہے۔

دوسرا بنیادی فرق یہ ہے کہ InfluxDB میں عجیب استفسار کی زبانیں ہیں - Flux اور InfluxQL۔ وہ کے مقابلے میں ٹائم سیریز کے ساتھ کام کرنے کے لئے بہت آسان نہیں ہیں پروم کیو ایل، جو وکٹوریہ میٹرکس کے ذریعہ تعاون یافتہ ہے۔ PromQL Prometheus کی طرف سے ایک سوال کی زبان ہے۔

اور ایک اور فرق یہ ہے کہ InfluxDB میں قدرے عجیب ڈیٹا ماڈل ہے، جہاں ہر لائن ٹیگز کے مختلف سیٹ کے ساتھ کئی فیلڈز کو اسٹور کر سکتی ہے۔ ان لائنوں کو مزید مختلف جدولوں میں تقسیم کیا گیا ہے۔ یہ اضافی پیچیدگیاں اس ڈیٹا بیس کے ساتھ بعد کے کام کو پیچیدہ بناتی ہیں۔ اس کی تائید اور سمجھنا مشکل ہے۔

وکٹوریہ میٹرکس میں سب کچھ بہت آسان ہے۔ وہاں، ہر بار سیریز ایک کلیدی قدر ہوتی ہے۔ قدر پوائنٹس کا ایک سیٹ ہے - (timestamp, value)، اور کلید سیٹ ہے۔ label=value. کھیتوں اور پیمائش کے درمیان کوئی علیحدگی نہیں ہے۔ یہ آپ کو کسی بھی ڈیٹا کو منتخب کرنے اور پھر InfluxDB کے برعکس یکجا کرنے، شامل کرنے، گھٹانے، ضرب کرنے، تقسیم کرنے کی اجازت دیتا ہے جہاں تک میں جانتا ہوں مختلف قطاروں کے درمیان حسابات ابھی تک لاگو نہیں ہوتے ہیں۔ یہاں تک کہ اگر وہ لاگو ہوتے ہیں، یہ مشکل ہے، آپ کو بہت زیادہ کوڈ لکھنا پڑتا ہے.

میرا ایک واضح سوال ہے۔ کیا میں نے صحیح طور پر سمجھا کہ کچھ مسئلہ تھا جس کے بارے میں آپ نے بات کی تھی کہ یہ الٹا انڈیکس میموری میں فٹ نہیں بیٹھتا، اس لیے وہاں تقسیم ہو رہی ہے؟

سب سے پہلے، میں نے معیاری گو میپ پر الٹی انڈیکس کا سادہ عمل دکھایا۔ یہ نفاذ ڈیٹا بیس کے لیے موزوں نہیں ہے کیونکہ یہ الٹا انڈیکس ڈسک میں محفوظ نہیں ہوتا ہے، اور ڈیٹا بیس کو ڈسک میں محفوظ کرنا چاہیے تاکہ یہ ڈیٹا دوبارہ شروع ہونے پر دستیاب رہے۔ اس عمل میں، جب آپ ایپلیکیشن کو دوبارہ شروع کریں گے، تو آپ کا الٹا انڈیکس غائب ہو جائے گا۔ اور آپ تمام ڈیٹا تک رسائی کھو دیں گے کیونکہ آپ اسے تلاش نہیں کر پائیں گے۔

ہیلو! رپورٹ کے لیے شکریہ! میرا نام پاول ہے۔ میں Wildberries سے ہوں میرے پاس آپ کے لیے چند سوالات ہیں۔ سوال ایک۔ کیا آپ کو لگتا ہے کہ اگر آپ نے اپنی ایپلیکیشن کا فن تعمیر کرتے وقت کوئی مختلف اصول منتخب کیا ہوتا اور وقت کے ساتھ ساتھ ڈیٹا کو تقسیم کیا ہوتا، تو شاید آپ تلاش کرتے وقت ڈیٹا کو کاٹ سکتے تھے، صرف اس حقیقت کی بنیاد پر کہ ایک پارٹیشن میں ایک کے لیے ڈیٹا ہوتا ہے۔ وقت کی مدت، یعنی ایک وقت کے وقفے میں اور آپ کو اس حقیقت کے بارے میں فکر کرنے کی ضرورت نہیں ہوگی کہ آپ کے ٹکڑے مختلف طریقے سے بکھرے ہوئے ہیں؟ سوال نمبر 2 - چونکہ آپ بٹ سیٹ اور ہر چیز کے ساتھ اسی طرح کا الگورتھم نافذ کر رہے ہیں، تو شاید آپ نے پروسیسر کی ہدایات کو استعمال کرنے کی کوشش کی؟ شاید آپ نے اس طرح کی اصلاح کی کوشش کی ہے؟

میں فوراً دوسرے کا جواب دوں گا۔ ہم ابھی تک اس مقام تک نہیں پہنچے ہیں۔ لیکن اگر ضروری ہوا تو ہم وہاں پہنچ جائیں گے۔ اور پہلا سوال کیا تھا؟

آپ نے دو منظرناموں پر بات کی۔ اور انہوں نے کہا کہ انہوں نے دوسرے کو زیادہ پیچیدہ نفاذ کے ساتھ منتخب کیا۔ اور انہوں نے پہلے کو ترجیح نہیں دی، جہاں ڈیٹا کو وقت کے ساتھ تقسیم کیا جاتا ہے۔

جی ہاں. پہلی صورت میں، انڈیکس کا کل حجم بڑا ہوگا، کیونکہ ہر پارٹیشن میں ہمیں ان تمام پارٹیشنز کے ذریعے جاری رہنے والی ٹائم سیریز کے لیے ڈپلیکیٹ ڈیٹا کو ذخیرہ کرنا ہوگا۔ اور اگر آپ کی ٹائم سیریز چرن ریٹ کم ہے، یعنی ایک ہی سیریز کو مسلسل استعمال کیا جاتا ہے، تو پہلی صورت میں ہم دوسری صورت کے مقابلے میں ڈسک کی جگہ کی مقدار میں زیادہ کھو دیں گے۔

اور اس طرح - ہاں، وقت کی تقسیم ایک اچھا آپشن ہے۔ پرومیتھیس اسے استعمال کرتا ہے۔ لیکن پرومیتھیس کی ایک اور خرابی ہے۔ ڈیٹا کے ان ٹکڑوں کو ضم کرتے وقت، اسے تمام لیبلز اور ٹائم سیریز کے لیے میموری میٹا کی معلومات رکھنے کی ضرورت ہوتی ہے۔ اس لیے، اگر ڈیٹا کے وہ ٹکڑے جو اس میں ضم ہوتے ہیں وہ بڑے ہوتے ہیں، تو VictoriaMetrics کے برعکس، انضمام کے دوران میموری کی کھپت بہت زیادہ بڑھ جاتی ہے۔ ضم کرتے وقت، VictoriaMetrics میموری کو بالکل استعمال نہیں کرتا؛ ڈیٹا کے ضم شدہ ٹکڑوں کے سائز سے قطع نظر، صرف چند کلو بائٹس استعمال کی جاتی ہیں۔

آپ جو الگورتھم استعمال کر رہے ہیں وہ میموری استعمال کرتا ہے۔ یہ ٹائم سیریز ٹیگز کو نشان زد کرتا ہے جن میں قدر ہوتی ہے۔ اور اس طرح آپ ایک ڈیٹا سرنی میں اور دوسرے میں جوڑی کی موجودگی کی جانچ کرتے ہیں۔ اور آپ سمجھتے ہیں کہ انٹرسیکٹ ہوا ہے یا نہیں۔ عام طور پر، ڈیٹا بیس کرسر اور تکرار کرنے والوں کو لاگو کرتے ہیں جو اپنے موجودہ مواد کو ذخیرہ کرتے ہیں اور ان آپریشنز کی سادہ پیچیدگی کی وجہ سے ترتیب شدہ ڈیٹا کے ذریعے چلتے ہیں۔

ہم ڈیٹا کو عبور کرنے کے لیے کرسر کا استعمال کیوں نہیں کرتے؟

جی ہاں.

ہم ترتیب شدہ قطاروں کو LevelDB یا mergeset میں اسٹور کرتے ہیں۔ ہم کرسر کو حرکت دے سکتے ہیں اور چوراہا تلاش کر سکتے ہیں۔ ہم اسے استعمال کیوں نہیں کرتے؟ کیونکہ یہ سست ہے۔ کیونکہ کرسر کا مطلب ہے کہ آپ کو ہر لائن کے لیے ایک فنکشن کال کرنے کی ضرورت ہے۔ ایک فنکشن کال 5 نینو سیکنڈز ہے۔ اور اگر آپ کے پاس 100 لائنیں ہیں، تو پتہ چلتا ہے کہ ہم صرف فنکشن کو کال کرنے میں آدھا سیکنڈ صرف کرتے ہیں۔

ایسی بات ہے، ہاں۔ اور میرا آخری سوال۔ سوال تھوڑا عجیب لگ سکتا ہے۔ ڈیٹا آنے کے وقت تمام ضروری ایگریگیٹس کو پڑھنا اور مطلوبہ شکل میں محفوظ کرنا کیوں ممکن نہیں؟ VictoriaMetrics، ClickHouse، وغیرہ جیسے کچھ سسٹمز میں بھاری حجم کیوں بچاتے ہیں، اور پھر ان پر کافی وقت صرف کرتے ہیں؟

میں اسے واضح کرنے کے لیے ایک مثال دیتا ہوں۔ آئیے کہتے ہیں کہ ایک چھوٹا کھلونا سپیڈومیٹر کیسے کام کرتا ہے؟ یہ آپ کے سفر کردہ فاصلے کو ریکارڈ کرتا ہے، ہر وقت اسے ایک قدر میں شامل کرتا ہے، اور دوسری بار۔ اور تقسیم کرتا ہے۔ اور اوسط رفتار حاصل کرتا ہے۔ آپ ایک ہی چیز کے بارے میں کر سکتے ہیں۔ پرواز پر تمام ضروری حقائق شامل کریں۔

ٹھیک ہے، میں سوال سمجھتا ہوں۔ آپ کی مثال اپنی جگہ ہے۔ اگر آپ جانتے ہیں کہ آپ کو کن مجموعوں کی ضرورت ہے، تو یہ بہترین نفاذ ہے۔ لیکن مسئلہ یہ ہے کہ لوگ ان میٹرکس، کچھ ڈیٹا کو ClickHouse میں محفوظ کرتے ہیں اور وہ ابھی تک نہیں جانتے کہ وہ مستقبل میں انہیں کیسے جمع اور فلٹر کریں گے، اس لیے انہیں تمام خام ڈیٹا کو محفوظ کرنا ہوگا۔ لیکن اگر آپ جانتے ہیں کہ آپ کو اوسط میں کسی چیز کا حساب لگانے کی ضرورت ہے، تو کیوں نہ وہاں خام قدروں کا ایک گچھا ذخیرہ کرنے کے بجائے اس کا حساب لگائیں؟ لیکن یہ صرف اس صورت میں ہے جب آپ جانتے ہوں کہ آپ کو کیا ضرورت ہے۔

ویسے، ٹائم سیریز کو ذخیرہ کرنے کے لیے ڈیٹا بیس مجموعی کی گنتی کی حمایت کرتے ہیں۔ مثال کے طور پر، Prometheus حمایت کرتا ہے ریکارڈنگ کے قوانین. یعنی، یہ کیا جا سکتا ہے اگر آپ جانتے ہیں کہ آپ کو کن یونٹس کی ضرورت ہوگی۔ VictoriaMetrics کے پاس ابھی تک یہ نہیں ہے، لیکن یہ عام طور پر Prometheus سے پہلے ہوتا ہے، جس میں یہ ری کوڈنگ کے قواعد میں کیا جا سکتا ہے۔

مثال کے طور پر، میری پچھلی ملازمت میں مجھے آخری گھنٹے کے دوران سلائیڈنگ ونڈو میں ہونے والے واقعات کی تعداد شمار کرنے کی ضرورت تھی۔ مسئلہ یہ ہے کہ مجھے گو میں اپنی مرضی کے مطابق عمل درآمد کرنا پڑا، یعنی اس چیز کو گننے کے لیے ایک سروس۔ یہ خدمت بالآخر غیر معمولی تھی، کیونکہ اس کا حساب لگانا مشکل ہے۔ اگر آپ کو مقررہ وقت کے وقفوں پر کچھ مجموعوں کو شمار کرنے کی ضرورت ہو تو عمل درآمد آسان ہو سکتا ہے۔ اگر آپ واقعات کو سلائیڈنگ ونڈو میں شمار کرنا چاہتے ہیں، تو یہ اتنا آسان نہیں جتنا لگتا ہے۔ میرے خیال میں یہ ابھی تک کلک ہاؤس یا ٹائم سیریز ڈیٹا بیس میں لاگو نہیں ہوا ہے، کیونکہ اس پر عمل درآمد مشکل ہے۔

اور ایک سوال۔ ہم صرف اوسط کے بارے میں بات کر رہے تھے، اور مجھے یاد آیا کہ ایک بار کاربن بیک اینڈ کے ساتھ گریفائٹ جیسی چیز تھی۔ اور وہ جانتا تھا کہ پرانے ڈیٹا کو کیسے پتلا کرنا ہے، یعنی ایک پوائنٹ فی منٹ، ایک پوائنٹ فی گھنٹہ، وغیرہ چھوڑ دیں۔ اصولی طور پر، یہ کافی آسان ہے اگر ہمیں ایک ماہ کے لیے، نسبتاً بولتے ہوئے، خام ڈیٹا کی ضرورت ہو، اور باقی سب کچھ کر سکتے ہیں۔ پتلا کیا جائے لیکن Prometheus اور VictoriaMetrics اس فعالیت کی حمایت نہیں کرتے ہیں۔ کیا اس کی حمایت کرنے کا منصوبہ بنایا گیا ہے؟ اگر نہیں تو کیوں نہیں؟

سوال کے لیے شکریہ۔ ہمارے صارفین وقتا فوقتا یہ سوال پوچھتے ہیں۔ وہ پوچھتے ہیں کہ ہم ڈاؤن سیمپلنگ کے لیے سپورٹ کب شامل کریں گے۔ یہاں کئی مسائل ہیں۔ سب سے پہلے، ہر صارف سمجھتا ہے downsampling کچھ مختلف: کوئی مقررہ وقفہ پر کوئی صوابدیدی نقطہ حاصل کرنا چاہتا ہے، کوئی زیادہ سے زیادہ، کم از کم، اوسط اقدار چاہتا ہے۔ اگر بہت سے سسٹمز آپ کے ڈیٹا بیس میں ڈیٹا لکھتے ہیں، تو آپ ان سب کو اکٹھا نہیں کر سکتے۔ یہ ہو سکتا ہے کہ ہر نظام کو مختلف پتلا کرنے کی ضرورت ہو۔ اور اس پر عمل درآمد مشکل ہے۔

اور دوسری چیز یہ ہے کہ VictoriaMetrics، ClickHouse کی طرح، خام ڈیٹا کی بڑی مقدار کے ساتھ کام کرنے کے لیے موزوں ہے، لہذا اگر آپ کے سسٹم میں بہت سے کور موجود ہیں تو یہ ایک سیکنڈ سے بھی کم وقت میں ایک ارب لائنوں کو چلا سکتا ہے۔ وکٹوریہ میٹرکس میں سکیننگ ٹائم سیریز پوائنٹس - 50 پوائنٹس فی سیکنڈ فی کور۔ اور یہ کارکردگی موجودہ کوروں تک پیمانہ ہے۔ یعنی، اگر آپ کے پاس 000 کور ہیں، مثال کے طور پر، آپ فی سیکنڈ ایک ارب پوائنٹس اسکین کریں گے۔ اور VictoriaMetrics اور ClickHouse کی یہ خاصیت ڈاؤن سملنگ کی ضرورت کو کم کرتی ہے۔

ایک اور خصوصیت یہ ہے کہ VictoriaMetrics اس ڈیٹا کو مؤثر طریقے سے کمپریس کرتا ہے۔ پیداوار میں اوسط کمپریشن 0,4 سے 0,8 بائٹس فی پوائنٹ ہے۔ ہر پوائنٹ ٹائم اسٹیمپ + ویلیو ہے۔ اور اسے اوسطاً ایک بائٹ سے کم میں کمپریس کیا جاتا ہے۔

سرجی میرا ایک سوال ہے. کم از کم ریکارڈنگ ٹائم کوانٹم کیا ہے؟

ایک ملی سیکنڈ۔ ہم نے حال ہی میں دیگر ٹائم سیریز ڈیٹا بیس ڈویلپرز کے ساتھ بات چیت کی ہے۔ ان کا کم از کم ٹائم سلائس ایک سیکنڈ ہے۔ اور گریفائٹ میں، مثال کے طور پر، یہ بھی ایک سیکنڈ ہے۔ OpenTSDB میں یہ بھی ایک سیکنڈ ہے۔ InfluxDB میں نینو سیکنڈ کی درستگی ہے۔ وکٹوریہ میٹرکس میں یہ ایک ملی سیکنڈ ہے، کیونکہ پرومیتھیس میں یہ ایک ملی سیکنڈ ہے۔ اور VictoriaMetrics کو اصل میں Prometheus کے لیے ریموٹ اسٹوریج کے طور پر تیار کیا گیا تھا۔ لیکن اب یہ دوسرے سسٹمز سے ڈیٹا محفوظ کر سکتا ہے۔

جس شخص سے میں نے بات کی وہ کہتا ہے کہ ان کے پاس دوسری سے دوسری درستگی ہے - یہ ان کے لیے کافی ہے کیونکہ یہ ڈیٹا کی قسم پر منحصر ہے جو ٹائم سیریز ڈیٹا بیس میں محفوظ کیا جا رہا ہے۔ اگر یہ DevOps ڈیٹا یا انفراسٹرکچر سے ڈیٹا ہے، جہاں آپ اسے 30 سیکنڈ، فی منٹ کے وقفوں سے اکٹھا کرتے ہیں، تو دوسری درستگی کافی ہے، آپ کو کسی چیز سے کم کی ضرورت نہیں ہے۔ اور اگر آپ یہ ڈیٹا ہائی فریکوئنسی ٹریڈنگ سسٹم سے جمع کرتے ہیں، تو آپ کو نینو سیکنڈ کی درستگی کی ضرورت ہے۔

VictoriaMetrics میں ملی سیکنڈ کی درستگی DevOps کیس کے لیے بھی موزوں ہے، اور زیادہ تر معاملات کے لیے موزوں ہو سکتی ہے جن کا میں نے رپورٹ کے آغاز میں ذکر کیا ہے۔ واحد چیز جس کے لیے یہ مناسب نہیں ہو سکتا ہے وہ ہے ہائی فریکوئنسی ٹریڈنگ سسٹم۔

شکریہ! اور ایک اور سوال۔ PromQL میں مطابقت کیا ہے؟

مکمل پیچھے کی طرف مطابقت۔ VictoriaMetrics مکمل طور پر PromQL کی حمایت کرتا ہے۔ اس کے علاوہ، یہ PromQL میں اضافی جدید فعالیت شامل کرتا ہے، جسے کہا جاتا ہے۔ میٹرکس کیو ایل. اس توسیعی فعالیت کے بارے میں یوٹیوب پر بات ہو رہی ہے۔ میں نے سینٹ پیٹرزبرگ میں موسم بہار میں مانیٹرنگ میٹ اپ میں بات کی۔

ٹیلیگرام چینل وکٹوریہ میٹرکس.

سروے میں صرف رجسٹرڈ صارفین ہی حصہ لے سکتے ہیں۔ سائن ان، برائے مہربانی.

Prometheus کے لیے آپ کے طویل مدتی اسٹوریج کے طور پر آپ کو وکٹوریہ میٹرکس پر جانے سے کیا روک رہا ہے؟ (کمنٹس میں لکھیں، میں اسے پول میں شامل کروں گا))

• 71,4٪میں Prometheus5 استعمال نہیں کرتا

• 28,6٪VictoriaMetrics2 کے بارے میں نہیں جانتے تھے۔

7 صارفین نے ووٹ دیا۔ 12 صارفین غیر حاضر رہے۔

ماخذ: www.habr.com