🥇 غوسه، معامله کول او خپګان کله چې د InfluxDB سره کار کوي

که تاسو د وخت لړۍ ډیټابیس کاروئ (timeseries db، ويکي) د احصایې سره د سایټ لپاره اصلي ذخیره په توګه، نو د ستونزې حل کولو پرځای تاسو کولی شئ ډیر سر درد ترلاسه کړئ. زه په یوه پروژه کار کوم چې دا ډول ډیټابیس کاروي، او ځینې وختونه InfluxDB، چې به یې بحث وشي، په بشپړه توګه غیر متوقع حیرانتیا وړاندې کوي.

دادعا: لیست شوي مسلې د InfluxDB نسخه 1.7.4 کې پلي کیږي.

ولې د وخت لړۍ؟

پروژه په مختلفو بلاکچینونو کې د راکړې ورکړې تعقیب او د احصایې ښودل دي. په ځانګړې توګه، موږ د مستحکم سکې اخراج او سوځولو ته ګورو (ويکي). د دې معاملو پر بنسټ، تاسو اړتیا لرئ چې ګرافونه جوړ کړئ او د لنډیز میزونه وښایئ.

د معاملو تحلیل کولو پرمهال، یوه مفکوره راپورته شوه: د اصلي ذخیره کولو په توګه د InfluxDB وخت لړۍ ډیټابیس کارولو لپاره. لیږدونه په وخت کې ټکي دي او دوی د وخت لړۍ ماډل کې ښه فټ کوي.

د راټولولو دندې هم خورا اسانه ښکاري - د اوږدې مودې سره د چارټونو پروسس کولو لپاره مثالی. کاروونکي د یو کال لپاره چارټ ته اړتیا لري، او ډیټابیس د پنځو دقیقو وخت چوکاټ سره ډیټا سیټ لري. دا بې معنی ده چې هغه ته ټول سل زره نقطې واستوئ - د اوږدې پروسس کولو سربیره ، دوی به حتی په سکرین کې فټ نشي. تاسو کولی شئ د وخت چوکاټ زیاتولو خپل پلي کول ولیکئ، یا په انفلکس کې جوړ شوي د راټولولو افعال وکاروئ. د دوی په مرسته، تاسو کولی شئ د ورځې لخوا ډاټا ګروپ کړئ او اړین 365 ټکي واستوئ.

دا یو څه ګډوډ و چې دا ډول ډیټابیسونه معمولا د میټریکونو راټولولو هدف لپاره کارول کیږي. د سرورونو څارنه، iot وسایل، هر هغه څه چې له هغې څخه د میلیونونو ټکي فورمه "بهیر": [<وخت> - <میتریک ارزښت>]. مګر که ډیټابیس د لوی ډیټا جریان سره ښه کار وکړي ، نو ولې یو کوچنی حجم باید ستونزې رامینځته کړي؟ د دې په پام کې نیولو سره، موږ کار کولو لپاره InfluxDB واخیست.

په InfluxDB کې نور څه اسانه دي

د یاد شوي مجموعې دندو سربیره، یو بل لوی شی شتون لري - دوامداره پوښتنې (ډاکتر). دا په ډیټابیس کې جوړ شوی مهالویش دی چې کولی شي په مهالویش کې ډاټا پروسس کړي. د مثال په توګه، په هرو 24 ساعتونو کې تاسو کولی شئ د ورځې ټول ریکارډونه ګروپ کړئ، اوسط محاسبه کړئ او یو نوی ټکی په بل میز کې ثبت کړئ پرته له دې چې خپل بایسکلونه ولیکي.

هم لري د ساتلو پالیسي (ډاکتر) - د یوې ټاکلې مودې وروسته د معلوماتو حذف کول. دا ګټور دی کله چې ، د مثال په توګه ، تاسو اړتیا لرئ د یوې اونۍ لپاره د CPU بار په هره ثانیه کې یو ځل اندازه کولو سره ذخیره کړئ ، مګر د څو میاشتو په فاصله کې دا ډول دقت ته اړتیا نشته. په داسې حالت کې، تاسو کولی شئ دا کار وکړئ:

په بل جدول کې د معلوماتو راټولولو لپاره دوامداره پوښتنه رامینځته کړئ؛
د لومړي جدول لپاره، د میټریکونو حذف کولو لپاره پالیسي تعریف کړئ چې د ورته اونۍ څخه زاړه دي.

او انفلکس به په خپلواکه توګه د معلوماتو اندازه کمه کړي او غیر ضروري شیان حذف کړي.

د ذخیره شوي معلوماتو په اړه

ډیر معلومات ندي زیرمه شوي: شاوخوا 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

زه په لیست کې جدول نه ګورم، مګر د معلوماتو نوې پوښتنه لاهم د معاملو ورته سیټ بیرته راګرځوي.

ستونزه یوازې یو ځل ماته راښکاره شوه، ځکه چې د حذف کولو قضیه یوه جلا قضیه وه. مګر د ډیټابیس دا چلند په واضح ډول د "سمه" عملیاتو په چوکاټ کې مناسب نه دی. وروسته ما دا په ګیتوب کې خلاص وموند ټکټ نږدې یو کال دمخه په دې موضوع.

د پایلې په توګه، د ټول ډیټابیس ړنګولو او بیا رغولو کې مرسته وکړه.

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

تشریح:

په لومړۍ غوښتنه کې، موږ د بازار ډیټا سره د هرې سکې لپاره وروستي ټکي ترلاسه کوو. زما په قضیه کې د اتو سکو لپاره اته ټکي.
دویمه غوښتنه یو له نویو ټکو څخه ترلاسه کوي.
دریم د تیرو XNUMX ساعتونو لپاره د معاملو لیست غوښتنه کوي؛ ممکن د دوی څو سوه وي.

اجازه راکړئ روښانه کړم چې InfluxDB په اوتومات ډول د ټاګونو او وخت پراساس یو شاخص رامینځته کوي ، کوم چې پوښتنې ګړندي کوي. په لومړۍ غوښتنه کې سمبول یوه نښه ده.

ما پدې API میتود کې د فشار ازموینه ترسره کړې. د 25 RPS لپاره، سرور د شپږو CPUs بشپړ بار ښودلی:

په ورته وخت کې، د NodeJs پروسې هیڅ ډول بار نه دی چمتو کړی.

د اجرا سرعت لا دمخه د 7-10 RPS لخوا کم شوی: که چیرې یو پیرودونکي په 200 ms کې ځواب ترلاسه کړي، نو 10 پیرودونکي باید یوه ثانیه انتظار وکړي. 25 RPS هغه حد دی چې په کوم کې ثبات زیانمن شوی؛ 500 تېروتنې مراجعینو ته راستانه شوي.

د داسې فعالیت سره زموږ په پروژه کې د انفلوکس کارول ناممکن دي. سربیره پردې: په یوه پروژه کې چیرې چې نظارت ته اړتیا لیدل کیږي ډیری پیرودونکو ته ، ورته ستونزې به څرګند شي او د میټریک سرور به ډیر شي.

پایلې

د ترلاسه شوي تجربې څخه خورا مهم پایله دا ده چې تاسو نشئ کولی یوه نامعلوم ټیکنالوژي پرته له کافي تحلیل څخه په پروژه کې واخلئ. په ګیتوب کې د خلاص مسلو ساده سکرینینګ کولی شي معلومات چمتو کړي ترڅو د اصلي ډیټا سټور په توګه د InfluxDB غوره کولو څخه مخنیوی وکړي.

InfluxDB باید زما د پروژې دندو لپاره ښه فټ وي، مګر لکه څنګه چې تمرین ښودلی، دا ډیټابیس اړتیاوې نه پوره کوي او ډیری بګونه لري.

تاسو کولی شئ دمخه د پروژې ذخیره کې 2.0.0-beta نسخه ومومئ؛ موږ یوازې امید کولی شو چې دوهم نسخه به د پام وړ پرمختګونه ولري. په ورته وخت کې، زه به د TimescaleDB اسناد مطالعه کړم.

سرچینه: www.habr.com

غوسه، معامله کول او خپګان کله چې د InfluxDB سره کار کوي