جيڪڏھن توھان استعمال ڪريو ھڪڙو ٽائيم سيريز ڊيٽابيس (timeseries db، انگن اکرن سان گڏ سائيٽ لاءِ بنيادي ذخيري جي طور تي، پوءِ مسئلو حل ڪرڻ بدران توهان تمام گهڻو سر درد حاصل ڪري سگهو ٿا. مان هڪ منصوبي تي ڪم ڪري رهيو آهيان جيڪو اهڙي ڊيٽابيس کي استعمال ڪري ٿو، ۽ ڪڏهن ڪڏهن InfluxDB، جنهن تي بحث ڪيو ويندو، مڪمل طور تي غير متوقع تعجب پيش ڪيو.
اعلان: فهرست ڏنل مسئلا InfluxDB ورجن 1.7.4 تي لاڳو ٿين ٿا.
ٽائيم سيريز ڇو؟
پروجيڪٽ مختلف بلاڪچين تي ٽرانزيڪشن کي ٽريڪ ڪرڻ ۽ انگ اکر ڏيکاري ٿو. خاص طور تي، اسان مستحڪم سکن جي اخراج ۽ جلڻ تي نظر رکون ٿا (). انهن ٽرانزيڪشن جي بنياد تي، توهان کي گراف ٺاهڻ ۽ خلاصو جدول ڏيکارڻ جي ضرورت آهي.
ٽرانزيڪشن جو تجزيو ڪرڻ دوران، هڪ خيال آيو: استعمال ڪرڻ لاءِ InfluxDB ٽائيم سيريز ڊيٽابيس کي مکيه اسٽوريج طور. ٽرانزيڪشن وقت ۾ پوائنٽون آهن ۽ اهي وقت جي سيريز جي ماڊل ۾ چڱي ريت آهن.
مجموعي ڪارڪردگي پڻ تمام آسان ڏسڻ ۾ اچي ٿي - هڪ ڊگهي عرصي سان چارٽ پروسيسنگ لاء مثالي. صارف کي هڪ سال لاءِ چارٽ جي ضرورت آهي، ۽ ڊيٽابيس ۾ پنجن منٽن جي ٽائيم فريم سان گڏ ڊيٽا سيٽ شامل آهي. هن کي موڪلڻ بي معنيٰ آهي هڪ لک هزار نقطا - ڊگھي پروسيسنگ کان علاوه، اهي اسڪرين تي به مناسب نه هوندا. توھان لکي سگھوٿا پنھنجي عمل کي وقت جي فريم کي وڌائڻ لاءِ، يا استعمال ڪري سگھوٿا ايگريگيشن افعال جو ٺاھيل انفڪس ۾. انهن جي مدد سان، توهان ڏينهن جي ڊيٽا گروپ ڪري سگهو ٿا ۽ گهربل 365 پوائنٽس موڪلي سگهو ٿا.
اهو ٿورڙو مونجهارو هو ته اهڙا ڊيٽابيس اڪثر ڪري ميٽرڪ گڏ ڪرڻ جي مقصد لاءِ استعمال ٿيندا آهن. سرورز جي نگراني، آئي او ٽي ڊوائيسز، هر شي جنهن مان لکين پوائنٽون فارم "فلوٽ": [<time> - <metric value>]. پر جيڪڏهن ڊيٽابيس هڪ وڏي ڊيٽا جي وهڪري سان چڱي طرح ڪم ڪري ٿي، پوء ڇو ته ننڍڙو حجم مسئلا پيدا ڪرڻ گهرجي؟ انهي سان گڏ ذهن ۾، اسان ورتو InfluxDB ڪم ڪرڻ لاء.
InfluxDB ۾ ٻيو ڇا آسان آهي
ذڪر ڪيل مجموعي ڪمن کان علاوه، هڪ ٻي وڏي شيء آهي - مسلسل سوال (). هي ڊيٽابيس ۾ ٺهيل هڪ شيڊولر آهي جيڪو شيڊول تي ڊيٽا کي پروسيس ڪري سگهي ٿو. مثال طور، هر 24 ڪلاڪن ۾ توهان ڏينهن جا سڀئي رڪارڊ گڏ ڪري سگهو ٿا، سراسري حساب ڪري سگهو ٿا ۽ هڪ نئين پوائنٽ کي ٻئي ٽيبل ۾ رڪارڊ ڪري سگهو ٿا بغير توهان جي پنهنجي سائيڪل لکڻ جي.
پڻ آهن برقرار رکڻ جي پاليسين () - هڪ مخصوص مدت کان پوء ڊيٽا کي ختم ڪرڻ کي ترتيب ڏيڻ. اهو مفيد آهي جڏهن، مثال طور، توهان کي هڪ هفتي لاء سي پي يو لوڊ ذخيرو ڪرڻ جي ضرورت آهي ماپ في سيڪنڊ سان هڪ ڀيرو، پر ڪجهه مهينن جي فاصلي تي اهڙي درستگي جي ضرورت ناهي. اهڙي صورتحال ۾، توهان ڪري سگهو ٿا:
- ٻئي جدول ۾ ڊيٽا کي گڏ ڪرڻ لاء مسلسل سوال ٺاهيو؛
- پهرين جدول لاءِ، هڪ پاليسي بيان ڪريو ميٽرڪس کي حذف ڪرڻ لاءِ جيڪي ساڳئي هفتي کان پراڻيون آهن.
۽ انفلوڪس آزاديء سان ڊيٽا جي سائيز کي گھٽائي ڇڏيندو ۽ غير ضروري شيون ختم ڪري ڇڏيندو.
ذخيرو ٿيل ڊيٽا بابت
گهڻو ڊيٽا محفوظ نه آهي: اٽڪل 70 هزار ٽرانزيڪشن ۽ مارڪيٽ جي معلومات سان گڏ ٻيو ملين پوائنٽ. نيون داخلائون شامل ڪرڻ - في ڏينهن 3000 پوائنٽس کان وڌيڪ نه. سائيٽ لاءِ ميٽرڪس پڻ آهن، پر اتي ٿورڙي ڊيٽا آهي ۽، برقرار رکڻ واري پاليسي جي مطابق، اهي هڪ مهيني کان وڌيڪ نه هونديون آهن.
پريشاني
سروس جي ترقي ۽ بعد ۾ جاچ دوران، InfluxDB جي آپريشن ۾ وڌيڪ ۽ وڌيڪ نازڪ مسئلا پيدا ٿيا.
1. ڊيٽا کي ختم ڪرڻ
ٽرانزيڪشن سان گڏ ڊيٽا جو هڪ سلسلو آهي:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'نتيجو
مان ڊيٽا کي حذف ڪرڻ لاء هڪ حڪم موڪلي رهيو آهيان:
DELETE FROM transactions WHERE symbol=’USDT’اڳيون آئون هڪ درخواست ڪريان ٿو حاصل ڪرڻ لاءِ اڳ ۾ ئي ختم ٿيل ڊيٽا. ۽ خالي جواب جي بدران، انفلوڪس ڊيٽا جو حصو واپس ڪري ٿو جيڪو ختم ڪيو وڃي.
مان پوري جدول کي ختم ڪرڻ جي ڪوشش ڪري رهيو آهيان:
DROP MEASUREMENT transactionsمان چيڪ ڪريان ٿو ٽيبل کي ختم ڪرڻ:
SHOW MEASUREMENTSمون کي لسٽ ۾ ٽيبل نه ڏسندا، پر هڪ نئين ڊيٽا سوال اڃا تائين ٽرانزيڪشن جو ساڳيو سيٽ واپس ڏئي ٿو.
مسئلو مون کي صرف هڪ ڀيرو پيش آيو، ڇاڪاڻ ته حذف ڪرڻ وارو معاملو هڪ الڳ ڪيس هو. پر ڊيٽابيس جو هي رويو واضح طور تي "درست" آپريشن جي فريم ورڪ ۾ نه ٿو اچي. بعد ۾ مون ان کي github تي کليل مليو هن موضوع تي لڳ ڀڳ هڪ سال اڳ.
نتيجي طور، مڪمل ڊيٽابيس کي ختم ڪرڻ ۽ پوء بحال ڪرڻ ۾ مدد ڪئي.
2. فلوٽنگ پوائنٽ نمبر
InfluxDB ۾ بلٽ ان فنڪشن استعمال ڪرڻ وقت رياضي جي حسابن ۾ درستي جون غلطيون آھن. اهو نه آهي ته اهو ڪجهه غير معمولي آهي، پر اهو ناپسنديده آهي.
منهنجي صورت ۾، ڊيٽا هڪ مالي جزو آهي ۽ مان ان کي اعلي درستگي سان پروسيس ڪرڻ چاهيندس. انهي جي ڪري، اسان مسلسل سوالن کي ڇڏي ڏيڻ جو منصوبو ٺاهيو.
3. مسلسل سوالن کي مختلف وقت جي زونن ۾ تبديل نه ٿو ڪري سگھجي
خدمت ۾ روزاني ٽرانزيڪشن جي انگن اکرن سان گڏ ٽيبل آهي. هر ڏينهن لاء، توهان کي ان ڏينهن لاء سڀني ٽرانزيڪشن کي گروپ ڪرڻ جي ضرورت آهي. پر هر صارف جو ڏينهن مختلف وقت تي شروع ٿيندو، ۽ تنهن ڪري ٽرانزيڪشن جو سيٽ مختلف هوندو. UTC پاران ها شفٽون جن لاءِ توهان کي ڊيٽا گڏ ڪرڻ جي ضرورت آهي.
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 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCوضاحت:
- پهرين درخواست ۾، اسان مارڪيٽ ڊيٽا سان هر هڪ سکن لاء آخري پوائنٽ حاصل ڪندا آهيون. منهنجي صورت ۾ اٺ سکن لاءِ اٺ پوائنٽ.
- ٻي درخواست نئين پوائنٽن مان هڪ حاصل ڪري ٿي.
- ٽيون هڪ آخري XNUMX ڪلاڪن لاءِ ٽرانزيڪشن جي هڪ فهرست جي درخواست ڪري ٿو؛ ٿي سگهي ٿو انهن مان ڪيترائي سئو.
مون کي واضع ڪرڻ ڏيو ته InfluxDB خود بخود ٽيگ ۽ وقت جي بنياد تي هڪ انڊيڪس ٺاهي ٿو، جيڪو سوالن کي تيز ڪري ٿو. پهرين درخواست ۾ علامت هڪ ٽيگ آهي.
مون هن API طريقي تي زور آزمائي ڪئي آهي. 25 RPS لاءِ، سرور ڏيکاريو مڪمل لوڊ ڇهه سي پي يوز:
ساڳئي وقت، NodeJs عمل سڀني تي لوڊ مهيا نه ڪيو.
عمل جي رفتار اڳ ۾ ئي 7-10 آر پي ايس جي ذريعي خراب ٿي چڪي آهي: جيڪڏهن هڪ ڪلائنٽ 200 ms ۾ جواب حاصل ڪري سگهي ٿو، پوء 10 ڪلائنٽ کي هڪ سيڪنڊ انتظار ڪرڻو پوندو. 25 RPS اها حد آهي جنهن تي استحڪام برداشت ڪيو؛ 500 غلطيون گراهڪن ڏانهن واپس ڪيون ويون.
اهڙي ڪارڪردگي سان اسان جي منصوبي ۾ Influx استعمال ڪرڻ ناممڪن آهي. ان کان علاوه: ھڪڙي منصوبي ۾ جتي نگراني ڪرڻ جي ضرورت آھي ڪيترن ئي مراجعين کي، ساڳيا مسئلا ظاهر ٿي سگھن ٿا ۽ ميٽرڪ سرور اوورلوڊ ٿي ويندو.
ٿڪل
حاصل ڪيل تجربي مان سڀ کان اهم نتيجو اهو آهي ته توهان اڻڄاتل ٽيڪنالاجي کي ڪافي تجزيي کانسواءِ پروجيڪٽ ۾ نٿا وٺي سگهو. Github تي کليل مسئلن جي هڪ سادي اسڪريننگ معلومات مهيا ڪري سگهي ٿي InfluxDB کي مکيه ڊيٽا اسٽور طور چونڊڻ کان بچڻ لاءِ.
InfluxDB منهنجي پروجيڪٽ جي ڪمن لاءِ هڪ سٺو موزون هجڻ گهرجي ها، پر جيئن ته عملي طور ڏيکاريو ويو آهي، هي ڊيٽابيس ضرورتن کي پورو نٿو ڪري ۽ ان ۾ ڪافي بگ آهن.
توھان اڳ ۾ ئي ڳولي سگھو ٿا نسخو 2.0.0-بيٽا پروجيڪٽ جي مخزن ۾؛ اسان صرف اميد ڪري سگھون ٿا ته ٻئي ورزن ۾ وڏيون واڌايون هونديون. ساڳئي وقت ۾، مان پڙهندس TimescaleDB دستاويزن.
جو ذريعو: www.habr.com