విక్టోరియామెట్రిక్స్‌లో ఆప్టిమైజేషన్‌లకు వెళ్లండి. అలెగ్జాండర్ వల్యాల్కిన్

అలెగ్జాండర్ వాల్యాల్కిన్ “గో ఆప్టిమైజేషన్స్ ఇన్ విక్టోరియామెట్రిక్స్” 2019 చివరి నివేదిక యొక్క ట్రాన్స్క్రిప్ట్ చదవమని నేను మీకు సూచిస్తున్నాను

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

ఈ నివేదిక యొక్క వీడియోకి లింక్ ఇక్కడ ఉంది - https://youtu.be/MZ5P21j_HLE

స్లయిడ్‌లు

మీ గురించి చెప్పండి. నేను అలెగ్జాండర్ వాలియాల్కిన్. ఇక్కడ నా GitHub ఖాతా. నేను గో మరియు పనితీరు ఆప్టిమైజేషన్ పట్ల మక్కువ కలిగి ఉన్నాను. నేను చాలా ఉపయోగకరమైన మరియు అంత ఉపయోగకరంగా లేని లైబ్రరీలను వ్రాసాను. అవి దేనితో ప్రారంభమవుతాయి fast, లేదా తో quick ఉపసర్గ.

నేను ప్రస్తుతం విక్టోరియామెట్రిక్స్‌లో పని చేస్తున్నాను. ఇది ఏమిటి మరియు నేను అక్కడ ఏమి చేస్తున్నాను? నేను ఈ ప్రదర్శనలో దీని గురించి మాట్లాడతాను.

నివేదిక యొక్క సారాంశం క్రింది విధంగా ఉంది:

• మొదట, విక్టోరియామెట్రిక్స్ అంటే ఏమిటో నేను మీకు చెప్తాను.
• అప్పుడు నేను మీకు సమయ శ్రేణి ఏమిటో చెబుతాను.
• టైమ్ సిరీస్ డేటాబేస్ ఎలా పనిచేస్తుందో నేను మీకు చెప్తాను.
• తరువాత, డేటాబేస్ ఆర్కిటెక్చర్ గురించి నేను మీకు చెప్తాను: అది ఏమి కలిగి ఉంటుంది.
• ఆపై విక్టోరియామెట్రిక్స్ కలిగి ఉన్న ఆప్టిమైజేషన్‌లకు వెళ్దాం. ఇది ఇన్‌వర్టెడ్ ఇండెక్స్‌కి ఆప్టిమైజేషన్ మరియు గోలో బిట్‌సెట్ ఇంప్లిమెంటేషన్ కోసం ఆప్టిమైజేషన్.

విక్టోరియామెట్రిక్స్ అంటే ఏమిటో ప్రేక్షకుల్లో ఎవరికైనా తెలుసా? వావ్, చాలా మందికి ఇప్పటికే తెలుసు. ఇది శుభవార్త. తెలియని వారికి, ఇది సమయ శ్రేణి డేటాబేస్. ఇది ClickHouse ఆర్కిటెక్చర్ ఆధారంగా, ClickHouse అమలుకు సంబంధించిన కొన్ని వివరాలపై ఆధారపడి ఉంటుంది. ఉదాహరణకు, ఇలాంటి వాటిపై: MergeTree, అందుబాటులో ఉన్న అన్ని ప్రాసెసర్ కోర్‌లపై సమాంతర గణన మరియు ప్రాసెసర్ కాష్‌లో ఉంచబడిన డేటా బ్లాక్‌లపై పని చేయడం ద్వారా పనితీరు ఆప్టిమైజేషన్.

VictoriaMetrics ఇతర సమయ శ్రేణి డేటాబేస్‌ల కంటే మెరుగైన డేటా కంప్రెషన్‌ను అందిస్తుంది.

ఇది నిలువుగా స్కేల్ అవుతుంది - అంటే, మీరు ఒక కంప్యూటర్‌లో మరిన్ని ప్రాసెసర్‌లు, ఎక్కువ RAMని జోడించవచ్చు. VictoriaMetrics ఈ అందుబాటులో ఉన్న వనరులను విజయవంతంగా ఉపయోగించుకుంటుంది మరియు సరళ ఉత్పాదకతను మెరుగుపరుస్తుంది.

VictoriaMetrics కూడా అడ్డంగా స్కేల్ చేస్తుంది - అంటే, మీరు VictoriaMetrics క్లస్టర్‌కు అదనపు నోడ్‌లను జోడించవచ్చు మరియు దాని పనితీరు దాదాపు సరళంగా పెరుగుతుంది.

మీరు ఊహించినట్లుగా, VictoriaMetrics వేగవంతమైన డేటాబేస్, ఎందుకంటే నేను ఇతరులను వ్రాయలేను. మరియు ఇది గోలో వ్రాయబడింది, కాబట్టి నేను ఈ సమావేశంలో దాని గురించి మాట్లాడుతున్నాను.

సమయ శ్రేణి అంటే ఏమిటో ఎవరికి తెలుసు? ఆయనకు కూడా చాలా మంది తెలుసు. సమయ శ్రేణి అనేది జంటల శ్రేణి (timestamp, значение), ఇక్కడ ఈ జంటలు సమయం ద్వారా క్రమబద్ధీకరించబడతాయి. విలువ ఫ్లోటింగ్ పాయింట్ సంఖ్య - float64.

ప్రతి సమయ శ్రేణి ప్రత్యేకంగా ఒక కీ ద్వారా గుర్తించబడుతుంది. ఈ కీ ఏమి కలిగి ఉంటుంది? ఇది కీ-విలువ జతల యొక్క నాన్-ఖాళీ సెట్‌ను కలిగి ఉంటుంది.

ఇక్కడ సమయ శ్రేణికి ఉదాహరణ. ఈ శ్రేణి యొక్క కీ జంటల జాబితా: __name__="cpu_usage" మెట్రిక్ పేరు, instance="my-server" - ఇది ఈ మెట్రిక్ సేకరించిన కంప్యూటర్, datacenter="us-east" - ఇది ఈ కంప్యూటర్ ఉన్న డేటా సెంటర్.

మేము మూడు కీలక-విలువ జతలతో కూడిన సమయ శ్రేణి పేరుతో ముగించాము. ఈ కీ జంటల జాబితాకు అనుగుణంగా ఉంటుంది (timestamp, value). t1, t3, t3, ..., tN - ఇవి సమయముద్రలు, 10, 20, 12, ..., 15 - సంబంధిత విలువలు. ఇచ్చిన శ్రేణికి ఇచ్చిన సమయంలో ఇది cpu-ఉపయోగం.

సమయ శ్రేణిని ఎక్కడ ఉపయోగించవచ్చు? ఎవరికైనా ఏమైనా ఆలోచన ఉందా?

• DevOpsలో, మీరు CPU, RAM, నెట్‌వర్క్, rps, ఎర్రర్‌ల సంఖ్య మొదలైనవాటిని కొలవవచ్చు.
• IoT - మనం ఉష్ణోగ్రత, పీడనం, జియో కోఆర్డినేట్‌లు మరియు మరేదైనా కొలవగలము.
• ఫైనాన్స్ కూడా - మేము అన్ని రకాల స్టాక్‌లు మరియు కరెన్సీల ధరలను పర్యవేక్షించగలము.
• అదనంగా, కర్మాగారాల్లో ఉత్పత్తి ప్రక్రియలను పర్యవేక్షించడంలో సమయ శ్రేణిని ఉపయోగించవచ్చు. రోబోట్‌ల కోసం విండ్ టర్బైన్‌లను పర్యవేక్షించడానికి VictoriaMetricsని ఉపయోగించే వినియోగదారులు మా వద్ద ఉన్నారు.
• వివిధ పరికరాల సెన్సార్ల నుండి సమాచారాన్ని సేకరించేందుకు సమయ శ్రేణి కూడా ఉపయోగపడుతుంది. ఉదాహరణకు, ఒక ఇంజిన్ కోసం; టైర్ ఒత్తిడిని కొలిచేందుకు; వేగం, దూరం కొలవడానికి; గ్యాసోలిన్ వినియోగాన్ని కొలిచేందుకు, మొదలైనవి.
• విమానాలను పర్యవేక్షించడానికి సమయ శ్రేణిని కూడా ఉపయోగించవచ్చు. ప్రతి విమానంలో బ్లాక్ బాక్స్ ఉంటుంది, ఇది విమానం యొక్క ఆరోగ్యానికి సంబంధించిన వివిధ పారామితుల కోసం సమయ శ్రేణిని సేకరిస్తుంది. ఏరోస్పేస్ పరిశ్రమలో కూడా సమయ శ్రేణిని ఉపయోగిస్తారు.
• ఆరోగ్య సంరక్షణ అంటే రక్తపోటు, పల్స్ మొదలైనవి.

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

మీకు టైమ్ సిరీస్ డేటాబేస్ ఎందుకు అవసరం? సమయ శ్రేణిని నిల్వ చేయడానికి మీరు సాధారణ రిలేషనల్ డేటాబేస్‌ను ఎందుకు ఉపయోగించలేరు?

ఎందుకంటే సమయ శ్రేణి సాధారణంగా పెద్ద మొత్తంలో సమాచారాన్ని కలిగి ఉంటుంది, ఇది సంప్రదాయ డేటాబేస్‌లలో నిల్వ చేయడం మరియు ప్రాసెస్ చేయడం కష్టం. అందువల్ల, సమయ శ్రేణి కోసం ప్రత్యేక డేటాబేస్లు కనిపించాయి. ఈ స్థావరాలు పాయింట్లను సమర్థవంతంగా నిల్వ చేస్తాయి (timestamp, value) ఇచ్చిన కీతో. వారు నిల్వ చేయబడిన డేటాను కీ ద్వారా, ఒకే కీ-విలువ జత లేదా బహుళ కీ-విలువ జతల ద్వారా లేదా regexp ద్వారా చదవడానికి APIని అందిస్తారు. ఉదాహరణకు, మీరు అమెరికాలోని డేటా సెంటర్‌లో మీ అన్ని సేవల యొక్క CPU లోడ్‌ను కనుగొనాలనుకుంటున్నారు, అప్పుడు మీరు ఈ నకిలీ ప్రశ్నను ఉపయోగించాలి.

సాధారణంగా సమయ శ్రేణి డేటాబేస్‌లు ప్రత్యేక ప్రశ్న భాషలను అందిస్తాయి ఎందుకంటే సమయ శ్రేణి SQL బాగా సరిపోదు. SQLకి మద్దతు ఇచ్చే డేటాబేస్‌లు ఉన్నప్పటికీ, ఇది చాలా సరిఅయినది కాదు. వంటి భాషలను ప్రశ్నించండి PromQL, InfluxQL, ప్రవాహం, Q. ఎవరైనా ఈ భాషల్లో కనీసం ఒక్కటైనా విన్నారని నేను ఆశిస్తున్నాను. PromQL గురించి చాలా మంది బహుశా విన్నారు. ఇది ప్రోమేతియస్ ప్రశ్న భాష.

విక్టోరియామెట్రిక్స్‌ని ఉదాహరణగా ఉపయోగించి ఆధునిక సమయ శ్రేణి డేటాబేస్ ఆర్కిటెక్చర్ ఇలా కనిపిస్తుంది.

ఇది రెండు భాగాలను కలిగి ఉంటుంది. ఇది విలోమ సూచిక కోసం నిల్వ మరియు సమయ శ్రేణి విలువల కోసం నిల్వ. ఈ రిపోజిటరీలు వేరు చేయబడ్డాయి.

డేటాబేస్‌లో కొత్త రికార్డ్ వచ్చినప్పుడు, ఇవ్వబడిన సెట్ కోసం సమయ శ్రేణి ఐడెంటిఫైయర్‌ను కనుగొనడానికి మేము ముందుగా విలోమ సూచికను యాక్సెస్ చేస్తాము label=value ఇచ్చిన మెట్రిక్ కోసం. మేము ఈ ఐడెంటిఫైయర్‌ని కనుగొని, డేటా స్టోర్‌లో విలువను సేవ్ చేస్తాము.

TSDB నుండి డేటాను తిరిగి పొందడానికి అభ్యర్థన వచ్చినప్పుడు, మేము మొదట విలోమ సూచికకు వెళ్తాము. అన్నీ పొందుదాం timeseries_ids ఈ సెట్‌కు సరిపోయే రికార్డులు label=value. ఆపై మేము డేటా గిడ్డంగి నుండి ఇండెక్స్ చేయబడిన అన్ని అవసరమైన డేటాను పొందుతాము timeseries_ids.

ఇన్‌కమింగ్ సెలెక్ట్ క్వెరీని టైమ్ సిరీస్ డేటాబేస్ ఎలా ప్రాసెస్ చేస్తుందో ఉదాహరణ చూద్దాం.

• అన్నింటిలో మొదటిది, ఆమె ప్రతిదీ పొందుతుంది timeseries_ids ఇచ్చిన జతలను కలిగి ఉన్న విలోమ సూచిక నుండి label=value, లేదా ఇచ్చిన సాధారణ వ్యక్తీకరణను సంతృప్తిపరచండి.
• ఆ తర్వాత అది డేటా స్టోరేజ్ నుండి దొరికిన వాటి కోసం ఇచ్చిన సమయ వ్యవధిలో అన్ని డేటా పాయింట్లను తిరిగి పొందుతుంది timeseries_ids.
• దీని తరువాత, వినియోగదారు అభ్యర్థన ప్రకారం, డేటాబేస్ ఈ డేటా పాయింట్లపై కొన్ని గణనలను నిర్వహిస్తుంది. మరియు ఆ తర్వాత అది సమాధానాన్ని తిరిగి ఇస్తుంది.

ఈ ప్రదర్శనలో నేను మొదటి భాగం గురించి మీకు చెప్తాను. ఇది ఒక శోధన timeseries_ids విలోమ సూచిక ద్వారా. మీరు రెండవ భాగం మరియు మూడవ భాగం గురించి తర్వాత చూడవచ్చు విక్టోరియామెట్రిక్స్ మూలాలు, లేదా నేను ఇతర నివేదికలను సిద్ధం చేసే వరకు వేచి ఉండండి :)

విలోమ సూచికకు వెళ్దాం. ఇది చాలా సులభం అని చాలామంది అనుకోవచ్చు. విలోమ సూచిక అంటే ఏమిటో మరియు అది ఎలా పని చేస్తుందో ఎవరికి తెలుసు? ఓహ్, ఇప్పుడు చాలా మంది లేరు. అది ఏమిటో అర్థం చేసుకోవడానికి ప్రయత్నిద్దాం.

ఇది నిజానికి సులభం. ఇది కేవలం ఒక విలువకు కీని మ్యాప్ చేసే నిఘంటువు. కీ అంటే ఏమిటి? ఈ జంట label=valueపేరు label и value - ఇవి పంక్తులు. మరియు విలువలు ఒక సెట్ timeseries_ids, ఇచ్చిన జతను కలిగి ఉంటుంది label=value.

విలోమ సూచిక మీరు త్వరగా ప్రతిదీ కనుగొనేందుకు అనుమతిస్తుంది timeseries_ids, ఇచ్చినవి label=value.

ఇది త్వరగా కనుగొనడానికి కూడా మిమ్మల్ని అనుమతిస్తుంది timeseries_ids అనేక జతల కోసం సమయ శ్రేణి label=value, లేదా జంటల కోసం label=regexp. ఇది ఎలా జరుగుతుంది? సెట్ యొక్క ఖండనను కనుగొనడం ద్వారా timeseries_ids ప్రతి జత కోసం label=value.

విలోమ సూచిక యొక్క వివిధ అమలులను చూద్దాం. సరళమైన అమాయక అమలుతో ప్రారంభిద్దాం. ఆమె ఇలా కనిపిస్తుంది.

ఫంక్షన్ getMetricIDs తీగల జాబితాను పొందుతుంది. ప్రతి లైన్ కలిగి ఉంటుంది label=value. ఈ ఫంక్షన్ జాబితాను అందిస్తుంది metricIDs.

అది ఎలా పని చేస్తుంది? ఇక్కడ మనకు గ్లోబల్ వేరియబుల్ అనే పేరు ఉంది invertedIndex. ఇది సాధారణ నిఘంటువు (map), ఇది స్ట్రింగ్‌ను స్లైస్ ఇంట్‌లకు మ్యాప్ చేస్తుంది. లైన్ కలిగి ఉంది label=value.

ఫంక్షన్ అమలు: పొందండి metricIDs తొలిసారి label=value, అప్పుడు మేము అన్నిటికీ వెళ్తాము label=value, మేము దానిని పొందుతాము metricIDs వారి కోసం. మరియు ఫంక్షన్ కాల్ intersectInts, ఇది క్రింద చర్చించబడుతుంది. మరియు ఈ ఫంక్షన్ ఈ జాబితాల ఖండనను తిరిగి ఇస్తుంది.

మీరు గమనిస్తే, విలోమ సూచికను అమలు చేయడం చాలా క్లిష్టంగా లేదు. కానీ ఇది అమాయకమైన అమలు. దానికి ఎలాంటి ప్రతికూలతలు ఉన్నాయి? అమాయక అమలు యొక్క ప్రధాన ప్రతికూలత ఏమిటంటే, అటువంటి విలోమ సూచిక RAMలో నిల్వ చేయబడుతుంది. అప్లికేషన్‌ను పునఃప్రారంభించిన తర్వాత మేము ఈ సూచికను కోల్పోతాము. ఈ సూచికను డిస్క్‌లో సేవ్ చేయడం లేదు. అటువంటి విలోమ సూచిక డేటాబేస్కు తగినది కాదు.

రెండవ లోపం కూడా జ్ఞాపకశక్తికి సంబంధించినది. విలోమ సూచిక తప్పనిసరిగా RAMకి సరిపోతుంది. ఇది RAM యొక్క పరిమాణాన్ని మించి ఉంటే, అప్పుడు స్పష్టంగా మనం పొందుతాము - మెమరీ లోపం నుండి బయటపడింది. మరియు ప్రోగ్రామ్ పనిచేయదు.

వంటి రెడీమేడ్ పరిష్కారాలను ఉపయోగించి ఈ సమస్యను పరిష్కరించవచ్చు లెవల్‌డిబి, లేదా రాక్స్ డిబి.

సంక్షిప్తంగా, మాకు మూడు కార్యకలాపాలను త్వరగా చేయడానికి అనుమతించే డేటాబేస్ అవసరం.

• మొదటి ఆపరేషన్ రికార్డింగ్ ключ-значение ఈ డేటాబేస్కు. ఆమె దీన్ని చాలా త్వరగా చేస్తుంది, ఎక్కడ ключ-значение ఏకపక్ష తీగలు.
• రెండవ ఆపరేషన్ ఇచ్చిన కీని ఉపయోగించి విలువ కోసం శీఘ్ర శోధన.
• మరియు మూడవ ఆపరేషన్ ఇచ్చిన ఉపసర్గ ద్వారా అన్ని విలువల కోసం శీఘ్ర శోధన.

LevelDB మరియు RocksDB - ఈ డేటాబేస్‌లను Google మరియు Facebook అభివృద్ధి చేశాయి. మొదట LevelDB వచ్చింది. అప్పుడు ఫేస్‌బుక్‌లోని కుర్రాళ్ళు లెవెల్‌డిబిని తీసుకొని దాన్ని మెరుగుపరచడం ప్రారంభించారు, వారు రాక్స్‌డిబిని తయారు చేశారు. ఇప్పుడు దాదాపు అన్ని అంతర్గత డేటాబేస్‌లు Facebook లోపల RocksDBలో పని చేస్తాయి, వీటిలో RocksDB మరియు MySQLకి బదిలీ చేయబడ్డాయి. వారు అతనికి పేరు పెట్టారు MyRocks.

లెవెల్‌డిబిని ఉపయోగించి విలోమ సూచికను అమలు చేయవచ్చు. ఇది ఎలా చెయ్యాలి? మేము కీగా సేవ్ చేస్తాము label=value. మరియు విలువ అనేది జత ఉన్న సమయ శ్రేణి యొక్క ఐడెంటిఫైయర్ label=value.

ఇచ్చిన జతతో మనకు చాలా సమయ శ్రేణి ఉంటే label=value, అప్పుడు ఈ డేటాబేస్‌లో ఒకే కీ మరియు విభిన్నమైన అనేక వరుసలు ఉంటాయి timeseries_ids. అందరి జాబితాను పొందడానికి timeseries_ids, దీనితో మొదలవుతుంది label=prefix, ఈ డేటాబేస్ ఆప్టిమైజ్ చేయబడిన పరిధిని స్కాన్ చేస్తాము. అంటే, మేము ప్రారంభమయ్యే అన్ని పంక్తులను ఎంచుకుంటాము label=prefix మరియు అవసరమైన వాటిని పొందండి timeseries_ids.

Goలో ఇది ఎలా ఉంటుందో దాని నమూనా అమలు ఇక్కడ ఉంది. మాకు విలోమ సూచిక ఉంది. ఇది LevelDB.

అమాయకమైన అమలు కోసం ఫంక్షన్ అదే. ఇది దాదాపు పంక్తి ద్వారా అమాయక అమలును పునరావృతం చేస్తుంది. తిరుగు బదులు మాత్రమే పాయింట్ map మేము విలోమ సూచికను యాక్సెస్ చేస్తాము. మేము మొదటిదానికి అన్ని విలువలను పొందుతాము label=value. అప్పుడు మేము మిగిలిన అన్ని జతల ద్వారా వెళ్తాము label=value మరియు వాటికి సంబంధించిన మెట్రిక్‌ఐడి సెట్‌లను పొందండి. అప్పుడు మేము ఖండనను కనుగొంటాము.

ప్రతిదీ బాగానే ఉన్నట్లు అనిపిస్తుంది, కానీ ఈ పరిష్కారానికి లోపాలు ఉన్నాయి. VictoriaMetrics ప్రారంభంలో LevelDB ఆధారంగా విలోమ సూచికను అమలు చేసింది. కానీ చివరికి నేను వదులుకోవలసి వచ్చింది.

ఎందుకు? ఎందుకంటే LevelDB అమాయకమైన అమలు కంటే నెమ్మదిగా ఉంటుంది. అమాయకమైన అమలులో, ఇచ్చిన కీని అందించినప్పుడు, మేము వెంటనే మొత్తం స్లైస్‌ను తిరిగి పొందుతాము metricIDs. ఇది చాలా వేగవంతమైన ఆపరేషన్ - మొత్తం స్లైస్ ఉపయోగం కోసం సిద్ధంగా ఉంది.

LevelDBలో, ప్రతిసారీ ఒక ఫంక్షన్ అంటారు GetValues మీరు ప్రారంభించే అన్ని పంక్తుల ద్వారా వెళ్లాలి label=value. మరియు ప్రతి పంక్తికి విలువను పొందండి timeseries_ids. అటువంటి timeseries_ids వీటిలో ఒక ముక్కను సేకరించండి timeseries_ids. సహజంగానే, ఇది సాధారణ మ్యాప్‌ను కీ ద్వారా యాక్సెస్ చేయడం కంటే చాలా నెమ్మదిగా ఉంటుంది.

రెండవ లోపం ఏమిటంటే LevelDB Cలో వ్రాయబడింది. గో నుండి C ఫంక్షన్‌లను కాల్ చేయడం చాలా వేగంగా లేదు. దీనికి వందల కొద్దీ నానోసెకన్లు పడుతుంది. ఇది చాలా వేగంగా లేదు, ఎందుకంటే గోలో వ్రాసిన సాధారణ ఫంక్షన్ కాల్‌తో పోలిస్తే, ఇది 1-5 నానోసెకన్లు పడుతుంది, పనితీరులో వ్యత్యాసం పదుల రెట్లు ఉంటుంది. విక్టోరియామెట్రిక్స్ కోసం ఇది ఒక ఘోరమైన లోపం :)

కాబట్టి నేను విలోమ సూచిక యొక్క నా స్వంత అమలును వ్రాసాను. మరియు అతను ఆమెను పిలిచాడు విలీనం.

Mergeset అనేది MergeTree డేటా నిర్మాణంపై ఆధారపడి ఉంటుంది. ఈ డేటా నిర్మాణం ClickHouse నుండి తీసుకోబడింది. సహజంగానే, వేగవంతమైన శోధన కోసం మెర్జెసెట్ ఆప్టిమైజ్ చేయబడాలి timeseries_ids ఇచ్చిన కీ ప్రకారం. మెర్జెసెట్ పూర్తిగా గోలో వ్రాయబడింది. మీరు చూడగలరు GitHubలో VictoriaMetrics మూలాలు. విలీనం యొక్క అమలు ఫోల్డర్‌లో ఉంది /lib/mergeset. మీరు అక్కడ ఏమి జరుగుతుందో గుర్తించడానికి ప్రయత్నించవచ్చు.

విలీనం API LevelDB మరియు RocksDBలకు చాలా పోలి ఉంటుంది. అంటే, అక్కడ కొత్త రికార్డులను త్వరగా సేవ్ చేయడానికి మరియు ఇచ్చిన ప్రిఫిక్స్ ద్వారా రికార్డులను త్వరగా ఎంచుకోవడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.

మేము విలీనం యొక్క ప్రతికూలతల గురించి తరువాత మాట్లాడుతాము. విలోమ సూచికను అమలు చేసేటప్పుడు ఉత్పత్తిలో విక్టోరియామెట్రిక్స్‌తో ఏ సమస్యలు తలెత్తాయో ఇప్పుడు మాట్లాడుదాం.

అవి ఎందుకు తలెత్తాయి?

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

రెండవ కారణం పెద్ద సంఖ్యలో సమయ శ్రేణులు. ప్రారంభంలో, పర్యవేక్షణ జనాదరణ పొందుతున్నప్పుడు, సమయ శ్రేణుల సంఖ్య తక్కువగా ఉండేది. ఉదాహరణకు, ప్రతి కంప్యూటర్ కోసం మీరు CPU, మెమరీ, నెట్‌వర్క్ మరియు డిస్క్ లోడ్‌ను పర్యవేక్షించాలి. కంప్యూటర్‌కు 4 సమయ శ్రేణి. మీ వద్ద 100 కంప్యూటర్లు మరియు 400 టైమ్ సిరీస్‌లు ఉన్నాయని అనుకుందాం. ఇది చాలా తక్కువ.

కాలక్రమేణా, ప్రజలు మరింత కణిక సమాచారాన్ని కొలవగలరని కనుగొన్నారు. ఉదాహరణకు, మొత్తం ప్రాసెసర్ యొక్క లోడ్‌ను కొలవదు, కానీ ప్రతి ప్రాసెసర్ కోర్ విడిగా. మీకు 40 ప్రాసెసర్ కోర్లు ఉంటే, ప్రాసెసర్ లోడ్‌ను కొలవడానికి మీకు 40 రెట్లు ఎక్కువ సమయ శ్రేణి ఉంటుంది.

అయితే అదంతా కాదు. ప్రతి ప్రాసెసర్ కోర్ నిష్క్రియంగా ఉన్నప్పుడు నిష్క్రియ వంటి అనేక స్థితులను కలిగి ఉంటుంది. మరియు వినియోగదారు స్థలంలో పని చేయండి, కెర్నల్ స్థలం మరియు ఇతర రాష్ట్రాల్లో పని చేయండి. మరియు అటువంటి ప్రతి స్థితిని ప్రత్యేక సమయ శ్రేణిగా కూడా కొలవవచ్చు. ఇది అదనంగా వరుసల సంఖ్యను 7-8 సార్లు పెంచుతుంది.

ఒక మెట్రిక్ నుండి మేము కేవలం ఒక కంప్యూటర్ కోసం 40 x 8 = 320 మెట్రిక్‌లను పొందాము. 100తో గుణిస్తే, మనకు 32కి బదులుగా 000 వస్తుంది.

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

అధిక చూర్ణం రేటును నిశితంగా పరిశీలిద్దాం. ఉత్పత్తిలో అధిక చర్న్ రేటుకు కారణమేమిటి? ఎందుకంటే లేబుల్స్ మరియు ట్యాగ్‌ల యొక్క కొన్ని అర్థాలు నిరంతరం మారుతూ ఉంటాయి.

ఉదాహరణకు, భావనను కలిగి ఉన్న కుబెర్నెట్స్‌ను తీసుకోండి deployment, అంటే మీ అప్లికేషన్ యొక్క కొత్త వెర్షన్ అందుబాటులోకి వచ్చినప్పుడు. కొన్ని కారణాల వల్ల, కుబెర్నెట్స్ డెవలపర్‌లు లేబుల్‌కి డిప్లాయ్‌మెంట్ ఐడిని జోడించాలని నిర్ణయించుకున్నారు.

ఇది దేనికి దారి తీసింది? అంతేకాకుండా, ప్రతి కొత్త విస్తరణతో, అన్ని పాత సమయ శ్రేణికి అంతరాయం ఏర్పడుతుంది మరియు వాటికి బదులుగా, కొత్త సమయ శ్రేణి కొత్త లేబుల్ విలువతో ప్రారంభమవుతుంది deployment_id. అటువంటి వరుసలు వందల వేల మరియు మిలియన్ల కూడా ఉండవచ్చు.

వీటన్నింటిలో ముఖ్యమైన విషయం ఏమిటంటే, మొత్తం సమయ శ్రేణి సంఖ్య పెరుగుతుంది, అయితే ప్రస్తుతం సక్రియంగా ఉన్న మరియు డేటాను స్వీకరించే సమయ శ్రేణి సంఖ్య స్థిరంగా ఉంటుంది. ఈ స్థితిని హై చర్న్ రేట్ అంటారు.

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

ఈ సమస్యను ఎలా పరిష్కరించాలి? ఇక్కడ మొదటి ఎంపిక ఉంది. ఇది విలోమ సూచికను కాలక్రమేణా స్వతంత్ర భాగాలుగా విభజించడం. అంటే, కొంత సమయం విరామం గడిచిపోతుంది, మేము ప్రస్తుత విలోమ సూచికతో పనిని పూర్తి చేస్తాము. మరియు కొత్త విలోమ సూచికను సృష్టించండి. మరొక సమయ విరామం గడిచిపోతుంది, మేము మరొకటి మరియు మరొకదాన్ని సృష్టిస్తాము.

మరియు ఈ విలోమ సూచికల నుండి నమూనా చేసినప్పుడు, మేము ఇచ్చిన విరామంలో వచ్చే విలోమ సూచికల సమితిని కనుగొంటాము. మరియు, తదనుగుణంగా, మేము అక్కడ నుండి సమయ శ్రేణి యొక్క ఐడిని ఎంచుకుంటాము.

ఇది వనరులను ఆదా చేస్తుంది ఎందుకంటే మేము ఇచ్చిన విరామంలో రాని భాగాలను చూడవలసిన అవసరం లేదు. అంటే, సాధారణంగా, మేము చివరి గంటకు డేటాను ఎంచుకుంటే, మునుపటి సమయ వ్యవధిలో మేము అభ్యర్థనలను దాటవేస్తాము.

ఈ సమస్యను పరిష్కరించడానికి మరొక ఎంపిక ఉంది. ఇది ప్రతి రోజు కోసం ఆ రోజు సంభవించిన సమయ శ్రేణి యొక్క ప్రత్యేక జాబితాను నిల్వ చేయడం.

మునుపటి పరిష్కారం కంటే ఈ పరిష్కారం యొక్క ప్రయోజనం ఏమిటంటే, కాలక్రమేణా అదృశ్యం కాని సమయ శ్రేణి సమాచారాన్ని మేము నకిలీ చేయము. అవి నిరంతరం ఉంటాయి మరియు మారవు.

ప్రతికూలత ఏమిటంటే, అటువంటి పరిష్కారం అమలు చేయడం చాలా కష్టం మరియు డీబగ్ చేయడం చాలా కష్టం. మరియు VictoriaMetrics ఈ పరిష్కారాన్ని ఎంచుకుంది. చారిత్రాత్మకంగా ఇలా జరిగింది. మునుపటి దానితో పోలిస్తే ఈ పరిష్కారం కూడా బాగా పనిచేస్తుంది. ఎందుకంటే మారని, అంటే కాలక్రమేణా అదృశ్యం కాని సమయ శ్రేణి కోసం ప్రతి విభజనలో డేటాను నకిలీ చేయడం అవసరం అనే వాస్తవం కారణంగా ఈ పరిష్కారం అమలు చేయబడలేదు. VictoriaMetrics ప్రధానంగా డిస్క్ స్పేస్ వినియోగం కోసం ఆప్టిమైజ్ చేయబడింది మరియు మునుపటి అమలు డిస్క్ స్పేస్ వినియోగాన్ని అధ్వాన్నంగా చేసింది. కానీ డిస్క్ స్పేస్ వినియోగాన్ని తగ్గించడానికి ఈ అమలు బాగా సరిపోతుంది, కాబట్టి ఇది ఎంపిక చేయబడింది.

నేను ఆమెతో పోరాడవలసి వచ్చింది. పోరాటం ఏమిటంటే, ఈ అమలులో మీరు ఇంకా చాలా పెద్ద సంఖ్యను ఎంచుకోవాలి timeseries_ids విలోమ సూచిక సమయం విభజించబడినప్పుడు కంటే డేటా కోసం.

మేము ఈ సమస్యను ఎలా పరిష్కరించాము? మేము దానిని అసలైన మార్గంలో పరిష్కరించాము - ప్రతి విలోమ సూచిక నమోదులో ఒక ఐడెంటిఫైయర్‌కు బదులుగా అనేక సమయ శ్రేణి ఐడెంటిఫైయర్‌లను నిల్వ చేయడం ద్వారా. అంటే మన దగ్గర ఒక కీ ఉంది label=value, ఇది ప్రతి సమయ శ్రేణిలో సంభవిస్తుంది. మరియు ఇప్పుడు మేము అనేక సేవ్ timeseries_ids ఒక ఎంట్రీలో.

ఇక్కడ ఒక ఉదాహరణ. ఇంతకుముందు మనకు N ఎంట్రీలు ఉన్నాయి, కానీ ఇప్పుడు మనకు ఒక ఎంట్రీ ఉంది, దీని ఉపసర్గ అన్నింటిలాగే ఉంటుంది. మునుపటి నమోదు కోసం, విలువ అన్ని సమయ శ్రేణి ఐడిలను కలిగి ఉంటుంది.

ఇది అటువంటి విలోమ సూచిక యొక్క స్కానింగ్ వేగాన్ని 10 రెట్లు పెంచడం సాధ్యం చేసింది. మరియు ఇది కాష్ కోసం మెమరీ వినియోగాన్ని తగ్గించడానికి మాకు అనుమతి ఇచ్చింది, ఎందుకంటే ఇప్పుడు మేము స్ట్రింగ్‌ను నిల్వ చేస్తాము label=value N సార్లు కలిసి కాష్‌లో ఒక్కసారి మాత్రమే. మరియు మీరు మీ ట్యాగ్‌లు మరియు లేబుల్‌లలో పొడవాటి లైన్‌లను నిల్వ చేస్తే, ఈ లైన్ పెద్దదిగా ఉంటుంది, వీటిని కుబెర్నెట్స్ అక్కడ తరలించడానికి ఇష్టపడతారు.

విలోమ సూచికలో శోధనను వేగవంతం చేయడానికి మరొక ఎంపిక షార్డింగ్. ఒకదానికి బదులుగా అనేక విలోమ సూచికలను సృష్టించడం మరియు కీ ద్వారా వాటి మధ్య డేటాను పంచుకోవడం. ఇది ఒక సెట్ key=value ఆవిరి. అంటే, మేము అనేక స్వతంత్ర విలోమ సూచికలను పొందుతాము, వీటిని మేము అనేక ప్రాసెసర్లలో సమాంతరంగా ప్రశ్నించవచ్చు. మునుపటి అమలులు సింగిల్-ప్రాసెసర్ మోడ్‌లో మాత్రమే ఆపరేషన్‌ను అనుమతించాయి, అనగా, కేవలం ఒక కోర్‌లో డేటాను స్కాన్ చేస్తుంది. ఈ పరిష్కారం క్లిక్‌హౌస్ చేయాలనుకుంటున్నట్లుగా, ఒకేసారి అనేక కోర్లలో డేటాను స్కాన్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. ఇది మేము అమలు చేయడానికి ప్లాన్ చేస్తున్నాము.

ఇప్పుడు మన గొర్రెలకు - ఖండన ఫంక్షన్‌కి తిరిగి వెళ్దాం timeseries_ids. ఎలాంటి అమలులు ఉండవచ్చో పరిశీలిద్దాం. ఈ ఫంక్షన్ మిమ్మల్ని కనుగొనడానికి అనుమతిస్తుంది timeseries_ids ఇచ్చిన సెట్ కోసం label=value.

మొదటి ఎంపిక అమాయక అమలు. రెండు సమూహ ఉచ్చులు. ఇక్కడ మనకు ఫంక్షన్ ఇన్‌పుట్ వస్తుంది intersectInts రెండు ముక్కలు - a и b. అవుట్‌పుట్ వద్ద, అది ఈ ముక్కల ఖండనను మాకు తిరిగి ఇవ్వాలి.

అమాయకమైన అమలు ఇలా కనిపిస్తుంది. మేము స్లైస్ నుండి అన్ని విలువలను పునరావృతం చేస్తాము a, ఈ లూప్ లోపల మనం స్లైస్ యొక్క అన్ని విలువల ద్వారా వెళ్తాము b. మరియు మేము వాటిని పోల్చాము. అవి సరిపోలితే, మేము ఒక ఖండనను కనుగొన్నాము. మరియు దానిని సేవ్ చేయండి result.

నష్టాలు ఏమిటి? క్వాడ్రాటిక్ సంక్లిష్టత దాని ప్రధాన లోపం. ఉదాహరణకు, మీ కొలతలు ముక్కలుగా ఉంటే a и b ఒకేసారి ఒక మిలియన్, అప్పుడు ఈ ఫంక్షన్ మీకు ఎప్పటికీ సమాధానం ఇవ్వదు. ఎందుకంటే ఇది ఒక ట్రిలియన్ పునరావృత్తులు చేయవలసి ఉంటుంది, ఇది ఆధునిక కంప్యూటర్‌లకు కూడా చాలా ఎక్కువ.

రెండవ అమలు మ్యాప్ ఆధారంగా ఉంటుంది. మేము మ్యాప్‌ని సృష్టిస్తాము. మేము స్లైస్ నుండి అన్ని విలువలను ఈ మ్యాప్‌లో ఉంచాము a. అప్పుడు మేము ఒక ప్రత్యేక లూప్లో స్లైస్ ద్వారా వెళ్తాము b. మరియు ఈ విలువ స్లైస్ నుండి ఉందో లేదో తనిఖీ చేస్తాము b మ్యాప్‌లో. అది ఉనికిలో ఉంటే, దానిని ఫలితానికి జోడించండి.

ప్రయోజనాలు ఏమిటి? ప్రయోజనం ఏమిటంటే సరళ సంక్లిష్టత మాత్రమే ఉంది. అంటే, పెద్ద ముక్కల కోసం ఫంక్షన్ చాలా వేగంగా అమలు అవుతుంది. మిలియన్-పరిమాణ స్లైస్ కోసం, ఈ ఫంక్షన్ మునుపటి ఫంక్షన్ యొక్క ట్రిలియన్ పునరావృతాలకు విరుద్ధంగా 2 మిలియన్ పునరావృతాలలో అమలు చేయబడుతుంది.

ప్రతికూలత ఏమిటంటే, ఈ మ్యాప్‌ని రూపొందించడానికి ఈ ఫంక్షన్‌కు ఎక్కువ మెమరీ అవసరం.

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

ఈ ప్రదేశాలలో CPU సమయం ఎందుకు వృధా అవుతుంది? ఎందుకంటే గో ఈ లైన్లలో హ్యాషింగ్ ఆపరేషన్ చేస్తుంది. అంటే, ఇది HashMapలో ఇచ్చిన ఇండెక్స్ వద్ద దాన్ని యాక్సెస్ చేయడానికి కీ యొక్క హాష్‌ను గణిస్తుంది. హాష్ లెక్కింపు ఆపరేషన్ పదుల నానోసెకన్లలో పూర్తవుతుంది. ఇది VictoriaMetricsకి నెమ్మదిగా ఉంది.

నేను ఈ సందర్భంలో ప్రత్యేకంగా ఆప్టిమైజ్ చేసిన బిట్‌సెట్‌ని అమలు చేయాలని నిర్ణయించుకున్నాను. ఇప్పుడు రెండు ముక్కల ఖండన ఇలా కనిపిస్తుంది. ఇక్కడ మనం బిట్‌సెట్‌ని క్రియేట్ చేస్తాము. మేము దానికి మొదటి స్లైస్ నుండి మూలకాలను జోడిస్తాము. అప్పుడు మేము రెండవ స్లైస్లో ఈ మూలకాల ఉనికిని తనిఖీ చేస్తాము. మరియు వాటిని ఫలితానికి జోడించండి. అంటే, ఇది మునుపటి ఉదాహరణ నుండి దాదాపు భిన్నంగా లేదు. ఇక్కడ ఉన్న ఏకైక విషయం ఏమిటంటే, మేము మ్యాప్‌కి ప్రాప్యతను అనుకూల ఫంక్షన్‌లతో భర్తీ చేసాము add и has.

మొదటి చూపులో, ఇంతకుముందు అక్కడ ప్రామాణిక మ్యాప్‌ని ఉపయోగించినట్లయితే, ఇది నెమ్మదిగా పని చేస్తుందని అనిపిస్తుంది, ఆపై కొన్ని ఇతర ఫంక్షన్లను పిలుస్తారు, అయితే విక్టోరియామెట్రిక్స్ విషయంలో ప్రామాణిక మ్యాప్ కంటే ఈ విషయం 10 రెట్లు వేగంగా పనిచేస్తుందని ప్రొఫైలింగ్ చూపిస్తుంది.

అదనంగా, ఇది మ్యాప్ అమలుతో పోలిస్తే చాలా తక్కువ మెమరీని ఉపయోగిస్తుంది. ఎందుకంటే మేము ఎనిమిది-బైట్ విలువలకు బదులుగా బిట్‌లను ఇక్కడ నిల్వ చేస్తున్నాము.

ఈ అమలు యొక్క ప్రతికూలత ఏమిటంటే ఇది అంత స్పష్టంగా లేదు, అల్పమైనది కాదు.

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

ఈ నిర్మాణం యొక్క అమలును పరిశీలిద్దాం. మీరు చూడాలనుకుంటే, అది VictoriaMetrics మూలాల్లో, ఫోల్డర్‌లో ఉంది lib/uint64set. ఇది విక్టోరియామెట్రిక్స్ కేసు కోసం ప్రత్యేకంగా ఆప్టిమైజ్ చేయబడింది timeseries_id అనేది 64-బిట్ విలువ, ఇక్కడ మొదటి 32 బిట్‌లు ప్రాథమికంగా స్థిరంగా ఉంటాయి మరియు చివరి 32 బిట్‌లు మాత్రమే మారతాయి.

ఈ డేటా నిర్మాణం డిస్క్‌లో నిల్వ చేయబడదు, ఇది మెమరీలో మాత్రమే పనిచేస్తుంది.

ఇక్కడ దాని API ఉంది. ఇది చాలా క్లిష్టంగా లేదు. API ప్రత్యేకంగా VictoriaMetricsని ఉపయోగించడం యొక్క నిర్దిష్ట ఉదాహరణకి అనుగుణంగా రూపొందించబడింది. అంటే, ఇక్కడ అనవసరమైన విధులు లేవు. విక్టోరియామెట్రిక్స్ ద్వారా స్పష్టంగా ఉపయోగించే విధులు ఇక్కడ ఉన్నాయి.

విధులు ఉన్నాయి add, ఇది కొత్త విలువలను జోడిస్తుంది. ఒక ఫంక్షన్ ఉంది has, ఇది కొత్త విలువల కోసం తనిఖీ చేస్తుంది. మరియు ఒక ఫంక్షన్ ఉంది del, ఇది విలువలను తొలగిస్తుంది. సహాయక ఫంక్షన్ ఉంది len, ఇది సెట్ పరిమాణాన్ని అందిస్తుంది. ఫంక్షన్ clone చాలా క్లోన్ చేస్తుంది. మరియు ఫంక్షన్ appendto ఈ సెట్‌ని స్లైస్‌గా మారుస్తుంది timeseries_ids.

ఈ డేటా నిర్మాణం యొక్క అమలు ఇలా కనిపిస్తుంది. సెట్లో రెండు అంశాలు ఉన్నాయి:

• ItemsCount సెట్‌లోని మూలకాల సంఖ్యను త్వరగా అందించడానికి సహాయక ఫీల్డ్. ఈ సహాయక ఫీల్డ్ లేకుండా చేయడం సాధ్యమవుతుంది, కానీ విక్టోరియామెట్రిక్స్ తరచుగా దాని అల్గారిథమ్‌లలో బిట్‌సెట్ పొడవును ప్రశ్నిస్తుంది కాబట్టి దీన్ని ఇక్కడ జోడించాల్సి వచ్చింది.

• రెండవ క్షేత్రం buckets. ఇది నిర్మాణం నుండి స్లైస్ bucket32. ప్రతి నిర్మాణం నిల్వ చేస్తుంది hi ఫీల్డ్. ఇవి ఎగువ 32 బిట్‌లు. మరియు రెండు ముక్కలు - b16his и buckets నుండి bucket16 నిర్మాణాలు.

16-బిట్ నిర్మాణం యొక్క రెండవ భాగం యొక్క టాప్ 64 బిట్‌లు ఇక్కడ నిల్వ చేయబడతాయి. మరియు ఇక్కడ బిట్‌సెట్‌లు ప్రతి బైట్‌లోని దిగువ 16 బిట్‌ల కోసం నిల్వ చేయబడతాయి.

Bucket64 శ్రేణిని కలిగి ఉంటుంది uint64. ఈ స్థిరాంకాలను ఉపయోగించి పొడవు లెక్కించబడుతుంది. ఒకదానిలో bucket16 గరిష్టంగా నిల్వ చేయవచ్చు 2^16=65536 బిట్. మీరు దీన్ని 8తో భాగిస్తే, అది 8 కిలోబైట్లు. మళ్లీ 8తో భాగిస్తే 1000 అవుతుంది uint64 అర్థం. అంటే Bucket16 - ఇది మా 8-కిలోబైట్ నిర్మాణం.

కొత్త విలువను జోడించడం కోసం ఈ నిర్మాణం యొక్క పద్ధతుల్లో ఒకటి ఎలా అమలు చేయబడుతుందో చూద్దాం.

ఇది అన్ని మొదలవుతుంది uint64 అర్థాలు. మేము ఎగువ 32 బిట్లను లెక్కిస్తాము, మేము దిగువ 32 బిట్లను లెక్కిస్తాము. అన్నింటినీ గుండా వెళ్దాం buckets. మేము ప్రతి బకెట్‌లోని టాప్ 32 బిట్‌లను జోడించిన విలువతో పోల్చాము. మరియు అవి సరిపోలితే, మేము ఫంక్షన్ అని పిలుస్తాము add నిర్మాణం b32 లో buckets. మరియు అక్కడ తక్కువ 32 బిట్‌లను జోడించండి. మరియు అది తిరిగి ఉంటే true, అప్పుడు మేము అక్కడ అటువంటి విలువను జోడించామని మరియు మాకు అలాంటి విలువ లేదని దీని అర్థం. అది తిరిగి వస్తే false, అటువంటి అర్థం ఇప్పటికే ఉనికిలో ఉంది. అప్పుడు మేము నిర్మాణంలో మూలకాల సంఖ్యను పెంచుతాము.

మీకు అవసరమైనది మేము కనుగొనలేకపోతే bucket అవసరమైన హై-విలువతో, మేము ఫంక్షన్‌ని పిలుస్తాము addAlloc, ఇది కొత్తదాన్ని ఉత్పత్తి చేస్తుంది bucket, బకెట్ నిర్మాణం దానిని జోడించడం.

ఇది ఫంక్షన్ యొక్క అమలు b32.add. ఇది మునుపటి అమలును పోలి ఉంటుంది. మేము చాలా ముఖ్యమైన 16 బిట్‌లను, తక్కువ ముఖ్యమైన 16 బిట్‌లను లెక్కిస్తాము.

అప్పుడు మేము అన్ని ఎగువ 16 బిట్‌ల ద్వారా వెళ్తాము. మేము మ్యాచ్‌లను కనుగొంటాము. మరియు ఏదైనా సరిపోలిక ఉంటే, మేము యాడ్ పద్ధతిని పిలుస్తాము, దాని కోసం మేము తదుపరి పేజీలో పరిశీలిస్తాము bucket16.

మరియు ఇక్కడ అత్యల్ప స్థాయి ఉంది, ఇది సాధ్యమైనంత వరకు ఆప్టిమైజ్ చేయబడాలి. మేము లెక్కిస్తాము uint64 స్లైస్ బిట్‌లో ఐడి విలువ మరియు కూడా bitmask. ఇది ఇచ్చిన 64-బిట్ విలువ కోసం ఒక ముసుగు, ఇది ఈ బిట్ ఉనికిని తనిఖీ చేయడానికి లేదా సెట్ చేయడానికి ఉపయోగించవచ్చు. మేము ఈ బిట్ సెట్ చేయబడిందో లేదో తనిఖీ చేస్తాము మరియు దానిని సెట్ చేస్తాము మరియు ఉనికిని తిరిగి ఇస్తాము. ఇది మా అమలు, ఇది సాంప్రదాయ మ్యాప్‌లతో పోలిస్తే సమయ శ్రేణి యొక్క ఖండన ఐడిల ఆపరేషన్‌ను 10 రెట్లు వేగవంతం చేయడానికి మాకు వీలు కల్పించింది.

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

ఇది ఆప్టిమైజేషన్ యొక్క ప్రధాన నియమం - ఇక్కడ అడ్డంకి ఉంటుందని భావించి ఆప్టిమైజేషన్‌ని జోడించవద్దు, ఎందుకంటే అక్కడ అడ్డంకి ఉండదని తేలిపోవచ్చు. ఆప్టిమైజేషన్ సాధారణంగా కోడ్ నాణ్యతను తగ్గిస్తుంది. అందువల్ల, ప్రొఫైలింగ్ తర్వాత మరియు ప్రాధాన్యంగా ఉత్పత్తిలో మాత్రమే ఆప్టిమైజ్ చేయడం విలువైనది, తద్వారా ఇది నిజమైన డేటా. ఎవరైనా ఆసక్తి కలిగి ఉంటే, మీరు VictoriaMetrics సోర్స్ కోడ్‌ని చూడవచ్చు మరియు అక్కడ ఉన్న ఇతర ఆప్టిమైజేషన్‌లను అన్వేషించవచ్చు.

నాకు బిట్‌సెట్ గురించి ఒక ప్రశ్న ఉంది. C++ వెక్టర్ బూల్ ఇంప్లిమెంటేషన్, ఆప్టిమైజ్ చేసిన బిట్‌సెట్‌కి చాలా పోలి ఉంటుంది. అమలును అక్కడి నుంచి తీసుకున్నారా?

లేదు, అక్కడ నుండి కాదు. ఈ బిట్‌సెట్‌ని అమలు చేస్తున్నప్పుడు, విక్టోరియామెట్రిక్స్‌లో ఉపయోగించబడే ఈ ఐడిల టైమ్‌సిరీస్‌ల నిర్మాణం గురించి నాకు అవగాహన కలిగింది. మరియు వాటి నిర్మాణం ఎగువ 32 బిట్‌లు ప్రాథమికంగా స్థిరంగా ఉంటాయి. దిగువ 32 బిట్‌లు మారవచ్చు. తక్కువ బిట్, మరింత తరచుగా మార్చవచ్చు. కాబట్టి, ఈ డేటా నిర్మాణం కోసం ఈ అమలు ప్రత్యేకంగా ఆప్టిమైజ్ చేయబడింది. C++ అమలు, నాకు తెలిసినంతవరకు, సాధారణ సందర్భంలో ఆప్టిమైజ్ చేయబడింది. మీరు సాధారణ కేసు కోసం ఆప్టిమైజ్ చేస్తే, ఇది నిర్దిష్ట కేసుకు అత్యంత అనుకూలమైనది కాదని దీని అర్థం.

అలెక్సీ మిలోవిడ్ యొక్క నివేదికను చూడమని కూడా నేను మీకు సలహా ఇస్తున్నాను. ఒక నెల క్రితం, అతను నిర్దిష్ట స్పెషలైజేషన్ల కోసం క్లిక్‌హౌస్‌లో ఆప్టిమైజేషన్ గురించి మాట్లాడాడు. సాధారణ సందర్భంలో, C++ ఇంప్లిమెంటేషన్ లేదా కొన్ని ఇతర ఇంప్లిమెంటేషన్‌లు ఆసుపత్రిలో సగటున బాగా పనిచేసేలా రూపొందించబడిందని అతను చెప్పాడు. ఇది మా వంటి నాలెడ్జ్-నిర్దిష్ట అమలు కంటే అధ్వాన్నంగా పని చేస్తుంది, ఇక్కడ టాప్ 32 బిట్‌లు చాలా వరకు స్థిరంగా ఉన్నాయని మాకు తెలుసు.

నాకు రెండవ ప్రశ్న ఉంది. InfluxDB నుండి ప్రాథమిక వ్యత్యాసం ఏమిటి?

అనేక ప్రాథమిక వ్యత్యాసాలు ఉన్నాయి. పనితీరు మరియు మెమరీ వినియోగం పరంగా, పరీక్షలలో InfluxDB అధిక కార్డినాలిటీ సమయ శ్రేణి కోసం 10 రెట్లు ఎక్కువ మెమరీ వినియోగాన్ని చూపుతుంది, మీరు వాటిని చాలా కలిగి ఉన్నప్పుడు, ఉదాహరణకు, మిలియన్లు. ఉదాహరణకు, VictoriaMetrics ప్రతి మిలియన్ క్రియాశీల వరుసలకు 1 GB వినియోగిస్తుంది, అయితే InfluxDB 10 GBని వినియోగిస్తుంది. మరియు అది ఒక పెద్ద తేడా.

రెండవ ప్రాథమిక వ్యత్యాసం ఏమిటంటే, InfluxDB విచిత్రమైన ప్రశ్న భాషలను కలిగి ఉంది - Flux మరియు InfluxQL. తో పోలిస్తే సమయ శ్రేణితో పనిచేయడానికి అవి చాలా సౌకర్యవంతంగా లేవు PromQL, దీనికి VictoriaMetrics మద్దతు ఉంది. PromQL అనేది ప్రోమేతియస్ నుండి ఒక ప్రశ్న భాష.

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

విక్టోరియామెట్రిక్స్‌లో ప్రతిదీ చాలా సరళంగా ఉంటుంది. అక్కడ, ప్రతి సమయ శ్రేణి కీ-విలువ. విలువ అనేది పాయింట్ల సమితి - (timestamp, value), మరియు కీ సెట్ label=value. ఫీల్డ్‌లు మరియు కొలతల మధ్య విభజన లేదు. ఇది మీకు తెలిసినంతవరకు వివిధ అడ్డు వరుసల మధ్య లెక్కలు ఇప్పటికీ అమలు చేయబడని InfluxDB వలె కాకుండా ఏదైనా డేటాను ఎంచుకుని, ఆపై కలపడం, జోడించడం, తీసివేయడం, గుణించడం, విభజించడం వంటివి చేయడానికి మిమ్మల్ని అనుమతిస్తుంది. అవి అమలు చేసినా కష్టమే, చాలా కోడ్ రాయాలి.

నాకు స్పష్టమైన ప్రశ్న ఉంది. మీరు మాట్లాడిన ఒక రకమైన సమస్య ఉందని, ఈ విలోమ సూచిక మెమరీకి సరిపోదని, అక్కడ విభజన ఉందని నేను సరిగ్గా అర్థం చేసుకున్నానా?

ముందుగా, నేను ప్రామాణిక గో మ్యాప్‌లో విలోమ సూచిక యొక్క అమాయక అమలును చూపించాను. ఈ అమలు డేటాబేస్‌లకు తగినది కాదు ఎందుకంటే ఈ విలోమ సూచిక డిస్క్‌లో సేవ్ చేయబడదు మరియు డేటాబేస్ తప్పనిసరిగా డిస్క్‌లో సేవ్ చేయబడాలి, తద్వారా ఈ డేటా పునఃప్రారంభించిన తర్వాత అందుబాటులో ఉంటుంది. ఈ అమలులో, మీరు అప్లికేషన్‌ను పునఃప్రారంభించినప్పుడు, మీ విలోమ సూచిక అదృశ్యమవుతుంది. మరియు మీరు మొత్తం డేటాకు ప్రాప్యతను కోల్పోతారు ఎందుకంటే మీరు దాన్ని కనుగొనలేరు.

హలో! నివేదికకు ధన్యవాదాలు! నా పేరు పావెల్. నేను వైల్డ్‌బెర్రీస్ నుండి వచ్చాను. మీ కోసం నా దగ్గర కొన్ని ప్రశ్నలు ఉన్నాయి. ప్రశ్న ఒకటి. మీరు మీ అప్లికేషన్ యొక్క ఆర్కిటెక్చర్‌ను రూపొందించేటప్పుడు వేరొక సూత్రాన్ని ఎంచుకుని, కాలక్రమేణా డేటాను విభజించి ఉంటే, ఒక విభజన ఒకదానికి సంబంధించిన డేటాను కలిగి ఉంటుంది అనే వాస్తవం ఆధారంగా శోధిస్తున్నప్పుడు మీరు డేటాను కలిపే అవకాశం ఉందని మీరు అనుకుంటున్నారా? కాలం , అంటే, ఒక సమయ వ్యవధిలో మరియు మీ ముక్కలు విభిన్నంగా చెల్లాచెదురుగా ఉన్నాయని మీరు చింతించాల్సిన అవసరం లేదా? ప్రశ్న సంఖ్య 2 - మీరు బిట్‌సెట్ మరియు మిగతా వాటితో ఒకే విధమైన అల్గారిథమ్‌ని అమలు చేస్తున్నందున, బహుశా మీరు ప్రాసెసర్ సూచనలను ఉపయోగించి ప్రయత్నించారా? బహుశా మీరు అలాంటి ఆప్టిమైజేషన్‌లను ప్రయత్నించారా?

రెండవ దానికి వెంటనే సమాధానం ఇస్తాను. మేము ఇంకా ఆ స్థితికి రాలేదు. అయితే అవసరమైతే అక్కడికి చేరుకుంటాం. మరియు మొదటిది, ప్రశ్న ఏమిటి?

మీరు రెండు దృశ్యాలను చర్చించారు. మరియు వారు మరింత సంక్లిష్టమైన అమలుతో రెండవదాన్ని ఎంచుకున్నారని వారు చెప్పారు. మరియు వారు మొదటిదాన్ని ఇష్టపడలేదు, ఇక్కడ డేటా సమయం ద్వారా విభజించబడింది.

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

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

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

డేటాను దాటడానికి మనం కర్సర్‌లను ఎందుకు ఉపయోగించకూడదు?

అవును.

మేము క్రమబద్ధీకరించిన అడ్డు వరుసలను LevelDB లేదా విలీనంలో నిల్వ చేస్తాము. మేము కర్సర్‌ను తరలించి, ఖండనను కనుగొనవచ్చు. మనం ఎందుకు ఉపయోగించకూడదు? ఎందుకంటే ఇది నెమ్మదిగా ఉంటుంది. ఎందుకంటే కర్సర్లు అంటే మీరు ప్రతి పంక్తికి ఒక ఫంక్షన్‌ని కాల్ చేయాలి. ఒక ఫంక్షన్ కాల్ 5 నానోసెకన్లు. మరియు మీరు 100 లైన్‌లను కలిగి ఉంటే, మేము ఫంక్షన్‌కు కాల్ చేయడానికి అర సెకను వెచ్చిస్తాము.

అటువంటి విషయం ఉంది, అవును. మరియు నా చివరి ప్రశ్న. అనే ప్రశ్న కొంచెం వింతగా అనిపించవచ్చు. డేటా వచ్చిన సమయంలో అవసరమైన అన్ని కంకరలను చదవడం మరియు అవసరమైన రూపంలో వాటిని సేవ్ చేయడం ఎందుకు సాధ్యం కాదు? VictoriaMetrics, ClickHouse మొదలైన కొన్ని సిస్టమ్‌లలో భారీ వాల్యూమ్‌లను ఎందుకు సేవ్ చేయాలి మరియు వాటిపై ఎక్కువ సమయం వెచ్చించాలి?

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

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

మార్గం ద్వారా, సమయ శ్రేణిని నిల్వ చేయడానికి డేటాబేస్‌లు కంకరల గణనకు మద్దతు ఇస్తాయి. ఉదాహరణకు, ప్రోమేతియస్ మద్దతు ఇస్తుంది రికార్డింగ్ నియమాలు. అంటే, మీకు ఏ యూనిట్లు అవసరమో మీకు తెలిస్తే ఇది చేయవచ్చు. VictoriaMetricsకి ఇది ఇంకా లేదు, కానీ ఇది సాధారణంగా ప్రోమేతియస్‌తో ముందు ఉంటుంది, దీనిలో ఇది రీకోడింగ్ నియమాలలో చేయవచ్చు.

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

మరియు మరొక ప్రశ్న. మేము సగటు గురించి మాట్లాడుతున్నాము మరియు కార్బన్ బ్యాకెండ్‌తో గ్రాఫైట్ వంటిది ఒకప్పుడు ఉందని నేను గుర్తుంచుకున్నాను. మరియు పాత డేటాను ఎలా సన్నబడతారో అతనికి తెలుసు, అంటే నిమిషానికి ఒక పాయింట్, గంటకు ఒక పాయింట్ మొదలైనవి వదిలివేయడం. సూత్రప్రాయంగా, మనకు ముడి డేటా అవసరమైతే, సాపేక్షంగా చెప్పాలంటే, ఒక నెల పాటు మరియు మిగతావన్నీ చేయగలిగితే ఇది చాలా సౌకర్యవంతంగా ఉంటుంది. సన్నబడాలి . కానీ ప్రోమేతియస్ మరియు విక్టోరియామెట్రిక్స్ ఈ కార్యాచరణకు మద్దతు ఇవ్వవు. మద్దతిచ్చే యోచన ఉందా? లేకపోతే, ఎందుకు కాదు?

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

మరియు రెండవ విషయం ఏమిటంటే, క్లిక్‌హౌస్ వంటి VictoriaMetrics, పెద్ద మొత్తంలో ముడి డేటాపై పని చేయడానికి ఆప్టిమైజ్ చేయబడింది, కాబట్టి మీరు మీ సిస్టమ్‌లో అనేక కోర్లను కలిగి ఉన్నట్లయితే అది సెకనులోపు బిలియన్ లైన్‌లను పారవేస్తుంది. విక్టోరియామెట్రిక్స్‌లో సమయ శ్రేణి పాయింట్‌లను స్కానింగ్ చేస్తోంది - ఒక్కో కోర్‌కి సెకనుకు 50 పాయింట్‌లు. మరియు ఈ పనితీరు ఇప్పటికే ఉన్న కోర్లకు స్కేల్ చేస్తుంది. అంటే, మీరు 000 కోర్లను కలిగి ఉంటే, ఉదాహరణకు, మీరు సెకనుకు బిలియన్ పాయింట్లను స్కాన్ చేస్తారు. మరియు VictoriaMetrics మరియు ClickHouse యొక్క ఈ ఆస్తి డౌన్‌సామ్లింగ్ అవసరాన్ని తగ్గిస్తుంది.

విక్టోరియామెట్రిక్స్ ఈ డేటాను సమర్థవంతంగా కుదించడం మరో విశేషం. ఉత్పత్తిలో సగటున కుదింపు పాయింట్‌కు 0,4 నుండి 0,8 బైట్‌ల వరకు ఉంటుంది. ప్రతి పాయింట్ టైమ్‌స్టాంప్ + విలువ. మరియు అది సగటున ఒక బైట్ కంటే తక్కువకు కుదించబడుతుంది.

సెర్గీ. నాకు ఒక ప్రశ్న ఉంది. కనీస రికార్డింగ్ సమయం క్వాంటం ఎంత?

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

నేను మాట్లాడిన వ్యక్తి వారు రెండవ నుండి రెండవ వరకు ఖచ్చితత్వాన్ని కలిగి ఉన్నారని చెప్పారు - ఇది వారికి సరిపోతుంది ఎందుకంటే ఇది సమయ శ్రేణి డేటాబేస్‌లో నిల్వ చేయబడే డేటా రకంపై ఆధారపడి ఉంటుంది. ఇది DevOps డేటా లేదా ఇన్‌ఫ్రాస్ట్రక్చర్ నుండి డేటా అయితే, మీరు దీన్ని నిమిషానికి 30 సెకన్ల వ్యవధిలో సేకరిస్తే, రెండవ ఖచ్చితత్వం సరిపోతుంది, మీకు తక్కువ ఏమీ అవసరం లేదు. మరియు మీరు అధిక ఫ్రీక్వెన్సీ ట్రేడింగ్ సిస్టమ్‌ల నుండి ఈ డేటాను సేకరిస్తే, మీకు నానోసెకండ్ ఖచ్చితత్వం అవసరం.

VictoriaMetricsలో మిల్లీసెకన్ల ఖచ్చితత్వం DevOps కేస్‌కు కూడా అనుకూలంగా ఉంటుంది మరియు నేను నివేదిక ప్రారంభంలో పేర్కొన్న చాలా కేసులకు అనుకూలంగా ఉంటుంది. ఇది సరిపోని ఏకైక విషయం అధిక ఫ్రీక్వెన్సీ ట్రేడింగ్ సిస్టమ్స్.

ధన్యవాదాలు! మరియు మరొక ప్రశ్న. PromQLలో అనుకూలత అంటే ఏమిటి?

పూర్తి వెనుకకు అనుకూలత. VictoriaMetrics పూర్తిగా PromQLకి మద్దతు ఇస్తుంది. అదనంగా, ఇది PromQLలో అదనపు అధునాతన కార్యాచరణను జోడిస్తుంది, దీనిని పిలుస్తారు MetricsQL. ఈ పొడిగించిన కార్యాచరణ గురించి YouTubeలో చర్చ జరుగుతోంది. నేను సెయింట్ పీటర్స్‌బర్గ్‌లో వసంతకాలంలో మానిటరింగ్ మీటప్‌లో మాట్లాడాను.

టెలిగ్రామ్ ఛానల్ విక్టోరియామెట్రిక్స్.

నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. సైన్ ఇన్ చేయండిదయచేసి.

ప్రోమేతియస్ కోసం మీ దీర్ఘకాలిక నిల్వగా VictoriaMetricsకి మారకుండా మిమ్మల్ని ఆపేది ఏమిటి? (వ్యాఖ్యలలో వ్రాయండి, నేను పోల్‌కు జోడిస్తాను))

• 71,4%నేను Prometheus5ని ఉపయోగించను

• 28,6%VictoriaMetrics2 గురించి తెలియదు

7 మంది వినియోగదారులు ఓటు వేశారు. 12 మంది వినియోగదారులు దూరంగా ఉన్నారు.

మూలం: www.habr.com