InfluxDBతో పని చేస్తున్నప్పుడు కోపం, బేరసారాలు మరియు నిరాశ

మీరు సమయ శ్రేణి డేటాబేస్ (టైమ్‌సిరీస్ db, వికీ) గణాంకాలతో కూడిన సైట్ కోసం ప్రధాన నిల్వగా, సమస్యను పరిష్కరించడానికి బదులుగా మీరు చాలా తలనొప్పిని పొందవచ్చు. నేను అటువంటి డేటాబేస్‌ని ఉపయోగించే ప్రాజెక్ట్‌లో పని చేస్తున్నాను మరియు కొన్నిసార్లు InfluxDB, ఇది పూర్తిగా ఊహించని ఆశ్చర్యాలను ప్రదర్శించబడుతుంది.

నిరాకరణ: జాబితా చేయబడిన సమస్యలు InfluxDB వెర్షన్ 1.7.4కి వర్తిస్తాయి.

సమయ శ్రేణి ఎందుకు?

ప్రాజెక్ట్ వివిధ బ్లాక్‌చెయిన్‌లలో లావాదేవీలను ట్రాక్ చేయడం మరియు గణాంకాలను ప్రదర్శించడం. ప్రత్యేకంగా, మేము స్థిరమైన నాణేల ఉద్గారాలను మరియు దహనాన్ని పరిశీలిస్తాము (వికీ) ఈ లావాదేవీల ఆధారంగా, మీరు గ్రాఫ్‌లను రూపొందించాలి మరియు సారాంశ పట్టికలను చూపించాలి.

లావాదేవీలను విశ్లేషిస్తున్నప్పుడు, ఒక ఆలోచన వచ్చింది: InfluxDB సమయ శ్రేణి డేటాబేస్‌ను ప్రధాన నిల్వగా ఉపయోగించడానికి. లావాదేవీలు సమయానికి పాయింట్లు మరియు అవి సమయ శ్రేణి మోడల్‌కి బాగా సరిపోతాయి.

అగ్రిగేషన్ ఫంక్షన్‌లు కూడా చాలా సౌకర్యవంతంగా కనిపించాయి - చాలా కాలం పాటు చార్ట్‌లను ప్రాసెస్ చేయడానికి అనువైనది. వినియోగదారుకు ఒక సంవత్సరం పాటు చార్ట్ అవసరం మరియు డేటాబేస్ ఐదు నిమిషాల సమయ ఫ్రేమ్‌తో సెట్ చేయబడిన డేటాను కలిగి ఉంటుంది. అతనికి మొత్తం లక్ష చుక్కలు పంపడం అర్థరహితం - సుదీర్ఘ ప్రాసెసింగ్‌తో పాటు, అవి స్క్రీన్‌పై కూడా సరిపోవు. మీరు కాలపరిమితిని పెంచడానికి మీ స్వంత అమలును వ్రాయవచ్చు లేదా ఇన్‌ఫ్లక్స్‌లో నిర్మించిన అగ్రిగేషన్ ఫంక్షన్‌లను ఉపయోగించవచ్చు. వారి సహాయంతో, మీరు రోజువారీ డేటాను సమూహపరచవచ్చు మరియు అవసరమైన 365 పాయింట్లను పంపవచ్చు.

అటువంటి డేటాబేస్‌లు సాధారణంగా కొలమానాలను సేకరించే ప్రయోజనం కోసం ఉపయోగించబడటం కొంచెం గందరగోళంగా ఉంది. సర్వర్‌ల పర్యవేక్షణ, iot పరికరాలు, "ఫ్లో" రూపంలో మిలియన్ల కొద్దీ పాయింట్‌ల నుండి ప్రతిదీ: [<time> - <మెట్రిక్ విలువ>]. పెద్ద డేటా ప్రవాహంతో డేటాబేస్ బాగా పనిచేస్తే, చిన్న వాల్యూమ్ ఎందుకు సమస్యలను కలిగిస్తుంది? దీన్ని దృష్టిలో ఉంచుకుని, మేము పని చేయడానికి InfluxDB తీసుకున్నాము.

InfluxDBలో ఇంకా ఏది సౌకర్యవంతంగా ఉంటుంది

పేర్కొన్న అగ్రిగేషన్ ఫంక్షన్‌లు కాకుండా, మరొక గొప్ప విషయం ఉంది - నిరంతర ప్రశ్నలు (డిఓసి) ఇది షెడ్యూల్‌లో డేటాను ప్రాసెస్ చేయగల డేటాబేస్‌లో నిర్మించిన షెడ్యూలర్. ఉదాహరణకు, ప్రతి 24 గంటలకు మీరు రోజులోని అన్ని రికార్డులను సమూహపరచవచ్చు, సగటును లెక్కించవచ్చు మరియు మీ స్వంత సైకిళ్లను వ్రాయకుండా మరొక పట్టికలో ఒక కొత్త పాయింట్‌ను రికార్డ్ చేయవచ్చు.

కూడా ఉన్నాయి నిలుపుదల విధానాలు (డిఓసి)-నిర్దిష్ట వ్యవధి తర్వాత డేటా తొలగింపును ఏర్పాటు చేయడం. ఉదాహరణకు, మీరు సెకనుకు ఒకసారి కొలతలతో CPU లోడ్‌ను ఒక వారం పాటు నిల్వ చేయవలసి వచ్చినప్పుడు ఇది ఉపయోగకరంగా ఉంటుంది, అయితే కొన్ని నెలల దూరంలో అలాంటి ఖచ్చితత్వం అవసరం లేదు. అటువంటి పరిస్థితిలో, మీరు దీన్ని చేయవచ్చు:

1. మరొక పట్టికలో డేటాను సమగ్రపరచడానికి నిరంతర ప్రశ్నను సృష్టించండి;
2. మొదటి పట్టిక కోసం, అదే వారం కంటే పాత మెట్రిక్‌లను తొలగించే విధానాన్ని నిర్వచించండి.

మరియు ఇన్‌ఫ్లక్స్ స్వతంత్రంగా డేటా పరిమాణాన్ని తగ్గిస్తుంది మరియు అనవసరమైన విషయాలను తొలగిస్తుంది.

నిల్వ చేసిన డేటా గురించి

ఎక్కువ డేటా నిల్వ చేయబడదు: సుమారు 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

వివరణ:

1. మొదటి అభ్యర్థనలో, మేము మార్కెట్ డేటాతో ప్రతి నాణెం కోసం చివరి పాయింట్లను పొందుతాము. నా విషయంలో ఎనిమిది నాణేలకు ఎనిమిది పాయింట్లు.
2. రెండవ అభ్యర్థన సరికొత్త పాయింట్‌లలో ఒకదాన్ని పొందుతుంది.
3. మూడవది గత XNUMX గంటల లావాదేవీల జాబితాను అభ్యర్థిస్తుంది; వాటిలో కొన్ని వందలు ఉండవచ్చు.

InfluxDB ట్యాగ్‌లు మరియు సమయం ఆధారంగా స్వయంచాలకంగా ఇండెక్స్‌ను నిర్మిస్తుందని నేను స్పష్టం చేస్తున్నాను, ఇది ప్రశ్నలను వేగవంతం చేస్తుంది. మొదటి అభ్యర్థనలో చిహ్నం అనేది ట్యాగ్.

నేను ఈ API పద్ధతిలో ఒత్తిడి పరీక్షను అమలు చేసాను. 25 RPS కోసం, సర్వర్ ఆరు CPUల పూర్తి లోడ్‌ను ప్రదర్శించింది:

అదే సమయంలో, NodeJs ప్రక్రియ ఎటువంటి లోడ్‌ను అందించలేదు.

అమలు వేగం ఇప్పటికే 7-10 RPS తగ్గింది: ఒక క్లయింట్ 200 msలో ప్రతిస్పందనను అందుకోగలిగితే, 10 మంది క్లయింట్లు ఒక సెకను వేచి ఉండవలసి ఉంటుంది. 25 RPS అనేది స్థిరత్వం దెబ్బతినే పరిమితి; 500 ఎర్రర్‌లు క్లయింట్‌లకు అందించబడ్డాయి.

అటువంటి పనితీరుతో మా ప్రాజెక్ట్‌లో ఇన్‌ఫ్లక్స్ ఉపయోగించడం అసాధ్యం. అంతేకాకుండా: చాలా మంది క్లయింట్‌లకు పర్యవేక్షణను ప్రదర్శించాల్సిన ప్రాజెక్ట్‌లో, ఇలాంటి సమస్యలు కనిపించవచ్చు మరియు కొలమానాల సర్వర్ ఓవర్‌లోడ్ అవుతుంది.

తీర్మానం

పొందిన అనుభవం నుండి చాలా ముఖ్యమైన ముగింపు ఏమిటంటే, మీరు తగినంత విశ్లేషణ లేకుండా తెలియని సాంకేతికతను ప్రాజెక్ట్‌లోకి తీసుకోలేరు. ఇన్‌ఫ్లక్స్‌డిబిని ప్రధాన డేటా స్టోర్‌గా ఎంచుకోకుండా ఉండటానికి గిథబ్‌లో ఓపెన్ ఇష్యూల యొక్క సాధారణ స్క్రీనింగ్ సమాచారాన్ని అందిస్తుంది.

నా ప్రాజెక్ట్ యొక్క పనులకు InfluxDB బాగా సరిపోయేలా ఉండాలి, కానీ ఆచరణలో చూపినట్లుగా, ఈ డేటాబేస్ అవసరాలను తీర్చలేదు మరియు చాలా బగ్‌లను కలిగి ఉంది.

ప్రాజెక్ట్ రిపోజిటరీలో మీరు ఇప్పటికే వెర్షన్ 2.0.0-బీటాను కనుగొనవచ్చు; రెండవ సంస్కరణలో గణనీయమైన మెరుగుదలలు ఉంటాయని మాత్రమే మేము ఆశిస్తున్నాము. ఈలోగా, నేను TimescaleDB డాక్యుమెంటేషన్‌ని అధ్యయనం చేస్తాను.

మూలం: www.habr.com