ہم دیکھیں گے کہ Zabbix بیک اینڈ کے طور پر TimescaleDB ڈیٹا بیس کے ساتھ کیسے کام کرتا ہے۔ ہم آپ کو دکھائیں گے کہ کس طرح شروع سے آغاز کیا جائے اور PostgreSQL سے کیسے منتقل کیا جائے۔ ہم دونوں کنفیگریشنز کے تقابلی کارکردگی کے ٹیسٹ بھی فراہم کریں گے۔
ہائی لوڈ++ سائبیریا 2019۔ ٹامسک ہال۔ 24 جون، 16:00۔ مقالہ جات اور . اگلی HighLoad++ کانفرنس 6 اور 7 اپریل 2020 کو سینٹ پیٹرزبرگ میں منعقد ہوگی۔ تفصیلات اور ٹکٹ .
آندرے گوشچن (اس کے بعد - AG): - میں ایک ZABBIX ٹیکنیکل سپورٹ انجینئر ہوں (اس کے بعد "Zabbix" کہا جاتا ہے)، ایک ٹرینر۔ میں 6 سال سے زیادہ عرصے سے تکنیکی معاونت میں کام کر رہا ہوں اور مجھے کارکردگی کا براہ راست تجربہ ہے۔ آج میں اس کارکردگی کے بارے میں بات کروں گا جو TimescaleDB باقاعدہ PostgreSQL 10 کے مقابلے میں فراہم کر سکتا ہے۔ اس کے علاوہ، کچھ تعارفی حصہ کہ یہ عام طور پر کیسے کام کرتا ہے۔
اعلی پیداواری چیلنجز: ڈیٹا اکٹھا کرنے سے ڈیٹا صاف کرنے تک
شروع کرنے کے لیے، کارکردگی کے کچھ چیلنجز ہیں جن کا ہر مانیٹرنگ سسٹم کا سامنا ہے۔ پہلا پیداواری چیلنج ڈیٹا اکٹھا کرنا اور اس پر تیزی سے کارروائی کرنا ہے۔
ایک اچھے مانیٹرنگ سسٹم کو چاہیے کہ وہ تمام ڈیٹا کو جلدی، بروقت وصول کرے، اسے ٹرگر ایکسپریشنز کے مطابق پروسیس کرے، یعنی اسے کچھ معیاروں کے مطابق پروسیس کرے (یہ مختلف سسٹمز میں مختلف ہے) اور اسے ڈیٹا بیس میں محفوظ کرنا چاہیے تاکہ اس ڈیٹا کو استعمال میں لایا جا سکے۔ مستقبل.
کارکردگی کا دوسرا چیلنج تاریخ کا ذخیرہ ہے۔ ڈیٹا بیس میں اکثر اسٹور کریں اور ان میٹرکس تک فوری اور آسان رسائی حاصل کریں جو وقت کے ساتھ جمع کیے گئے تھے۔ سب سے اہم بات یہ ہے کہ یہ ڈیٹا حاصل کرنے کے لیے آسان ہے، اسے رپورٹس، گرافس، ٹرگرز، کچھ حد کی قدروں میں، الرٹس وغیرہ کے لیے استعمال کرنا ہے۔
کارکردگی کا تیسرا چیلنج ہسٹری کلیئرنگ ہے، یعنی، جب آپ اس مقام پر پہنچ جاتے ہیں جہاں آپ کو 5 سال (یہاں تک کہ مہینوں یا دو ماہ) سے زیادہ جمع کیے گئے کسی بھی تفصیلی میٹرکس کو ذخیرہ کرنے کی ضرورت نہیں ہوتی ہے۔ کچھ نیٹ ورک نوڈس کو حذف کر دیا گیا تھا، یا کچھ میزبان، میٹرکس کی مزید ضرورت نہیں ہے کیونکہ وہ پہلے سے پرانے ہو چکے ہیں اور اب جمع نہیں ہوتے۔ اس سب کو صاف کرنے کی ضرورت ہے تاکہ آپ کا ڈیٹا بیس بہت بڑا نہ ہو۔ عام طور پر، تاریخ کو صاف کرنا اکثر اسٹوریج کے لیے ایک سنگین امتحان ہوتا ہے - اس کا اکثر کارکردگی پر بہت گہرا اثر پڑتا ہے۔
کیشنگ کے مسائل کو کیسے حل کریں؟
میں اب خاص طور پر زبکس کے بارے میں بات کروں گا۔ Zabbix میں، پہلی اور دوسری کالیں کیشنگ کے ذریعے حل کی جاتی ہیں۔
ڈیٹا اکٹھا کرنا اور پروسیسنگ - ہم اس تمام ڈیٹا کو ذخیرہ کرنے کے لیے RAM کا استعمال کرتے ہیں۔ ان اعداد و شمار پر اب مزید تفصیل سے بات کی جائے گی۔
اس کے علاوہ ڈیٹا بیس کی طرف اہم انتخاب کے لیے کچھ کیشنگ ہے - گرافس اور دیگر چیزوں کے لیے۔
Zabbix سرور کی طرف ہی کیشنگ: ہمارے پاس ConfigurationCache، ValueCache، HistoryCache، TrendsCache ہے۔ یہ کیا ہے؟
کنفیگریشن کیچ مرکزی کیش ہے جس میں ہم میٹرکس، میزبان، ڈیٹا آئٹمز، ٹرگرز کو اسٹور کرتے ہیں۔ ہر وہ چیز جس کی آپ کو پری پروسیسنگ پر کارروائی کرنے کی ضرورت ہے، ڈیٹا اکٹھا کرنا، کس میزبان سے جمع کرنا ہے، کس فریکوئنسی کے ساتھ۔ یہ سب کچھ ConfigurationCache میں محفوظ ہے تاکہ ڈیٹا بیس میں جا کر غیر ضروری سوالات پیدا نہ ہوں۔ سرور شروع ہونے کے بعد، ہم اس کیش کو اپ ڈیٹ کرتے ہیں (اسے بنائیں) اور اسے وقتاً فوقتاً اپ ڈیٹ کرتے ہیں (کنفیگریشن سیٹنگز پر منحصر ہے)۔
Zabbix میں کیشنگ۔ ڈیٹا اکٹھا کرنا
یہاں خاکہ کافی بڑا ہے:
اسکیم میں اہم یہ جمع کرنے والے ہیں:
یہ خود اسمبلی کے عمل ہیں، مختلف "پولرز" جو مختلف قسم کی اسمبلیوں کے لیے ذمہ دار ہیں۔ وہ icmp، ipmi، اور مختلف پروٹوکولز کے ذریعے ڈیٹا اکٹھا کرتے ہیں اور اسے پری پروسیسنگ میں منتقل کرتے ہیں۔
پری پروسیسنگ ہسٹری کیچ
اس کے علاوہ، اگر ہمارے پاس ڈیٹا کے عناصر (وہ لوگ جو Zabbix سے واقف ہیں جانتے ہیں) کا حساب لگایا ہے، یعنی کیلکولیٹڈ، ایگریگیشن ڈیٹا عناصر، تو ہم انہیں براہ راست ValueCache سے لیتے ہیں۔ میں آپ کو بعد میں بتاؤں گا کہ یہ کیسے بھرا ہے۔ یہ تمام جمع کرنے والے اپنی ملازمتیں حاصل کرنے کے لیے ConfigurationCache کا استعمال کرتے ہیں اور پھر انہیں پری پروسیسنگ میں منتقل کرتے ہیں۔
پری پروسیسنگ کنفیگریشن کیچ کو پری پروسیسنگ کے مراحل حاصل کرنے کے لیے بھی استعمال کرتی ہے اور اس ڈیٹا کو مختلف طریقوں سے پروسیس کرتی ہے۔ ورژن 4.2 سے شروع کرتے ہوئے، ہم نے اسے ایک پراکسی میں منتقل کر دیا ہے۔ یہ بہت آسان ہے، کیونکہ پری پروسیسنگ خود ایک مشکل عمل ہے۔ اور اگر آپ کے پاس ایک بہت بڑا Zabbix ہے، جس میں ڈیٹا کے عناصر کی ایک بڑی تعداد اور زیادہ جمع کرنے کی فریکوئنسی ہے، تو یہ کام کو بہت آسان بنا دیتا ہے۔
اس کے مطابق، جب ہم نے اس ڈیٹا کو پری پروسیسنگ کا استعمال کرتے ہوئے کسی طرح سے پروسیس کیا ہے، ہم اسے مزید پروسیسنگ کے لیے HistoryCache میں محفوظ کر لیتے ہیں۔ یہ ڈیٹا اکٹھا کرنے کا اختتام کرتا ہے۔ ہم مرکزی عمل کی طرف بڑھتے ہیں۔
ہسٹری سنسر کا کام
Zabbix میں اہم عمل (چونکہ یہ ایک یک سنگی فن تعمیر ہے) ہسٹری سنسر ہے۔ یہ وہ اہم عمل ہے جو خاص طور پر ہر ڈیٹا عنصر کی ایٹم پروسیسنگ سے متعلق ہے، یعنی ہر قدر:
- قیمت آتی ہے (یہ اسے HistoryCache سے لیتا ہے)؛
- کنفیگریشن سنسر میں چیک کرتا ہے: کیا حساب کے لیے کوئی محرکات ہیں - ان کا حساب لگاتا ہے؛
اگر وہاں ہے تو - واقعات کو تخلیق کرتا ہے، ایک انتباہ پیدا کرنے کے لیے اضافہ کرتا ہے، اگر ترتیب کے مطابق ضروری ہو؛ - ریکارڈز بعد میں پروسیسنگ کے لیے محرکات، جمع؛ اگر آپ آخری گھنٹے وغیرہ کو جمع کرتے ہیں، تو یہ قدر ValueCache کے ذریعے یاد رکھی جاتی ہے تاکہ ہسٹری ٹیبل پر نہ جا سکے۔ اس طرح، ValueCache ضروری ڈیٹا سے بھرا ہوا ہے جو کہ محرکات، حسابی عناصر وغیرہ کا حساب لگانے کے لیے ضروری ہے۔
- پھر ہسٹری سنسر تمام ڈیٹا کو ڈیٹا بیس میں لکھتا ہے۔
- ڈیٹا بیس انہیں ڈسک پر لکھتا ہے - یہ وہ جگہ ہے جہاں پروسیسنگ کا عمل ختم ہوتا ہے۔
ڈیٹا بیس۔ کیشنگ
ڈیٹا بیس کی طرف، جب آپ واقعات پر گرافس یا کچھ رپورٹس دیکھنا چاہتے ہیں، تو مختلف کیچز ہوتے ہیں۔ لیکن اس رپورٹ میں میں ان کے بارے میں بات نہیں کروں گا۔
MySQL کے لیے Innodb_buffer_pool ہے، اور مختلف کیشز کا ایک گروپ ہے جسے کنفیگر بھی کیا جا سکتا ہے۔
لیکن یہ اہم ہیں:
- مشترکہ_بفرز؛
- موثر_کیشے_سائز؛
- مشترکہ_پول
تمام ڈیٹا بیسز کے لیے، میں نے کہا کہ کچھ مخصوص کیچز ہیں جو آپ کو RAM میں ڈیٹا کو ذخیرہ کرنے کی اجازت دیتے ہیں جو اکثر سوالات کے لیے درکار ہوتا ہے۔ اس کے لیے ان کی اپنی ٹیکنالوجیز ہیں۔
ڈیٹا بیس کی کارکردگی کے بارے میں
اسی مناسبت سے، ایک مسابقتی ماحول ہے، یعنی Zabbix سرور ڈیٹا اکٹھا کرتا ہے اور اسے ریکارڈ کرتا ہے۔ دوبارہ شروع ہونے پر، یہ ValueCache وغیرہ کو بھرنے کے لیے تاریخ سے بھی پڑھتا ہے۔ یہاں آپ کے پاس اسکرپٹ اور رپورٹس ہوسکتی ہیں جو Zabbix API کا استعمال کرتی ہیں، جو ویب انٹرفیس پر بنایا گیا ہے۔ Zabbix API ڈیٹابیس میں داخل ہوتا ہے اور گرافس، رپورٹس، یا واقعات کی کسی قسم کی فہرست، حالیہ مسائل حاصل کرنے کے لیے ضروری ڈیٹا حاصل کرتا ہے۔
اس کے علاوہ ایک بہت مقبول تصوراتی حل Grafana ہے، جسے ہمارے صارفین استعمال کرتے ہیں۔ Zabbix API اور ڈیٹا بیس کے ذریعے براہ راست لاگ ان کرنے کے قابل۔ یہ ڈیٹا حاصل کرنے کے لیے ایک خاص مسابقت بھی پیدا کرتا ہے: نتائج اور جانچ کی تیزی سے فراہمی کے لیے ڈیٹا بیس کی ایک بہتر، بہتر ٹیوننگ کی ضرورت ہے۔
تاریخ کو صاف کرنا۔ Zabbix کے پاس ہاؤس کیپر ہے۔
تیسری کال جو زیبکس میں استعمال ہوتی ہے وہ ہاؤس کیپر کا استعمال کرتے ہوئے تاریخ کو صاف کر رہی ہے۔ ہاؤس کیپر تمام ترتیبات کی پیروی کرتا ہے، یعنی ہمارے ڈیٹا کے عناصر بتاتے ہیں کہ کتنی دیر تک ذخیرہ کرنا ہے (دنوں میں)، رجحانات کو کتنی دیر تک ذخیرہ کرنا ہے، اور تبدیلیوں کی حرکیات۔
میں نے TrendCache کے بارے میں بات نہیں کی، جس کا ہم فلائی پر حساب لگاتے ہیں: ڈیٹا آتا ہے، ہم اسے ایک گھنٹے کے لیے جمع کرتے ہیں (زیادہ تر یہ آخری گھنٹے کے نمبر ہوتے ہیں)، رقم اوسط/کم سے کم ہے اور ہم اسے ایک گھنٹے میں ایک بار ریکارڈ کرتے ہیں۔ تبدیلیوں کی حرکیات کا جدول ("رجحان")۔ "ہاؤس کیپر" ڈیٹا بیس سے ڈیٹا کو باقاعدہ سلیکٹس کا استعمال کرتے ہوئے شروع اور حذف کرتا ہے، جو ہمیشہ موثر نہیں ہوتا ہے۔
یہ کیسے سمجھیں کہ یہ غیر موثر ہے؟ آپ اندرونی عمل کی کارکردگی کے گراف پر درج ذیل تصویر دیکھ سکتے ہیں:
آپ کا ہسٹری سنسر مسلسل مصروف رہتا ہے (سرخ گراف)۔ اور "سرخ" گراف جو اوپر جاتا ہے۔ یہ ایک "ہاؤس کیپر" ہے جو شروع ہوتا ہے اور ڈیٹا بیس کے ان تمام قطاروں کو حذف کرنے کا انتظار کرتا ہے جن کی اس نے وضاحت کی ہے۔
آئیے کچھ آئٹم آئی ڈی لیتے ہیں: آپ کو آخری 5 ہزار کو حذف کرنے کی ضرورت ہے۔ یقینا، اشاریہ جات کے ذریعہ۔ لیکن عام طور پر ڈیٹاسیٹ کافی بڑا ہوتا ہے - ڈیٹا بیس اب بھی اسے ڈسک سے پڑھتا ہے اور اسے کیشے میں رکھتا ہے، اور یہ ڈیٹا بیس کے لیے بہت مہنگا آپریشن ہے۔ اس کے سائز پر منحصر ہے، یہ کارکردگی کے بعض مسائل کا باعث بن سکتا ہے۔
آپ ایک آسان طریقے سے ہاؤس کیپر کو غیر فعال کر سکتے ہیں - ہمارے پاس ایک واقف ویب انٹرفیس ہے۔ ایڈمنسٹریشن جنرل میں سیٹنگز ("ہاؤس کیپر" کے لیے سیٹنگز) ہم اندرونی تاریخ اور رجحانات کے لیے اندرونی ہاؤس کیپنگ کو غیر فعال کر دیتے ہیں۔ اس کے مطابق، ہاؤس کیپر اب اس پر قابو نہیں رکھتا:
آپ آگے کیا کر سکتے ہیں؟ آپ نے اسے آف کر دیا، آپ کے گراف برابر ہو گئے ہیں... اس معاملے میں مزید کیا مسائل پیدا ہو سکتے ہیں؟ کیا مدد کر سکتا ہے؟
تقسیم (حصہ بندی)
عام طور پر یہ ہر متعلقہ ڈیٹا بیس پر مختلف طریقے سے ترتیب دیا جاتا ہے جسے میں نے درج کیا ہے۔ MySQL کی اپنی ٹیکنالوجی ہے۔ لیکن جب PostgreSQL 10 اور MySQL کی بات آتی ہے تو مجموعی طور پر وہ بہت ملتے جلتے ہیں۔ بلاشبہ، اس میں بہت سارے اندرونی اختلافات ہیں کہ یہ سب کیسے لاگو ہوتا ہے اور یہ سب کارکردگی کو کیسے متاثر کرتا ہے۔ لیکن عام طور پر، ایک نئی تقسیم کی تخلیق بھی اکثر بعض مسائل کا باعث بنتی ہے۔
آپ کے سیٹ اپ پر منحصر ہے (آپ ایک دن میں کتنا ڈیٹا بناتے ہیں)، وہ عام طور پر کم از کم سیٹ کرتے ہیں - یہ 1 دن / بیچ ہے، اور "ٹرینڈز" کے لیے، تبدیلیوں کی حرکیات - 1 مہینہ / نیا بیچ۔ اگر آپ کے پاس بہت بڑا سیٹ اپ ہے تو یہ تبدیل ہو سکتا ہے۔
آئیے سیٹ اپ کے سائز کے بارے میں فوراً کہتے ہیں: فی سیکنڈ 5 ہزار نئی ویلیوز (نام نہاد این وی پی ایس) - اسے ایک چھوٹا "سیٹ اپ" سمجھا جائے گا۔ اوسط - 5 سے 25 ہزار اقدار فی سیکنڈ تک۔ جو کچھ اوپر ہے وہ پہلے سے ہی بڑی اور بہت بڑی تنصیبات ہیں جن کے لیے ڈیٹا بیس کی بہت محتاط ترتیب کی ضرورت ہوتی ہے۔
بہت بڑی تنصیبات پر، ہو سکتا ہے کہ 1 دن بہترین نہ ہو۔ میں نے ذاتی طور پر MySQL پر 40 گیگا بائٹس فی دن پارٹیشنز دیکھے ہیں (اور اس سے بھی زیادہ ہو سکتے ہیں)۔ یہ ڈیٹا کی ایک بہت بڑی مقدار ہے، جو کچھ مسائل کا باعث بن سکتی ہے۔ اسے کم کرنے کی ضرورت ہے۔
آپ کو تقسیم کی ضرورت کیوں ہے؟
پارٹیشننگ کیا فراہم کرتی ہے، میرے خیال میں سب جانتے ہیں، ٹیبل پارٹیشننگ ہے۔ اکثر یہ ڈسک اور اسپین کی درخواستوں پر الگ الگ فائلیں ہوتی ہیں۔ اگر یہ عام تقسیم کا حصہ ہے تو یہ ایک پارٹیشن کو زیادہ بہتر طریقے سے منتخب کرتا ہے۔
Zabbix کے لیے، خاص طور پر، یہ رینج کے لحاظ سے، رینج کے لحاظ سے استعمال ہوتا ہے، یعنی ہم ٹائم اسٹیمپ (ایک باقاعدہ نمبر، عہد کے آغاز سے لے کر وقت) استعمال کرتے ہیں۔ آپ دن کا آغاز/دن کے اختتام کی وضاحت کرتے ہیں، اور یہ تقسیم ہے۔ اس کے مطابق، اگر آپ دو دن پرانا ڈیٹا طلب کر رہے ہیں، تو ڈیٹا بیس سے سب کچھ تیزی سے بازیافت ہو جاتا ہے، کیونکہ آپ کو صرف ایک فائل کو کیشے میں لوڈ کرنے اور اسے واپس کرنے کی ضرورت ہوتی ہے (بڑے ٹیبل کے بجائے)۔
بہت سے ڈیٹا بیس داخل کرنے کی رفتار بھی بڑھاتے ہیں (ایک چائلڈ ٹیبل میں داخل کرنا)۔ میں ابھی کے لیے خلاصہ بول رہا ہوں، لیکن یہ بھی ممکن ہے۔ تقسیم کرنا اکثر مدد کرتا ہے۔
NoSQL کے لیے لچکدار تلاش
حال ہی میں، 3.4 میں، ہم نے ایک NoSQL حل نافذ کیا۔ Elasticsearch میں لکھنے کی صلاحیت شامل کی گئی۔ آپ مخصوص قسمیں لکھ سکتے ہیں: آپ منتخب کرتے ہیں - یا تو نمبر لکھیں یا کچھ نشانیاں؛ ہمارے پاس سٹرنگ ٹیکسٹ ہے، آپ Elasticsearch پر لاگ لکھ سکتے ہیں... اس کے مطابق، ویب انٹرفیس Elasticsearch تک بھی رسائی حاصل کرے گا۔ یہ کچھ معاملات میں بہت اچھا کام کرتا ہے، لیکن اس وقت اسے استعمال کیا جا سکتا ہے۔
ٹائم اسکیل ڈی بی۔ ہائپر ٹیبلز
4.4.2 کے لیے ہم نے TimescaleDB جیسی ایک چیز پر توجہ دی۔ یہ کیا ہے؟ یہ PostgreSQL کے لیے ایک توسیع ہے، یعنی اس کا مقامی PostgreSQL انٹرفیس ہے۔ اس کے علاوہ، یہ توسیع آپ کو ٹائم سیریز ڈیٹا کے ساتھ زیادہ موثر طریقے سے کام کرنے اور خودکار تقسیم کرنے کی اجازت دیتی ہے۔ یہ کیسا لگتا ہے:
یہ ہائپر ٹیبل ہے - ٹائم اسکیل میں ایسا تصور موجود ہے۔ یہ ایک ہائپر ٹیبل ہے جسے آپ بناتے ہیں، اور اس میں ٹکڑے ہوتے ہیں۔ ٹکڑے پارٹیشنز ہیں، یہ چائلڈ ٹیبلز ہیں، اگر میں غلط نہیں ہوں۔ یہ واقعی موثر ہے۔
TimescaleDB اور PostgreSQL
جیسا کہ TimescaleDB مینوفیکچررز یقین دہانی کراتے ہیں، وہ سوالات پر کارروائی کرنے کے لیے ایک زیادہ درست الگورتھم استعمال کرتے ہیں، خاص طور پر داخلوں میں، جو انہیں ڈیٹا سیٹ داخل کرنے کے بڑھتے ہوئے سائز کے ساتھ تقریباً مستقل کارکردگی رکھنے کی اجازت دیتا ہے۔ یعنی، پوسٹگریس کی 200 ملین قطاروں کے بعد، عام طور پر بہت زیادہ گھٹنا شروع ہو جاتا ہے اور کارکردگی کو لفظی طور پر صفر کر دیتا ہے، جبکہ ٹائم سکیل آپ کو کسی بھی مقدار میں ڈیٹا کے ساتھ زیادہ سے زیادہ مؤثر طریقے سے انسرٹس داخل کرنے کی اجازت دیتا ہے۔
TimescaleDB کیسے انسٹال کریں؟ یہ آسان ہے!
یہ دستاویزات میں ہے، یہ بیان کیا گیا ہے - آپ اسے کسی بھی پیکیج سے انسٹال کر سکتے ہیں... یہ سرکاری پوسٹگریس پیکجوں پر منحصر ہے۔ دستی طور پر مرتب کیا جا سکتا ہے۔ ایسا ہوا کہ مجھے ڈیٹا بیس کے لیے مرتب کرنا پڑا۔
Zabbix پر ہم صرف Extention کو فعال کرتے ہیں۔ میرا خیال ہے کہ وہ لوگ جنہوں نے پوسٹگریس میں ایکسٹینشن کا استعمال کیا... آپ صرف ایکسٹینشن کو ایکٹیویٹ کرتے ہیں، اسے زیبکس ڈیٹا بیس کے لیے بنائیں جسے آپ استعمال کر رہے ہیں۔
اور آخری مرحلہ...
ٹائم اسکیل ڈی بی۔ ہسٹری ٹیبلز کی ہجرت
آپ کو ایک ہائپر ٹیبل بنانے کی ضرورت ہے۔ اس کے لیے ایک خاص فنکشن ہے - ہائیپر ٹیبل بنائیں۔ اس میں، پہلا پیرامیٹر وہ ٹیبل ہے جو اس ڈیٹا بیس میں درکار ہے (جس کے لیے آپ کو ایک ہائپر ٹیبل بنانا ہوگا)۔
وہ فیلڈ جس کے ذریعے تخلیق کرنا ہے، اور chunk_time_interval (یہ ٹکڑوں کا وقفہ ہے (جو پارٹیشنز استعمال کرنے کی ضرورت ہے)۔ 86 ایک دن ہے۔
منتقلی_ڈیٹا پیرامیٹر: اگر آپ سچ میں داخل کرتے ہیں، تو یہ تمام موجودہ ڈیٹا کو پہلے سے بنائے گئے حصوں میں منتقل کر دے گا۔
میں نے خود migrate_data استعمال کیا ہے - آپ کا ڈیٹا بیس کتنا بڑا ہے اس پر منحصر ہے کہ اس میں کافی وقت لگتا ہے۔ میرے پاس ایک ٹیرا بائٹ سے زیادہ تھی - اسے بنانے میں ایک گھنٹہ سے زیادہ کا وقت لگا۔ کچھ معاملات میں، جانچ کے دوران، میں نے متن (ہسٹری_ٹیکسٹ) اور سٹرنگ (ہسٹری_سٹر) کے لیے تاریخی ڈیٹا کو حذف کر دیا تاکہ انھیں منتقل نہ کیا جا سکے - وہ میرے لیے واقعی دلچسپ نہیں تھے۔
اور ہم اپنے db_extention میں آخری اپ ڈیٹ کرتے ہیں: ہم timescaledb کو انسٹال کرتے ہیں تاکہ ڈیٹا بیس اور خاص طور پر ہمارا Zabbix سمجھے کہ db_extention موجود ہے۔ وہ اسے چالو کرتا ہے اور ڈیٹا بیس میں صحیح نحو اور سوالات کا استعمال کرتا ہے، ان "خصوصیات" کو استعمال کرتے ہوئے جو TimescaleDB کے لیے ضروری ہیں۔
سرور کی ترتیب
میں نے دو سرورز کا استعمال کیا۔ پہلا سرور کافی چھوٹی ورچوئل مشین، 20 پروسیسرز، 16 گیگا بائٹس ریم ہے۔ میں نے اس پر پوسٹگریس 10.8 کو تشکیل دیا:
آپریٹنگ سسٹم ڈیبین تھا، فائل سسٹم xfs تھا۔ میں نے اس مخصوص ڈیٹا بیس کو استعمال کرنے کے لیے کم سے کم سیٹنگز بنائی ہیں، مائنس کیا جو Zabbix خود استعمال کرے گا۔ اسی مشین پر ایک Zabbix سرور، PostgreSQL اور لوڈ ایجنٹس تھے۔
میں نے 50 فعال ایجنٹوں کا استعمال کیا ہے جو LoadableModule کو تیزی سے مختلف نتائج پیدا کرنے کے لیے استعمال کرتے ہیں۔ وہ وہی ہیں جنہوں نے تار، نمبر وغیرہ بنائے۔ میں نے ڈیٹا بیس کو بہت سارے ڈیٹا سے بھر دیا۔ ابتدائی طور پر، ترتیب میں فی میزبان 5 ہزار ڈیٹا عناصر شامل تھے، اور تقریباً ہر ڈیٹا عنصر میں ایک ٹرگر ہوتا تھا - تاکہ یہ ایک حقیقی سیٹ اپ ہو۔ بعض اوقات آپ کو استعمال کرنے کے لیے ایک سے زیادہ ٹرگر کی بھی ضرورت ہوتی ہے۔
میں نے اپ ڈیٹ کے وقفہ اور بوجھ کو نہ صرف 50 ایجنٹس (مزید شامل کر کے) استعمال کرکے ریگولیٹ کیا بلکہ متحرک ڈیٹا عناصر کا استعمال کرکے اور اپ ڈیٹ کے وقفہ کو 4 سیکنڈ تک کم کیا۔
کارکردگی کا امتحان. PostgreSQL: 36 ہزار NVPs
پہلی لانچ، میرا پہلا سیٹ اپ اس ہارڈ ویئر پر خالص PostreSQL 10 پر تھا (35 ہزار ویلیوز فی سیکنڈ)۔ عام طور پر، جیسا کہ آپ اسکرین پر دیکھ سکتے ہیں، ڈیٹا داخل کرنے میں ایک سیکنڈ کا حصہ لگتا ہے - سب کچھ اچھا اور تیز ہے، SSD ڈرائیوز (200 گیگا بائٹس)۔ صرف یہ ہے کہ 20 جی بی کافی تیزی سے بھر جاتا ہے۔
مستقبل میں اس طرح کے بہت سارے گراف ہوں گے۔ یہ ایک معیاری Zabbix سرور پرفارمنس ڈیش بورڈ ہے۔
پہلا گراف فی سیکنڈ کی قدروں کی تعداد ہے (نیلے، اوپر بائیں)، اس معاملے میں 35 ہزار اقدار۔ یہ (اوپر کا مرکز) تعمیراتی عمل کی لوڈنگ ہے، اور یہ (اوپر دائیں) اندرونی عمل کی لوڈنگ ہے: ہسٹری سنسر اور ہاؤس کیپر، جو یہاں (نیچے مرکز) کافی عرصے سے چل رہا ہے۔
یہ گراف (نیچے مرکز) ValueCache کے استعمال کو دکھاتا ہے - ٹرگرز کے لیے کتنے ValueCache ہٹ ہوتے ہیں (کئی ہزار ویلیوز فی سیکنڈ)۔ ایک اور اہم گراف چوتھا (نیچے بائیں) ہے، جو ہسٹری کیچ کا استعمال ظاہر کرتا ہے، جس کے بارے میں میں نے بات کی، جو ڈیٹا بیس میں داخل کرنے سے پہلے ایک بفر ہے۔
کارکردگی کا امتحان. PostgreSQL: 50 ہزار NVPs
اس کے بعد، میں نے اسی ہارڈ ویئر پر بوجھ کو 50 ہزار ویلیو فی سیکنڈ تک بڑھا دیا۔ جب ہاؤس کیپر نے لوڈ کیا تو حساب کے ساتھ 10-2 سیکنڈ میں 3 ہزار ویلیو ریکارڈ کی گئی۔ کیا، حقیقت میں، مندرجہ ذیل اسکرین شاٹ میں دکھایا گیا ہے:
"ہاؤس کیپر" پہلے سے ہی کام میں مداخلت کرنے لگا ہے، لیکن عام طور پر، تاریخ میں ڈوبنے والوں پر بوجھ اب بھی 60% (تیسرا گراف، اوپر دائیں) کی سطح پر ہے۔ ہسٹری کیچ پہلے ہی فعال طور پر بھرنا شروع کر دیتا ہے جب ہاؤس کیپر چل رہا ہوتا ہے (نیچے بائیں)۔ یہ تقریباً آدھا گیگا بائٹ تھا، 20% بھرا ہوا تھا۔
کارکردگی کا امتحان. PostgreSQL: 80 ہزار NVPs
پھر میں نے اسے 80 ہزار ویلیو فی سیکنڈ تک بڑھا دیا:
یہ تقریباً 400 ہزار ڈیٹا عناصر، 280 ہزار محرکات تھے۔ ڈالیں، جیسا کہ آپ دیکھ سکتے ہیں، تاریخ کے ڈوبنے والوں کے بوجھ کے لحاظ سے (ان میں سے 30 تھے) پہلے ہی کافی زیادہ تھا۔ پھر میں نے مختلف پیرامیٹرز میں اضافہ کیا: ہسٹری سنکرز، کیش... اس ہارڈ ویئر پر، ہسٹری سنکرز کا بوجھ زیادہ سے زیادہ بڑھنے لگا، تقریباً "شیلف پر" - اس کے مطابق، ہسٹری کیچ بہت زیادہ بوجھ میں چلا گیا:
اس سارے عرصے میں میں نے سسٹم کے تمام پیرامیٹرز (پروسیسر کا استعمال کیسے کیا جاتا ہے، RAM) کی نگرانی کی اور دریافت کیا کہ ڈسک کا استعمال زیادہ سے زیادہ ہے - میں نے اس ہارڈ ویئر پر، اس ورچوئل مشین پر اس ڈسک کی زیادہ سے زیادہ صلاحیت حاصل کی۔ "پوسٹگریس" نے اتنی شدت سے ڈیٹا کو کافی فعال طور پر ڈمپ کرنا شروع کر دیا، اور ڈسک کے پاس اب لکھنے، پڑھنے کا وقت نہیں تھا...
میں نے ایک اور سرور لیا جس میں پہلے سے ہی 48 پروسیسر اور 128 گیگا بائٹس ریم تھی:
میں نے اسے "ٹیون" بھی کیا - ہسٹری سنسر (60 ٹکڑے) انسٹال کیا اور قابل قبول کارکردگی حاصل کی۔ درحقیقت، ہم "شیلف پر" نہیں ہیں، لیکن یہ شاید پیداواری صلاحیت کی حد ہے، جہاں اس کے بارے میں کچھ کرنا پہلے سے ہی ضروری ہے۔
کارکردگی کا امتحان. ٹائم اسکیل ڈی بی: 80 ہزار NVPs
میرا بنیادی کام TimescaleDB استعمال کرنا تھا۔ ہر گراف ایک ڈپ دکھاتا ہے:
یہ ناکامیاں درست طور پر ڈیٹا کی منتقلی ہیں۔ اس کے بعد، Zabbix سرور میں، تاریخ کے ڈوبنے والوں کی لوڈنگ پروفائل، جیسا کہ آپ دیکھ سکتے ہیں، بہت بدل گیا ہے۔ یہ آپ کو تقریباً 3 گنا تیزی سے ڈیٹا داخل کرنے اور کم HistoryCache استعمال کرنے کی اجازت دیتا ہے - اس کے مطابق، آپ کو وقت پر ڈیٹا ڈیلیور کیا جائے گا۔ ایک بار پھر، 80 ہزار اقدار فی سیکنڈ کافی زیادہ شرح ہے (یقینا، Yandex کے لئے نہیں)۔ مجموعی طور پر یہ ایک سرور کے ساتھ کافی بڑا سیٹ اپ ہے۔
PostgreSQL کارکردگی کا ٹیسٹ: 120 ہزار NVPs
اس کے بعد، میں نے ڈیٹا عناصر کی تعداد کو نصف ملین تک بڑھا دیا اور 125 ہزار فی سیکنڈ کی حسابی قدر حاصل کی:
اور مجھے یہ گراف ملے:
اصولی طور پر، یہ ایک ورکنگ سیٹ اپ ہے، یہ کافی دیر تک کام کر سکتا ہے۔ لیکن چونکہ میرے پاس صرف 1,5 ٹیرا بائٹ ڈسک تھی، اس لیے میں نے اسے چند دنوں میں استعمال کر لیا۔ سب سے اہم بات یہ ہے کہ اسی وقت TimescaleDB پر نئے پارٹیشنز بنائے گئے تھے، اور کارکردگی کے حوالے سے یہ مکمل طور پر کسی کا دھیان نہیں تھا، جو MySQL کے بارے میں نہیں کہا جا سکتا۔
عام طور پر، پارٹیشنز رات کو بنائے جاتے ہیں، کیونکہ یہ عام طور پر ٹیبل کے ساتھ اندراج اور کام کو روکتا ہے اور سروس کی تنزلی کا باعث بن سکتا ہے۔ اس معاملے میں ایسا نہیں ہے! اہم کام TimescaleDB کی صلاحیتوں کو جانچنا تھا۔ نتیجہ مندرجہ ذیل اعداد و شمار تھا: فی سیکنڈ 120 ہزار اقدار.
کمیونٹی میں بھی مثالیں ہیں:
اس شخص نے TimescaleDB کو بھی آن کر دیا اور io.weight استعمال کرنے کا بوجھ پروسیسر پر گر گیا۔ اور TimescaleDB کے شامل ہونے کی وجہ سے اندرونی عمل کے عناصر کا استعمال بھی کم ہو گیا ہے۔ مزید یہ کہ یہ عام پینکیک ڈسکیں ہیں، یعنی عام ڈسکوں پر ایک عام ورچوئل مشین (ایس ایس ڈی نہیں)!
کچھ چھوٹے سیٹ اپ کے لیے جو ڈسک کی کارکردگی سے محدود ہیں، TimescaleDB، میری رائے میں، ایک بہت اچھا حل ہے۔ یہ آپ کو ڈیٹا بیس کے لیے تیز تر ہارڈ ویئر پر منتقل ہونے سے پہلے کام جاری رکھنے کی اجازت دے گا۔
میں آپ سب کو اپنے پروگراموں میں مدعو کرتا ہوں: ماسکو میں کانفرنس، ریگا میں سمٹ۔ ہمارے چینلز استعمال کریں - ٹیلیگرام، فورم، آئی آر سی۔ اگر آپ کے کوئی سوالات ہیں تو ہماری میز پر آئیں، ہم ہر چیز کے بارے میں بات کر سکتے ہیں۔
سامعین کے سوالات
سامعین سے سوال (اس کے بعد - A): - اگر TimescaleDB کو ترتیب دینا اتنا آسان ہے، اور اس سے کارکردگی کو اتنا فروغ ملتا ہے، تو شاید اسے Postgres کے ساتھ Zabbix کو ترتیب دینے کے لیے ایک بہترین عمل کے طور پر استعمال کیا جانا چاہیے؟ اور کیا اس حل کے کوئی نقصانات اور نقصانات ہیں، یا آخر کار، اگر میں نے اپنے لیے Zabbix بنانے کا فیصلہ کیا ہے، تو میں آسانی سے Postgres لے سکتا ہوں، وہاں پر Timescale انسٹال کر سکتا ہوں، اسے استعمال کر سکتا ہوں اور کسی پریشانی کے بارے میں نہیں سوچ سکتا؟
AG: - ہاں، میں کہوں گا کہ یہ ایک اچھی تجویز ہے: TimescaleDB ایکسٹینشن کے ساتھ فوری طور پر Postgres استعمال کریں۔ جیسا کہ میں نے پہلے ہی کہا، بہت سارے اچھے جائزے، اس حقیقت کے باوجود کہ یہ "خصوصیت" تجرباتی ہے۔ لیکن اصل میں ٹیسٹ سے پتہ چلتا ہے کہ یہ ایک بہت اچھا حل ہے (TimescaleDB کے ساتھ) اور مجھے لگتا ہے کہ یہ تیار ہو جائے گا! ہم نگرانی کر رہے ہیں کہ یہ توسیع کس طرح تیار ہوتی ہے اور ضرورت کے مطابق تبدیلیاں کریں گے۔
ترقی کے دوران بھی، ہم نے ان کی ایک معروف "خصوصیات" پر انحصار کیا: ٹکڑوں کے ساتھ تھوڑا مختلف طریقے سے کام کرنا ممکن تھا۔ لیکن پھر انہوں نے اسے اگلی ریلیز میں کاٹ دیا، اور ہمیں اس کوڈ پر انحصار کرنا چھوڑنا پڑا۔ میں اس حل کو بہت سے سیٹ اپ پر استعمال کرنے کی سفارش کروں گا۔ اگر آپ MySQL استعمال کرتے ہیں... اوسط سیٹ اپ کے لیے، کوئی بھی حل اچھا کام کرتا ہے۔
اور: - کمیونٹی کے آخری گرافس پر، "ہاؤس کیپر" کے ساتھ ایک گراف تھا:
اس نے کام جاری رکھا۔ ٹائم اسکیل ڈی بی کے ساتھ ہاؤس کیپر کیا کرتا ہے؟
AG: - اب میں یقین سے نہیں کہہ سکتا - میں کوڈ دیکھوں گا اور آپ کو مزید تفصیل سے بتاؤں گا۔ یہ ٹائم اسکیل ڈی بی سوالات کا استعمال ٹکڑوں کو حذف کرنے کے لیے نہیں، بلکہ کسی نہ کسی طرح ان کو جمع کرنے کے لیے کرتا ہے۔ میں ابھی تک اس تکنیکی سوال کا جواب دینے کے لیے تیار نہیں ہوں۔ ہم آج یا کل اسٹینڈ پر مزید معلومات حاصل کریں گے۔
اور: – میرے پاس بھی ایسا ہی سوال ہے – ٹائم اسکیل میں ڈیلیٹ آپریشن کی کارکردگی کے بارے میں۔
A (سامعین کی طرف سے جواب): – جب آپ کسی ٹیبل سے ڈیٹا ڈیلیٹ کرتے ہیں، اگر آپ اسے ڈیلیٹ کے ذریعے کرتے ہیں، تو آپ کو ٹیبل سے گزرنا ہوگا - ڈیلیٹ کریں، صاف کریں، مستقبل کے خلا کے لیے ہر چیز کو نشان زد کریں۔ ٹائم اسکیل میں، چونکہ آپ کے پاس ٹکڑے ہیں، آپ گر سکتے ہیں۔ موٹے الفاظ میں، آپ صرف اس فائل کو بتاتے ہیں جو بڑے ڈیٹا میں ہے: "حذف کریں!"
ٹائم اسکیل آسانی سے سمجھتا ہے کہ اس طرح کا حصہ اب موجود نہیں ہے۔ اور چونکہ یہ استفسار کے منصوبہ ساز میں مربوط ہے، اس لیے یہ آپ کے حالات کو منتخب یا دیگر کارروائیوں میں پکڑنے کے لیے ہکس کا استعمال کرتا ہے اور فوراً سمجھ جاتا ہے کہ یہ حصہ اب موجود نہیں ہے - "میں اب وہاں نہیں جاؤں گا!" (ڈیٹا دستیاب نہیں ہے)۔ بس! یعنی، ایک ٹیبل اسکین کو بائنری فائل ڈیلیٹ کرنے سے بدل دیا جاتا ہے، لہذا یہ تیز ہے۔
اور: - ہم پہلے ہی نان ایس کیو ایل کے موضوع کو چھو چکے ہیں۔ جہاں تک میں سمجھتا ہوں، Zabbix کو واقعی ڈیٹا میں ترمیم کرنے کی ضرورت نہیں ہے، اور یہ سب کچھ لاگ کی طرح ہے۔ کیا مخصوص ڈیٹا بیس کا استعمال ممکن ہے جو اپنے ڈیٹا کو تبدیل نہیں کر سکتے، لیکن ساتھ ہی بہت تیزی سے محفوظ، جمع اور تقسیم کرتے ہیں - کلک ہاؤس، مثال کے طور پر، کافکا جیسا کچھ؟... کافکا بھی ایک لاگ ہے! کیا کسی طرح ان کو ضم کرنا ممکن ہے؟
AG: - ان لوڈنگ کی جا سکتی ہے۔ ورژن 3.4 سے ہمارے پاس ایک خاص "خصوصیت" ہے: آپ تمام تاریخی فائلیں، واقعات، باقی سب کچھ فائلوں میں لکھ سکتے ہیں۔ اور پھر اسے کچھ ہینڈلر کا استعمال کرتے ہوئے کسی دوسرے ڈیٹا بیس پر بھیجیں۔ درحقیقت، بہت سے لوگ دوبارہ کام کرتے ہیں اور براہ راست ڈیٹا بیس پر لکھتے ہیں۔ فلائی پر، ہسٹری ڈوبنے والے یہ سب کچھ فائلوں میں لکھتے ہیں، ان فائلوں کو گھماتے ہیں، وغیرہ، اور آپ اسے کلک ہاؤس میں منتقل کر سکتے ہیں۔ میں منصوبوں کے بارے میں نہیں کہہ سکتا، لیکن شاید NoSQL حل (جیسے Clickhouse) کے لیے مزید تعاون جاری رہے گا۔
اور: - عام طور پر، یہ پتہ چلتا ہے کہ آپ پوسٹگریس سے مکمل طور پر چھٹکارا حاصل کر سکتے ہیں؟
AG: - بلاشبہ، زبکس میں سب سے مشکل حصہ تاریخی میزیں ہیں، جو سب سے زیادہ مسائل اور واقعات پیدا کرتی ہیں۔ اس صورت میں، اگر آپ واقعات کو طویل عرصے تک ذخیرہ نہیں کرتے ہیں اور تاریخ کو رجحانات کے ساتھ کسی اور تیز اسٹوریج میں ذخیرہ کرتے ہیں، تو عام طور پر، میرے خیال میں، کوئی مسئلہ نہیں ہوگا۔
اور: - کیا آپ اندازہ لگا سکتے ہیں کہ اگر آپ کلک ہاؤس پر سوئچ کرتے ہیں تو ہر چیز کتنی تیزی سے کام کرے گی، مثال کے طور پر؟
AG: - میں نے اس کا تجربہ نہیں کیا ہے۔ میرا خیال ہے کہ کم از کم ایک ہی نمبر کو کافی آسانی سے حاصل کیا جا سکتا ہے، اس لیے کہ کلک ہاؤس کا اپنا انٹرفیس ہے، لیکن میں یقین سے نہیں کہہ سکتا۔ ٹیسٹ کرنا بہتر ہے۔ یہ سب کنفیگریشن پر منحصر ہے: آپ کے پاس کتنے میزبان ہیں، وغیرہ۔ داخل کرنا ایک چیز ہے، لیکن آپ کو اس ڈیٹا کو بازیافت کرنے کی بھی ضرورت ہے - گرافانا یا کچھ اور۔
اور: - تو ہم مساوی لڑائی کے بارے میں بات کر رہے ہیں، نہ کہ ان تیز ڈیٹا بیس کے عظیم فائدے کے بارے میں؟
AG: - میرا خیال ہے کہ جب ہم انضمام کریں گے تو زیادہ درست ٹیسٹ ہوں گے۔
اور: - اچھا پرانا RRD کہاں گیا؟ کس چیز نے آپ کو ایس کیو ایل ڈیٹا بیس میں تبدیل کیا؟ ابتدائی طور پر، تمام میٹرکس آر آر ڈی پر جمع کیے گئے تھے۔
AG: - زیبکس کے پاس RRD تھا، شاید ایک بہت قدیم ورژن میں۔ SQL ڈیٹا بیس ہمیشہ رہے ہیں - ایک کلاسک نقطہ نظر۔ کلاسک نقطہ نظر MySQL، PostgreSQL ہے (وہ بہت طویل عرصے سے موجود ہیں)۔ ہم نے تقریباً کبھی بھی SQL اور RRD ڈیٹا بیس کے لیے مشترکہ انٹرفیس استعمال نہیں کیا۔
کچھ اشتہارات 🙂
ہمارے ساتھ رہنے کے لیے آپ کا شکریہ۔ کیا آپ کو ہمارے مضامین پسند ہیں؟ مزید دلچسپ مواد دیکھنا چاہتے ہیں؟ آرڈر دے کر یا دوستوں کو مشورہ دے کر ہمارا ساتھ دیں، , انٹری لیول سرورز کا ایک انوکھا اینالاگ، جو ہم نے آپ کے لیے ایجاد کیا تھا: (RAID1 اور RAID10 کے ساتھ دستیاب، 24 کور تک اور 40GB DDR4 تک)۔
ایمسٹرڈیم میں Equinix Tier IV ڈیٹا سینٹر میں Dell R730xd 2 گنا سستا؟ صرف یہاں نیدرلینڈ میں! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 سے! کے بارے میں پڑھا
ماخذ: www.habr.com