InfluxDB کے ساتھ کام کرتے وقت غصہ، سودے بازی اور افسردگی

اگر آپ ٹائم سیریز کا ڈیٹا بیس استعمال کرتے ہیں (ٹائم سیریز ڈی بی، وکیپیڈیا) اعداد و شمار کے ساتھ ایک سائٹ کے لئے بنیادی اسٹوریج کے طور پر، پھر مسئلہ کو حل کرنے کے بجائے آپ کو بہت زیادہ سر درد ہو سکتا ہے. میں ایک ایسے پروجیکٹ پر کام کر رہا ہوں جو اس طرح کے ڈیٹا بیس کا استعمال کرتا ہے، اور کبھی کبھی InfluxDB، جس پر بات کی جائے گی، مکمل طور پر غیر متوقع حیرتیں پیش کیں۔

اعلانِ لاتعلقی: درج کردہ مسائل InfluxDB ورژن 1.7.4 پر لاگو ہوتے ہیں۔

کیوں ٹائم سیریز؟

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

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

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

یہ تھوڑا سا الجھا ہوا تھا کہ اس طرح کے ڈیٹا بیس کو عام طور پر میٹرکس جمع کرنے کے مقصد کے لیے استعمال کیا جاتا ہے۔ سرورز کی نگرانی، آئی او ٹی ڈیوائسز، ہر وہ چیز جس سے لاکھوں پوائنٹس فارم "بہاؤ": [<time> - <میٹرک ویلیو>]۔ لیکن اگر ڈیٹا بیس بڑے ڈیٹا کے بہاؤ کے ساتھ اچھی طرح کام کرتا ہے، تو پھر ایک چھوٹا حجم کیوں مسائل پیدا کرے؟ اس کو ذہن میں رکھتے ہوئے، ہم نے InfluxDB کو کام کرنے کے لیے لیا۔

InfluxDB میں اور کیا آسان ہے۔

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

بھی ہے برقرار رکھنے کی پالیسیاں (DOC)—ایک مخصوص مدت کے بعد ڈیٹا ڈیلیٹ کرنا۔ یہ مفید ہے جب، مثال کے طور پر، آپ کو ایک ہفتے کے لیے CPU لوڈ کو ایک سیکنڈ میں ایک بار پیمائش کے ساتھ ذخیرہ کرنے کی ضرورت ہے، لیکن چند ماہ کے فاصلے پر اس طرح کی درستگی کی ضرورت نہیں ہے۔ ایسی صورت حال میں، آپ یہ کر سکتے ہیں:

1. ڈیٹا کو دوسرے ٹیبل میں جمع کرنے کے لیے ایک مسلسل استفسار بنائیں؛
2. پہلی جدول کے لیے، اسی ہفتے سے پرانی میٹرکس کو حذف کرنے کی پالیسی کی وضاحت کریں۔

اور Influx آزادانہ طور پر ڈیٹا کے سائز کو کم کر دے گا اور غیر ضروری چیزوں کو حذف کر دے گا۔

ذخیرہ شدہ ڈیٹا کے بارے میں

زیادہ ڈیٹا محفوظ نہیں ہے: تقریباً 70 ہزار لین دین اور مارکیٹ کی معلومات کے ساتھ مزید ملین پوائنٹس۔ نئی اندراجات شامل کرنا - فی دن 3000 پوائنٹس سے زیادہ نہیں۔ سائٹ کے لیے میٹرکس بھی موجود ہیں، لیکن وہاں ڈیٹا بہت کم ہے اور برقرار رکھنے کی پالیسی کے مطابق، وہ ایک ماہ سے زیادہ کے لیے محفوظ نہیں ہوتے۔

مسائل

سروس کی ترقی اور اس کے بعد کی جانچ کے دوران، InfluxDB کے آپریشن میں زیادہ سے زیادہ اہم مسائل پیدا ہوئے۔

1. ڈیٹا کو حذف کرنا

لین دین کے ساتھ ڈیٹا کا ایک سلسلہ ہے:

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

نتیجہ:

میں ڈیٹا کو حذف کرنے کے لیے ایک کمانڈ بھیج رہا ہوں:

DELETE FROM transactions WHERE symbol=’USDT’

اگلا میں پہلے سے حذف شدہ ڈیٹا وصول کرنے کی درخواست کرتا ہوں۔ اور خالی جواب کے بجائے، Influx ڈیٹا کا وہ حصہ لوٹاتا ہے جسے حذف کرنا چاہیے۔

میں پوری میز کو حذف کرنے کی کوشش کر رہا ہوں:

DROP MEASUREMENT transactions

میں میز کو حذف کرنے کی جانچ کرتا ہوں:

SHOW MEASUREMENTS

مجھے فہرست میں ٹیبل نظر نہیں آرہا ہے، لیکن ایک نیا ڈیٹا استفسار اب بھی لین دین کا وہی سیٹ لوٹاتا ہے۔

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

В результате, помогло удаление и последующее восстановление всей базы.

2. فلوٹنگ پوائنٹ نمبرز

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

میرے معاملے میں، ڈیٹا کا ایک مالیاتی جزو ہے اور میں اسے اعلیٰ درستگی کے ساتھ پروسیس کرنا چاہوں گا۔ اس کی وجہ سے، ہم مسلسل سوالات کو ترک کرنے کا ارادہ رکھتے ہیں۔

3. مسلسل سوالات کو مختلف ٹائم زونز کے مطابق نہیں بنایا جا سکتا

سروس میں روزانہ لین دین کے اعدادوشمار کے ساتھ ایک میز موجود ہے۔ ہر دن کے لیے، آپ کو اس دن کے لیے تمام لین دین کو گروپ کرنے کی ضرورت ہے۔ لیکن ہر صارف کا دن مختلف وقت پر شروع ہوگا، اور اس لیے لین دین کا سیٹ مختلف ہوگا۔ UTC کی طرف سے ہاں 37 مختلف حالتیں وہ شفٹیں جن کے لیے آپ کو ڈیٹا جمع کرنے کی ضرورت ہے۔

InfluxDB میں، وقت کے لحاظ سے گروپ بندی کرتے وقت، آپ اضافی طور پر ایک شفٹ کی وضاحت کر سکتے ہیں، مثال کے طور پر ماسکو ٹائم (UTC+3):

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

لیکن استفسار کا نتیجہ غلط ہوگا۔ کسی وجہ سے، دن کے لحاظ سے گروپ کردہ ڈیٹا 1677 تک واپس شروع ہو جائے گا (InfluxDB اس سال سے باضابطہ طور پر وقت کی حمایت کرتا ہے):

اس مسئلے کو حل کرنے کے لیے، ہم نے عارضی طور پر سروس کو UTC+0 میں تبدیل کر دیا۔

4. کارکردگی

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

میں آپ کو اپنا کیس بتاتا ہوں۔

سروس ایک API طریقہ فراہم کرتی ہے جو آخری دن کے اعدادوشمار واپس کرتی ہے۔ حساب کتاب کرتے وقت، طریقہ درج ذیل سوالات کے ساتھ ڈیٹا بیس سے تین بار استفسار کرتا ہے۔

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

وضاحت:

1. پہلی درخواست میں، ہمیں مارکیٹ ڈیٹا کے ساتھ ہر سکے کے آخری پوائنٹس ملتے ہیں۔ میرے معاملے میں آٹھ سکوں کے لیے آٹھ پوائنٹس۔
2. دوسری درخواست کو تازہ ترین پوائنٹس میں سے ایک ملتا ہے۔
3. تیسرا پچھلے XNUMX گھنٹوں کے لین دین کی فہرست کی درخواست کرتا ہے؛ ان میں سے کئی سو ہو سکتے ہیں۔

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

میں نے اس API طریقہ پر تناؤ کا ٹیسٹ چلایا ہے۔ 25 RPS کے لیے، سرور نے چھ CPUs کے مکمل بوجھ کا مظاہرہ کیا:

ایک ہی وقت میں، NodeJs کے عمل نے کوئی بوجھ فراہم نہیں کیا۔

عمل درآمد کی رفتار پہلے ہی 7-10 RPS سے کم ہو چکی ہے: اگر ایک کلائنٹ 200 ms میں جواب حاصل کر سکتا ہے، تو 10 کلائنٹس کو ایک سیکنڈ انتظار کرنا پڑے گا۔ 25 RPS وہ حد ہے جس پر استحکام کا سامنا کرنا پڑا؛ 500 غلطیاں کلائنٹس کو واپس کر دی گئیں۔

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

آؤٹ پٹ

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

InfluxDB میرے پروجیکٹ کے کاموں کے لیے موزوں ہونا چاہیے تھا، لیکن جیسا کہ پریکٹس نے دکھایا ہے، یہ ڈیٹا بیس ضروریات کو پورا نہیں کرتا اور اس میں بہت سارے کیڑے ہیں۔

آپ پروجیکٹ کے ذخیرے میں پہلے سے ہی ورژن 2.0.0-بیٹا تلاش کر سکتے ہیں؛ ہم صرف امید کر سکتے ہیں کہ دوسرے ورژن میں نمایاں بہتری آئے گی۔ اس دوران میں، میں TimescaleDB دستاویزات کا مطالعہ کروں گا۔

ماخذ: www.habr.com