🥇 ከ InfluxDB ጋር ሲሰሩ ቁጣ፣ ድርድር እና ድብርት

የጊዜ ተከታታይ ዳታቤዝ ከተጠቀሙ (የጊዜ ተከታታይ ዲቢ፣ wiki) ስታትስቲክስ ላለው ጣቢያ እንደ ዋና ማከማቻ ፣ ከዚያ ችግሩን ከመፍታት ይልቅ ብዙ ራስ ምታት ሊያጋጥምዎት ይችላል። እኔ እንደዚህ አይነት የውሂብ ጎታ የሚጠቀም ፕሮጀክት ላይ እየሰራሁ ነው, እና አንዳንድ ጊዜ InfluxDB, ውይይት ይደረጋል, በአጠቃላይ ያልተጠበቁ አስገራሚ ነገሮችን ያቀርባል.

ማስተባበያማስታወሻ፡ የታዩት ጉዳዮች ለ InfluxDB 1.7.4 ናቸው።

ለምን ተከታታይ ጊዜ?

ፕሮጀክቱ በተለያዩ blockchains ውስጥ ግብይቶችን መከታተል እና ስታቲስቲክስን ማሳየት ነው። በተለይም የተረጋጋ ሳንቲሞችን ልቀት እና ማቃጠል እንመለከታለን (wiki). በእነዚህ ግብይቶች ላይ በመመስረት, ግራፎችን መገንባት እና የምሰሶ ሠንጠረዦችን ማሳየት አለብዎት.

ግብይቶችን በሚተነተንበት ጊዜ አንድ ሀሳብ መጣ፡ InfluxDB የጊዜ ተከታታይ ዳታቤዝ እንደ ዋና ማከማቻ ለመጠቀም። ግብይቶች በጊዜ ውስጥ ነጥቦች ናቸው እና እነሱ በጊዜ ተከታታይ ሞዴል ውስጥ በትክክል ይጣጣማሉ.

የስብስብ ተግባራቶቹ እንዲሁ በጣም ምቹ ይመስላሉ - ለረጅም ጊዜ ገበታዎችን ለመስራት ተስማሚ ናቸው። ተጠቃሚው ለአንድ አመት ገበታ ያስፈልገዋል፣ እና የውሂብ ጎታው የአምስት ደቂቃ የጊዜ ገደብ ያለው የውሂብ ስብስብ ይዟል። ሁሉንም መቶ ሺህ ነጥቦችን ወደ እሱ መላክ ትርጉም የለሽ ነው - ከረዥም ሂደት በስተቀር ፣ በስክሪኑ ላይ አይገጥሙም። የጊዜ ገደብን ለመጨመር የራስዎን ትግበራ መጻፍ ወይም በ Influx ውስጥ የተገነቡትን የመደመር ተግባራትን መጠቀም ይችላሉ። በእነሱ እርዳታ መረጃን በቀን መሰብሰብ እና የተፈለገውን 365 ነጥብ መላክ ይችላሉ.

እንደዚህ ያሉ የውሂብ ጎታዎች አብዛኛውን ጊዜ መለኪያዎችን ለመሰብሰብ መጠቀማቸው ትንሽ አሳፋሪ ነበር። የአገልጋዮች ክትትል፣ iot መሳሪያዎች፣ በሚሊዮኖች የሚቆጠሩ የቅጹ ነጥቦች “የሚፈስሱበት” ሁሉም ነገር፡ [<ጊዜ> - <ሜትሪክ እሴት>]። ነገር ግን የመረጃ ቋቱ ከትልቅ የውሂብ ዥረት ጋር በደንብ የሚሰራ ከሆነ ታዲያ ለምን ትንሽ መጠን ችግር ይፈጥራል? በዚህ ሀሳብ, InfluxDBን ወደ ሥራ ወሰዱ.

በ InfluxDB ውስጥ ሌላ ምን ምቹ ነው።

ከተጠቀሱት የመደመር ተግባራት በተጨማሪ ሌላ ታላቅ ነገር አለ - ቀጣይነት ያለው መጠይቆች (doc). ይህ በመረጃ ቋቱ ውስጥ የተካተተ መርሐግብር አውጪ ሲሆን መረጃን በጊዜ መርሐግብር ማስኬድ ይችላል። ለምሳሌ, በየ 24 ሰዓቱ የቀኑን ሁሉንም መዝገቦች መቦደን, አማካኙን ማስላት እና የራስዎን ብስክሌቶች ሳይጽፉ አንድ አዲስ ነጥብ ወደ ሌላ ጠረጴዛ መጻፍ ይችላሉ.

እንዲሁም አለኝ የማቆያ ፖሊሲዎች (doc) - ከተወሰነ ጊዜ በኋላ ውሂብን ለመሰረዝ ቅንብር. ጠቃሚ ነው, ለምሳሌ, ጭነቱን በሲፒዩ ላይ ለአንድ ሳምንት ያህል በሴኮንድ አንድ ጊዜ መለኪያዎችን ማከማቸት, ነገር ግን በሁለት ወራት ርቀት ላይ, እንዲህ ዓይነቱ ትክክለኛነት አያስፈልግም. በእንደዚህ ዓይነት ሁኔታ ውስጥ ይህንን ማድረግ ይችላሉ-

ውሂብን ወደ ሌላ ሠንጠረዥ ለማዋሃድ ቀጣይነት ያለው ጥያቄ መፍጠር;
ለመጀመሪያው ሠንጠረዥ ከተመሳሳይ ሳምንት በላይ የቆዩ መለኪያዎችን የመሰረዝ ፖሊሲን ይግለጹ።

እና ኢንፍሉክስ የመረጃውን መጠን ይቀንሳል እና አላስፈላጊ መረጃዎችን በራሱ ይሰርዛል።

ስለተከማቸ መረጃ

ብዙ ውሂብ አይከማችም: ወደ 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

በዝርዝሩ ውስጥ ሰንጠረዡን አላየሁም, ነገር ግን አዲሱ የውሂብ ጥያቄ አሁንም ተመሳሳይ የግብይቶች ስብስብ ይመልሳል.

የስረዛው ጉዳይ ራሱን የቻለ ጉዳይ ስለሆነ ችግሩ አንድ ጊዜ ብቻ ተነሳ። ነገር ግን ይህ የመረጃ ቋቱ ባህሪ ከ "ትክክለኛ" ሥራ ማዕቀፍ ጋር በግልጽ አይጣጣምም. በኋላ ላይ github ክፍት ሆኖ ተገኝቷል ትኬት በዚህ ርዕስ ላይ ወደ አንድ ዓመት ገደማ.

በውጤቱም, የጠቅላላው የውሂብ ጎታ መወገድ እና እንደገና መመለስ ረድቷል.

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 እና ከሌሎች የውሂብ ጎታዎች ንፅፅር ጋር ብዙ መመዘኛዎች አሉ። በመጀመሪያ ትውውቅ እነሱ የግብይት ቁሳቁሶችን ይመስሉ ነበር, አሁን ግን በእነሱ ውስጥ የተወሰነ እውነት ያለ ይመስለኛል.

ጉዳዬን ልንገራችሁ።

አገልግሎቱ ላለፉት XNUMX ሰዓታት ስታቲስቲክስን የሚመልስ የኤፒአይ ዘዴን ያቀርባል። በስሌቶች ጊዜ ዘዴው የውሂብ ጎታውን ሶስት ጊዜ ከሚከተሉት ጥያቄዎች ጋር ይጠይቃል።

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 ውስጥ አንድ ኢንዴክስ በራስ-ሰር በታግ እና በጊዜ ይገነባል ይህም ጥያቄዎችን ያፋጥናል. በመጀመሪያው ጥያቄ ምልክት መለያ ነው።

ለዚህ ኤፒአይ ዘዴ የጭንቀት ሙከራ አድርጌያለሁ። ለ25 RPS፣ አገልጋዩ የስድስት ሲፒዩዎች ሙሉ ጭነት አሳይቷል፡-

በተመሳሳይ ጊዜ, የ NodeJs ሂደት ምንም አይነት ጭነት አልሰጠም.

የማስፈጸሚያ ፍጥነቱ ቀድሞውኑ በ7-10 RPS ቀንሷል፡ አንድ ደንበኛ በ200 ms ምላሽ ማግኘት ከቻለ 10 ደንበኞች ለአንድ ሰከንድ መጠበቅ ነበረባቸው። 25 RPS - መረጋጋት የተጎዳበት ድንበር, 500 ስህተቶች ወደ ደንበኞች ተመልሰዋል.

በእንደዚህ አይነት አፈፃፀም, በፕሮጀክታችን ውስጥ ኢንፍሉክስን መጠቀም አይቻልም. ከዚህም በላይ ክትትል ለብዙ ደንበኞች ማሳየት በሚያስፈልግበት ፕሮጀክት ውስጥ ተመሳሳይ ችግሮች ሊታዩ ይችላሉ እና የመለኪያ አገልጋዩ ከመጠን በላይ ይጫናል.

መደምደሚያ

ከተገኘው ልምድ በጣም አስፈላጊው መደምደሚያ በቂ ትንታኔ ከሌለው የማይታወቅ ቴክኖሎጂን ወደ ፕሮጀክት መውሰድ አይችሉም. በgithub ላይ ቀላል ትኬቶችን ማጣራት InfluxDBን እንደ ዋና የመረጃ ማከማቻ ላለመውሰድ መረጃን ሊሰጥ ይችላል።

InfluxDB የፕሮጀክቴን ተግባራት በሚገባ ያሟላል ተብሎ ነበር፣ ነገር ግን ልምምድ እንደሚያሳየው ይህ ዳታቤዝ ፍላጎቶችን አያሟላም እና ብዙ ያበላሻል።

በፕሮጀክት ማከማቻ ውስጥ 2.0.0-beta ስሪትን ማግኘት ይችላሉ, በሁለተኛው ስሪት ውስጥ ጉልህ መሻሻሎች እንደሚኖሩ ተስፋ ማድረግ ይቀራል. እስከዚያው ድረስ የTimescaleDB ሰነዶችን ለማጥናት እሄዳለሁ።

ምንጭ: hab.com

ከ InfluxDB ጋር ሲሰሩ ቁጣ፣ ድርድር እና ድብርት