టైమ్‌స్కేల్‌డిబి డేటాబేస్‌తో బ్యాకెండ్‌గా Zabbix ఎలా పని చేస్తుందో మేము పరిశీలిస్తాము. మొదటి నుండి ఎలా ప్రారంభించాలో మరియు PostgreSQL నుండి ఎలా మైగ్రేట్ చేయాలో మేము మీకు చూపుతాము. మేము రెండు కాన్ఫిగరేషన్ల తులనాత్మక పనితీరు పరీక్షలను కూడా అందిస్తాము.
హైలోడ్++ సైబీరియా 2019. టామ్స్క్ హాల్. జూన్ 24, 16:00. థీసెస్ మరియు . తదుపరి HighLoad++ సమావేశం 6 ఏప్రిల్ 7 మరియు 2020 తేదీలలో సెయింట్ పీటర్స్‌బర్గ్‌లో జరుగుతుంది. వివరాలు మరియు టిక్కెట్లు .
ఆండ్రీ గుష్చిన్ (ఇకపై - AG): – నేను ZABBIX టెక్నికల్ సపోర్ట్ ఇంజనీర్‌ని (ఇకపై "Zabbix"గా సూచిస్తారు), ఒక శిక్షకుడు. నేను 6 సంవత్సరాలకు పైగా సాంకేతిక మద్దతులో పని చేస్తున్నాను మరియు పనితీరుతో ప్రత్యక్ష అనుభవం కలిగి ఉన్నాను. ఈరోజు నేను సాధారణ PostgreSQL 10తో పోల్చినప్పుడు TimescaleDB అందించగల పనితీరు గురించి మాట్లాడతాను. అలాగే, ఇది సాధారణంగా ఎలా పని చేస్తుందనే దాని గురించి కొంత పరిచయ భాగం.
అగ్ర ఉత్పాదకత సవాళ్లు: డేటా సేకరణ నుండి డేటా ప్రక్షాళన వరకు
ప్రారంభించడానికి, ప్రతి పర్యవేక్షణ వ్యవస్థ ఎదుర్కొనే కొన్ని పనితీరు సవాళ్లు ఉన్నాయి. మొదటి ఉత్పాదకత సవాలు డేటాను త్వరగా సేకరించడం మరియు ప్రాసెస్ చేయడం.
ఒక మంచి పర్యవేక్షణ వ్యవస్థ త్వరగా, సకాలంలో మొత్తం డేటాను స్వీకరించాలి, ట్రిగ్గర్ ఎక్స్‌ప్రెషన్‌ల ప్రకారం ప్రాసెస్ చేయాలి, అంటే, కొన్ని ప్రమాణాల ప్రకారం (ఇది వేర్వేరు సిస్టమ్‌లలో భిన్నంగా ఉంటుంది) మరియు ఈ డేటాను ఉపయోగించడానికి డేటాబేస్లో సేవ్ చేయాలి భవిష్యత్తు.
రెండవ పనితీరు సవాలు చరిత్ర నిల్వ. తరచుగా డేటాబేస్లో నిల్వ చేయండి మరియు కొంత కాల వ్యవధిలో సేకరించబడిన ఈ కొలమానాలకు త్వరిత మరియు అనుకూలమైన యాక్సెస్‌ను కలిగి ఉండండి. అత్యంత ముఖ్యమైన విషయం ఏమిటంటే, ఈ డేటాను పొందడం, నివేదికలు, గ్రాఫ్‌లు, ట్రిగ్గర్లు, కొన్ని థ్రెషోల్డ్ విలువలలో, హెచ్చరికల కోసం మొదలైన వాటిలో ఉపయోగించడానికి సౌకర్యవంతంగా ఉంటుంది.
మూడవ పనితీరు సవాలు చరిత్ర క్లియరింగ్, అంటే, మీరు 5 సంవత్సరాలలో (నెలలు లేదా రెండు నెలలు కూడా) సేకరించిన ఎటువంటి వివరణాత్మక కొలమానాలను నిల్వ చేయనవసరం లేని స్థితికి చేరుకున్నప్పుడు. కొన్ని నెట్‌వర్క్ నోడ్‌లు తొలగించబడ్డాయి లేదా కొన్ని హోస్ట్‌లు, కొలమానాలు ఇకపై అవసరం లేదు ఎందుకంటే అవి ఇప్పటికే పాతవి మరియు ఇకపై సేకరించబడవు. మీ డేటాబేస్ చాలా పెద్దదిగా పెరగకుండా ఉండటానికి ఇవన్నీ శుభ్రం చేయాలి. సాధారణంగా, చరిత్రను క్లియర్ చేయడం చాలా తరచుగా నిల్వ కోసం తీవ్రమైన పరీక్ష - ఇది తరచుగా పనితీరుపై చాలా బలమైన ప్రభావాన్ని చూపుతుంది.
కాషింగ్ సమస్యలను ఎలా పరిష్కరించాలి?
నేను ఇప్పుడు Zabbix గురించి ప్రత్యేకంగా మాట్లాడతాను. Zabbixలో, మొదటి మరియు రెండవ కాల్‌లు కాషింగ్ ఉపయోగించి పరిష్కరించబడతాయి.
డేటా సేకరణ మరియు ప్రాసెసింగ్ - ఈ డేటా మొత్తాన్ని నిల్వ చేయడానికి మేము RAMని ఉపయోగిస్తాము. ఈ డేటా ఇప్పుడు మరింత వివరంగా చర్చించబడుతుంది.
డేటాబేస్ వైపు కూడా ప్రధాన ఎంపికల కోసం కొంత కాషింగ్ ఉంది - గ్రాఫ్‌లు మరియు ఇతర విషయాల కోసం.
Zabbix సర్వర్ వైపున కాషింగ్: మాకు కాన్ఫిగరేషన్ కాష్, వాల్యూ కాష్, హిస్టరీ కాష్, ట్రెండ్స్ కాష్ ఉన్నాయి. అదేంటి?
కాన్ఫిగరేషన్‌కాష్ అనేది మేము మెట్రిక్‌లు, హోస్ట్‌లు, డేటా అంశాలు, ట్రిగ్గర్‌లను నిల్వ చేసే ప్రధాన కాష్; మీరు ప్రీప్రాసెసింగ్‌ని ప్రాసెస్ చేయడం, డేటాను సేకరించడం, ఏ హోస్ట్‌ల నుండి సేకరించాలి, ఏ ఫ్రీక్వెన్సీతో అవసరం. డేటాబేస్కు వెళ్లకుండా మరియు అనవసరమైన ప్రశ్నలను సృష్టించకుండా ఉండటానికి ఇవన్నీ కాన్ఫిగరేషన్ కాష్‌లో నిల్వ చేయబడతాయి. సర్వర్ ప్రారంభమైన తర్వాత, మేము ఈ కాష్‌ని అప్‌డేట్ చేస్తాము (దీన్ని సృష్టించండి) మరియు క్రమానుగతంగా (కాన్ఫిగరేషన్ సెట్టింగ్‌లను బట్టి) అప్‌డేట్ చేస్తాము.
Zabbixలో కాషింగ్. వివరాల సేకరణ
ఇక్కడ రేఖాచిత్రం చాలా పెద్దది:
పథకంలో ప్రధానమైనవి ఈ కలెక్టర్లు:
ఇవి అసెంబ్లీ ప్రక్రియలు, వివిధ రకాలైన సమావేశాలకు బాధ్యత వహించే వివిధ "పోలర్లు". వారు icmp, ipmi మరియు వివిధ ప్రోటోకాల్‌ల ద్వారా డేటాను సేకరిస్తారు మరియు అన్నింటినీ ప్రీప్రాసెసింగ్‌కు బదిలీ చేస్తారు.
ప్రీప్రాసెసింగ్ చరిత్రకాష్
అలాగే, మేము డేటా ఎలిమెంట్‌లను లెక్కించినట్లయితే (Zabbix గురించి తెలిసిన వారికి తెలుసు), అంటే లెక్కించబడిన, అగ్రిగేషన్ డేటా ఎలిమెంట్స్, మేము వాటిని నేరుగా ValueCache నుండి తీసుకుంటాము. అది ఎలా నింపాలో తర్వాత చెబుతాను. ఈ కలెక్టర్‌లందరూ తమ ఉద్యోగాలను స్వీకరించడానికి కాన్ఫిగరేషన్‌కాష్‌ని ఉపయోగిస్తారు మరియు వాటిని ప్రీప్రాసెసింగ్‌కు పంపుతారు.
ప్రీప్రాసెసింగ్ అనేది ప్రిప్రాసెసింగ్ దశలను పొందేందుకు కాన్ఫిగరేషన్ కాష్‌ని కూడా ఉపయోగిస్తుంది మరియు ఈ డేటాను వివిధ మార్గాల్లో ప్రాసెస్ చేస్తుంది. వెర్షన్ 4.2 నుండి ప్రారంభించి, మేము దానిని ప్రాక్సీకి తరలించాము. ఇది చాలా సౌకర్యవంతంగా ఉంటుంది, ఎందుకంటే ప్రీప్రాసెసింగ్ అనేది చాలా కష్టమైన ఆపరేషన్. మరియు మీరు పెద్ద సంఖ్యలో డేటా ఎలిమెంట్స్ మరియు అధిక సేకరణ ఫ్రీక్వెన్సీతో చాలా పెద్ద Zabbixని కలిగి ఉంటే, ఇది పనిని చాలా సులభతరం చేస్తుంది.
దీని ప్రకారం, మేము ఈ డేటాను ప్రీప్రాసెసింగ్‌ని ఉపయోగించి ఏదో ఒక విధంగా ప్రాసెస్ చేసిన తర్వాత, దాన్ని మరింత ప్రాసెస్ చేయడానికి హిస్టరీ కాష్‌లో సేవ్ చేస్తాము. ఇది డేటా సేకరణను ముగించింది. మేము ప్రధాన ప్రక్రియకు వెళ్తాము.
హిస్టరీ సింకర్ పని
Zabbixలో ప్రధాన ప్రక్రియ (ఇది ఏకశిలా నిర్మాణం కాబట్టి) హిస్టరీ సింకర్. ఇది ప్రతి డేటా మూలకం యొక్క పరమాణు ప్రాసెసింగ్‌తో ప్రత్యేకంగా వ్యవహరించే ప్రధాన ప్రక్రియ, అంటే ప్రతి విలువ:
- విలువ వస్తుంది (ఇది HistoryCache నుండి తీసుకుంటుంది);
- కాన్ఫిగరేషన్ సమకాలీకరణలో తనిఖీలు: గణన కోసం ఏవైనా ట్రిగ్గర్లు ఉన్నాయా - వాటిని గణిస్తుంది;
అక్కడ ఉంటే - ఈవెంట్‌లను సృష్టిస్తుంది, కాన్ఫిగరేషన్ ప్రకారం అవసరమైతే హెచ్చరికను సృష్టించడానికి పెరుగుదలను సృష్టిస్తుంది; - తదుపరి ప్రాసెసింగ్, అగ్రిగేషన్ కోసం రికార్డుల ట్రిగ్గర్లు; మీరు చివరి గంట మరియు అంతకన్నా ఎక్కువ మొత్తంలో ఉంటే, ఈ విలువ చరిత్ర పట్టికకు వెళ్లకుండా ValueCache ద్వారా గుర్తుంచుకోబడుతుంది; అందువలన, ValueCache ట్రిగ్గర్స్, లెక్కించిన అంశాలు మొదలైనవాటిని లెక్కించడానికి అవసరమైన అవసరమైన డేటాతో నిండి ఉంటుంది;
- అప్పుడు హిస్టరీ సింకర్ మొత్తం డేటాను డేటాబేస్కు వ్రాస్తుంది;
- డేటాబేస్ వాటిని డిస్క్‌కి వ్రాస్తుంది - ఇక్కడ ప్రాసెసింగ్ ప్రక్రియ ముగుస్తుంది.
డేటాబేస్. కాషింగ్
డేటాబేస్ వైపు, మీరు ఈవెంట్‌లపై గ్రాఫ్‌లు లేదా కొన్ని నివేదికలను చూడాలనుకున్నప్పుడు, వివిధ కాష్‌లు ఉన్నాయి. కానీ ఈ నివేదికలో నేను వాటి గురించి మాట్లాడను.
MySQL కోసం Innodb_buffer_pool మరియు వివిధ కాష్‌ల సమూహం కూడా కాన్ఫిగర్ చేయవచ్చు.
కానీ ఇవి ప్రధానమైనవి:
- షేర్డ్_బఫర్స్;
- సమర్థవంతమైన_కాష్_పరిమాణం;
- భాగస్వామ్య_పూల్.
అన్ని డేటాబేస్‌ల కోసం, ప్రశ్నల కోసం తరచుగా అవసరమైన డేటాను RAMలో నిల్వ చేయడానికి మిమ్మల్ని అనుమతించే నిర్దిష్ట కాష్‌లు ఉన్నాయని నేను చెప్పాను. దీని కోసం వారి స్వంత సాంకేతికతలు ఉన్నాయి.
డేటాబేస్ పనితీరు గురించి
దీని ప్రకారం, పోటీ వాతావరణం ఉంది, అంటే, Zabbix సర్వర్ డేటాను సేకరిస్తుంది మరియు దానిని రికార్డ్ చేస్తుంది. పునఃప్రారంభించినప్పుడు, ఇది ValueCache మరియు మొదలైన వాటిని పూరించడానికి చరిత్ర నుండి కూడా చదువుతుంది. ఇక్కడ మీరు వెబ్ ఇంటర్‌ఫేస్‌లో నిర్మించబడిన Zabbix APIని ఉపయోగించే స్క్రిప్ట్‌లు మరియు నివేదికలను కలిగి ఉండవచ్చు. Zabbix API డేటాబేస్‌లోకి ప్రవేశిస్తుంది మరియు గ్రాఫ్‌లు, నివేదికలు లేదా కొన్ని రకాల ఈవెంట్‌ల జాబితా, ఇటీవలి సమస్యలను పొందేందుకు అవసరమైన డేటాను అందుకుంటుంది.
మా వినియోగదారులు ఉపయోగించే గ్రాఫానా కూడా చాలా ప్రజాదరణ పొందిన విజువలైజేషన్ పరిష్కారం. Zabbix API ద్వారా మరియు డేటాబేస్ ద్వారా నేరుగా లాగ్ ఇన్ చేయగలదు. ఇది డేటాను పొందడం కోసం ఒక నిర్దిష్ట పోటీని కూడా సృష్టిస్తుంది: ఫలితాలు మరియు పరీక్షల వేగవంతమైన డెలివరీకి అనుగుణంగా డేటాబేస్ యొక్క సూక్ష్మమైన, మెరుగైన ట్యూనింగ్ అవసరం.
చరిత్రను క్లియర్ చేస్తోంది. Zabbix హౌస్‌కీపర్‌ని కలిగి ఉంది
Zabbixలో ఉపయోగించిన మూడవ కాల్ హౌస్ కీపర్‌ని ఉపయోగించి చరిత్రను క్లియర్ చేస్తోంది. హౌస్‌కీపర్ అన్ని సెట్టింగ్‌లను అనుసరిస్తుంది, అంటే, మా డేటా మూలకాలు ఎంతకాలం నిల్వ చేయాలి (రోజుల్లో), ట్రెండ్‌లను ఎంతకాలం నిల్వ చేయాలి మరియు మార్పుల డైనమిక్‌లను సూచిస్తాయి.
TrendCache గురించి నేను మాట్లాడలేదు, ఇది మేము ఎగిరినప్పుడు లెక్కిస్తాము: డేటా వస్తుంది, మేము దానిని ఒక గంట పాటు సమగ్రపరుస్తాము (ఎక్కువగా ఇవి చివరి గంటకు సంబంధించిన సంఖ్యలు), మొత్తం సగటు/కనిష్టంగా ఉంటుంది మరియు మేము దానిని గంటకు ఒకసారి రికార్డ్ చేస్తాము మార్పుల డైనమిక్స్ పట్టిక ("ధోరణులు") . "హౌస్ కీపర్" సాధారణ ఎంపికలను ఉపయోగించి డేటాబేస్ నుండి డేటాను ప్రారంభిస్తుంది మరియు తొలగిస్తుంది, ఇది ఎల్లప్పుడూ ప్రభావవంతంగా ఉండదు.
ఇది పనికిరానిదని ఎలా అర్థం చేసుకోవాలి? అంతర్గత ప్రక్రియల పనితీరు గ్రాఫ్‌లపై మీరు క్రింది చిత్రాన్ని చూడవచ్చు:
మీ హిస్టరీ సింకర్ నిరంతరం బిజీగా ఉంటుంది (ఎరుపు గ్రాఫ్). మరియు పైన వెళ్ళే "ఎరుపు" గ్రాఫ్. ఇది "హౌస్ కీపర్", ఇది డేటాబేస్ పేర్కొన్న అన్ని అడ్డు వరుసలను తొలగించడానికి ప్రారంభమవుతుంది మరియు వేచి ఉంటుంది.
కొన్ని ఐటెమ్ ఐడిని తీసుకుందాం: మీరు చివరి 5 వేలను తొలగించాలి; వాస్తవానికి, సూచికల ద్వారా. కానీ సాధారణంగా డేటాసెట్ చాలా పెద్దది - డేటాబేస్ ఇప్పటికీ దానిని డిస్క్ నుండి చదివి కాష్‌లో ఉంచుతుంది మరియు ఇది డేటాబేస్ కోసం చాలా ఖరీదైన ఆపరేషన్. దాని పరిమాణంపై ఆధారపడి, ఇది నిర్దిష్ట పనితీరు సమస్యలకు దారి తీస్తుంది.
మీరు హౌస్‌కీపర్‌ని సులభమైన మార్గంలో నిలిపివేయవచ్చు - మాకు తెలిసిన వెబ్ ఇంటర్‌ఫేస్ ఉంది. అడ్మినిస్ట్రేషన్ జనరల్‌లోని సెట్టింగ్‌లు ("హౌస్ కీపర్" కోసం సెట్టింగ్‌లు) మేము అంతర్గత చరిత్ర మరియు ట్రెండ్‌ల కోసం అంతర్గత గృహనిర్వాహకతను నిలిపివేస్తాము. దీని ప్రకారం, హౌస్ కీపర్ ఇకపై దీన్ని నియంత్రించరు:
మీరు తర్వాత ఏమి చేయవచ్చు? మీరు దీన్ని ఆఫ్ చేసారు, మీ గ్రాఫ్‌లు సమం చేయబడ్డాయి... ఈ సందర్భంలో ఇంకా ఏ సమస్యలు తలెత్తవచ్చు? ఏమి సహాయపడుతుంది?
విభజన (విభజన)
సాధారణంగా ఇది నేను జాబితా చేసిన ప్రతి రిలేషనల్ డేటాబేస్లో వేరే విధంగా కాన్ఫిగర్ చేయబడుతుంది. MySQL దాని స్వంత సాంకేతికతను కలిగి ఉంది. కానీ PostgreSQL 10 మరియు MySQL విషయానికి వస్తే మొత్తంగా అవి చాలా పోలి ఉంటాయి. వాస్తవానికి, ఇవన్నీ ఎలా అమలు చేయబడతాయి మరియు పనితీరును ఎలా ప్రభావితం చేస్తాయి అనే దానిలో చాలా అంతర్గత వ్యత్యాసాలు ఉన్నాయి. కానీ సాధారణంగా, కొత్త విభజన యొక్క సృష్టి తరచుగా కొన్ని సమస్యలకు దారితీస్తుంది.
మీ సెటప్‌పై ఆధారపడి (ఒక రోజులో మీరు ఎంత డేటాను సృష్టిస్తారు), వారు సాధారణంగా కనిష్టాన్ని సెట్ చేస్తారు - ఇది 1 రోజు / బ్యాచ్, మరియు “ట్రెండ్‌లు”, మార్పుల డైనమిక్స్ కోసం - 1 నెల / కొత్త బ్యాచ్. మీరు చాలా పెద్ద సెటప్‌ని కలిగి ఉంటే ఇది మారవచ్చు.
సెటప్ పరిమాణం గురించి వెంటనే చెప్పండి: సెకనుకు 5 వేల కొత్త విలువలు (nvps అని పిలవబడేవి) - ఇది చిన్న “సెటప్” గా పరిగణించబడుతుంది. సగటు - సెకనుకు 5 నుండి 25 వేల విలువలు. పైన ఉన్నవన్నీ ఇప్పటికే పెద్దవి మరియు డేటాబేస్ యొక్క చాలా జాగ్రత్తగా కాన్ఫిగరేషన్ అవసరమయ్యే చాలా పెద్ద సంస్థాపనలు.
చాలా పెద్ద ఇన్‌స్టాలేషన్‌లలో, 1 రోజు సరైనది కాకపోవచ్చు. నేను వ్యక్తిగతంగా MySQLలో రోజుకు 40 గిగాబైట్ల విభజనలను చూశాను (మరియు ఇంకా ఎక్కువ ఉండవచ్చు). ఇది చాలా పెద్ద మొత్తంలో డేటా, ఇది కొన్ని సమస్యలకు దారితీయవచ్చు. ఇది తగ్గించాల్సిన అవసరం ఉంది.
మీకు విభజన ఎందుకు అవసరం?
విభజన అనేది టేబుల్ విభజన అని అందరికీ తెలుసు అని నేను అనుకుంటున్నాను. తరచుగా ఇవి డిస్క్ మరియు స్పాన్ అభ్యర్థనలపై ప్రత్యేక ఫైల్‌లు. ఇది సాధారణ విభజనలో భాగమైతే అది ఒక విభజనను మరింత ఉత్తమంగా ఎంచుకుంటుంది.
Zabbix కోసం, ప్రత్యేకించి, ఇది పరిధి ద్వారా ఉపయోగించబడుతుంది, అంటే, మేము టైమ్‌స్టాంప్‌ను ఉపయోగిస్తాము (సాధారణ సంఖ్య, యుగం ప్రారంభం నుండి సమయం). మీరు రోజు ప్రారంభం/రోజు ముగింపుని పేర్కొనండి మరియు ఇది విభజన. దీని ప్రకారం, మీరు రెండు రోజుల పాత డేటా కోసం అడుగుతున్నట్లయితే, డేటాబేస్ నుండి ప్రతిదీ వేగంగా తిరిగి పొందబడుతుంది, ఎందుకంటే మీరు కాష్‌లోకి ఒక ఫైల్‌ను మాత్రమే లోడ్ చేసి, దానిని తిరిగి ఇవ్వాలి (పెద్ద పట్టిక కంటే).
అనేక డేటాబేస్‌లు చొప్పించడాన్ని కూడా వేగవంతం చేస్తాయి (ఒక చైల్డ్ టేబుల్‌లోకి చొప్పించడం). నేను ప్రస్తుతానికి వియుక్తంగా మాట్లాడుతున్నాను, కానీ ఇది కూడా సాధ్యమే. విభజన తరచుగా సహాయపడుతుంది.
NoSQL కోసం సాగే శోధన
ఇటీవల, 3.4లో, మేము NoSQL పరిష్కారాన్ని అమలు చేసాము. సాగే శోధనలో వ్రాయగల సామర్థ్యం జోడించబడింది. మీరు కొన్ని రకాలను వ్రాయవచ్చు: మీరు ఎంచుకోండి - సంఖ్యలు లేదా కొన్ని సంకేతాలను వ్రాయండి; మా వద్ద స్ట్రింగ్ టెక్స్ట్ ఉంది, మీరు సాగే శోధనకు లాగ్‌లను వ్రాయవచ్చు... తదనుగుణంగా, వెబ్ ఇంటర్‌ఫేస్ సాగే శోధనను కూడా యాక్సెస్ చేస్తుంది. ఇది కొన్ని సందర్భాల్లో గొప్పగా పనిచేస్తుంది, కానీ ప్రస్తుతానికి దీనిని ఉపయోగించవచ్చు.
టైమ్‌స్కేల్DB. హైపర్ టేబుల్స్
4.4.2 కోసం మేము TimescaleDB వంటి ఒక విషయంపై దృష్టి పెట్టాము. అదేంటి? ఇది PostgreSQL కోసం పొడిగింపు, అంటే ఇది స్థానిక PostgreSQL ఇంటర్‌ఫేస్‌ని కలిగి ఉంది. అదనంగా, ఈ పొడిగింపు మీరు టైమ్‌సరీస్ డేటాతో మరింత సమర్థవంతంగా పని చేయడానికి మరియు స్వయంచాలక విభజనను కలిగి ఉండటానికి అనుమతిస్తుంది. అది చూడటానికి ఎలా ఉంటుంది:
ఇది హైపర్ టేబుల్ - టైమ్‌స్కేల్‌లో అలాంటి భావన ఉంది. ఇది మీరు సృష్టించే హైపర్ టేబుల్, మరియు ఇందులో భాగాలు ఉంటాయి. భాగాలు విభజనలు, ఇవి చైల్డ్ టేబుల్‌లు, నేను తప్పుగా భావించకపోతే. ఇది నిజంగా ప్రభావవంతమైనది.
TimescaleDB మరియు PostgreSQL
టైమ్‌స్కేల్‌డిబి తయారీదారులు హామీ ఇస్తున్నట్లుగా, వారు ప్రశ్నలను ప్రాసెస్ చేయడానికి మరింత సరైన అల్గారిథమ్‌ను ఉపయోగిస్తారు, ప్రత్యేకించి ఇన్సర్ట్‌లు, డేటాసెట్ ఇన్సర్ట్ యొక్క పెరుగుతున్న పరిమాణంతో సుమారుగా స్థిరమైన పనితీరును కలిగి ఉండటానికి వీలు కల్పిస్తుంది. అంటే, 200 మిలియన్ల పోస్ట్‌గ్రెస్ వరుసల తర్వాత, సాధారణమైనది చాలా కుంగిపోవడం ప్రారంభమవుతుంది మరియు పనితీరును అక్షరాలా సున్నాకి కోల్పోతుంది, అయితే టైమ్‌స్కేల్ ఎంత డేటాతోనైనా ఇన్‌సర్ట్‌లను సాధ్యమైనంత సమర్థవంతంగా ఇన్సర్ట్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
TimescaleDBని ఎలా ఇన్‌స్టాల్ చేయాలి? ఇది సులభం!
ఇది డాక్యుమెంటేషన్‌లో ఉంది, ఇది వివరించబడింది - మీరు దీన్ని ఏదైనా ప్యాకేజీల నుండి ఇన్‌స్టాల్ చేయవచ్చు... ఇది అధికారిక పోస్ట్‌గ్రెస్ ప్యాకేజీలపై ఆధారపడి ఉంటుంది. మానవీయంగా కంపైల్ చేయవచ్చు. నేను డేటాబేస్ కోసం కంపైల్ చేయవలసి వచ్చింది.
Zabbixలో మేము కేవలం పొడిగింపును సక్రియం చేస్తాము. పోస్ట్‌గ్రెస్‌లో ఎక్స్‌టెన్షన్‌ని ఉపయోగించిన వారు... మీరు ఎక్స్‌టెన్షన్‌ని యాక్టివేట్ చేసి, మీరు ఉపయోగిస్తున్న Zabbix డేటాబేస్ కోసం దీన్ని క్రియేట్ చేస్తారని నేను అనుకుంటున్నాను.
మరియు చివరి దశ ...
టైమ్‌స్కేల్DB. చరిత్ర పట్టికల తరలింపు
మీరు హైపర్ టేబుల్‌ని సృష్టించాలి. దీని కోసం ఒక ప్రత్యేక ఫంక్షన్ ఉంది - హైపర్ టేబుల్ సృష్టించండి. అందులో, మొదటి పరామితి ఈ డేటాబేస్లో అవసరమైన పట్టిక (దీని కోసం మీరు హైపర్‌టేబుల్‌ని సృష్టించాలి).
సృష్టించాల్సిన ఫీల్డ్, మరియు chunk_time_interval (ఇది భాగాలు (ఉపయోగించవలసిన విభజనలు) యొక్క విరామం. 86 ఒక రోజు.
Migrate_data పరామితి: మీరు ఒప్పుకు చొప్పించినట్లయితే, ఇది ప్రస్తుత డేటా మొత్తాన్ని ముందుగా సృష్టించిన భాగాలకు మారుస్తుంది.
నేను మైగ్రేట్_డేటాను నేనే ఉపయోగించాను - మీ డేటాబేస్ ఎంత పెద్దది అనేదానిపై ఆధారపడి దీనికి తగిన సమయం పడుతుంది. నా దగ్గర టెరాబైట్ కంటే ఎక్కువ ఉంది - దీన్ని సృష్టించడానికి గంటకు పైగా పట్టింది. కొన్ని సందర్భాల్లో, పరీక్ష సమయంలో, నేను వాటిని బదిలీ చేయకుండా టెక్స్ట్ (history_text) మరియు స్ట్రింగ్ (history_str) కోసం చారిత్రక డేటాను తొలగించాను - అవి నాకు నిజంగా ఆసక్తికరంగా లేవు.
మరియు మేము మా db_extentionలో చివరి అప్‌డేట్‌ను చేస్తాము: మేము timescaledbని ఇన్‌స్టాల్ చేస్తాము, తద్వారా డేటాబేస్ మరియు ప్రత్యేకించి, మా Zabbix db_extention ఉందని అర్థం చేసుకుంటుంది. అతను దానిని సక్రియం చేస్తాడు మరియు టైమ్‌స్కేల్‌డిబికి అవసరమైన “ఫీచర్‌లను” ఉపయోగించి డేటాబేస్కు సరైన సింటాక్స్ మరియు ప్రశ్నలను ఉపయోగిస్తాడు.
సర్వర్ కాన్ఫిగరేషన్
నేను రెండు సర్వర్‌లను ఉపయోగించాను. మొదటి సర్వర్ చాలా చిన్న వర్చువల్ మెషీన్, 20 ప్రాసెసర్లు, 16 గిగాబైట్ల RAM. నేను దానిపై పోస్ట్‌గ్రెస్ 10.8ని కాన్ఫిగర్ చేసాను:
ఆపరేటింగ్ సిస్టమ్ డెబియన్, ఫైల్ సిస్టమ్ xfs. నేను ఈ నిర్దిష్ట డేటాబేస్‌ని ఉపయోగించడానికి కనిష్ట సెట్టింగ్‌లను చేసాను, Zabbix కూడా ఏమి ఉపయోగిస్తుందో మైనస్. అదే మెషీన్‌లో Zabbix సర్వర్, PostgreSQL మరియు లోడ్ ఏజెంట్లు ఉన్నాయి.
విభిన్న ఫలితాలను త్వరగా రూపొందించడానికి LoadableModuleని ఉపయోగించే 50 క్రియాశీల ఏజెంట్లను నేను ఉపయోగించాను. తీగలు, సంఖ్యలు మొదలైనవాటిని రూపొందించిన వారు. నేను చాలా డేటాతో డేటాబేస్ నింపాను. ప్రారంభంలో, కాన్ఫిగరేషన్‌లో ఒక్కో హోస్ట్‌కి 5 వేల డేటా ఎలిమెంట్‌లు ఉన్నాయి మరియు దాదాపు ప్రతి డేటా ఎలిమెంట్‌లో ట్రిగ్గర్ ఉంటుంది - ఇది నిజమైన సెటప్ కావడానికి. కొన్నిసార్లు మీరు ఉపయోగించడానికి ఒకటి కంటే ఎక్కువ ట్రిగ్గర్లు కూడా అవసరం.
నేను 50 ఏజెంట్లను (మరింత జోడించడం) మాత్రమే కాకుండా, డైనమిక్ డేటా ఎలిమెంట్‌లను ఉపయోగించడం ద్వారా మరియు అప్‌డేట్ విరామాన్ని 4 సెకన్లకు తగ్గించడం ద్వారా నవీకరణ విరామం మరియు లోడ్‌ను నియంత్రించాను.
పనితీరు పరీక్ష. PostgreSQL: 36 వేల NVPలు
ఈ హార్డ్‌వేర్‌లో (సెకనుకు 10 వేల విలువలు) స్వచ్ఛమైన PostreSQL 35లో నేను కలిగి ఉన్న మొదటి ప్రయోగం, మొదటి సెటప్. సాధారణంగా, మీరు స్క్రీన్‌పై చూడగలిగినట్లుగా, డేటాను చొప్పించడం సెకనులో భిన్నాలను తీసుకుంటుంది - ప్రతిదీ మంచిది మరియు వేగవంతమైనది, SSD డ్రైవ్‌లు (200 గిగాబైట్లు). ఒకే విషయం ఏమిటంటే 20 GB చాలా త్వరగా నింపుతుంది.
భవిష్యత్తులో ఇలాంటి గ్రాఫ్‌లు చాలా ఉంటాయి. ఇది ప్రామాణిక Zabbix సర్వర్ పనితీరు డాష్‌బోర్డ్.
మొదటి గ్రాఫ్ సెకనుకు విలువల సంఖ్య (నీలం, ఎగువ ఎడమ), ఈ సందర్భంలో 35 వేల విలువలు. ఇది (ఎగువ కేంద్రం) బిల్డ్ ప్రాసెస్‌ల లోడ్, మరియు ఇది (కుడి ఎగువ) అంతర్గత ప్రక్రియల లోడ్: హిస్టరీ సింకర్‌లు మరియు హౌస్‌కీపర్, ఇక్కడ (దిగువ మధ్యలో) చాలా కాలంగా అమలవుతోంది.
ఈ గ్రాఫ్ (దిగువ మధ్యలో) ValueCache వినియోగాన్ని చూపుతుంది - ట్రిగ్గర్‌ల కోసం ఎన్ని ValueCache హిట్‌లు (సెకనుకు అనేక వేల విలువలు). మరొక ముఖ్యమైన గ్రాఫ్ నాల్గవది (దిగువ ఎడమవైపు), ఇది నేను మాట్లాడిన హిస్టరీకాష్ వినియోగాన్ని చూపుతుంది, ఇది డేటాబేస్‌లోకి చొప్పించే ముందు బఫర్.
పనితీరు పరీక్ష. PostgreSQL: 50 వేల NVPలు
తరువాత, నేను అదే హార్డ్‌వేర్‌లో సెకనుకు 50 వేల విలువలకు లోడ్‌ని పెంచాను. హౌస్ కీపర్ లోడ్ చేసినప్పుడు, గణనతో 10-2 సెకన్లలో 3 వేల విలువలు నమోదు చేయబడ్డాయి. వాస్తవానికి, కింది స్క్రీన్‌షాట్‌లో ఏమి చూపబడింది:
"హౌస్ కీపర్" ఇప్పటికే పనిలో జోక్యం చేసుకోవడం ప్రారంభించింది, అయితే సాధారణంగా, హిస్టరీ-సింకర్ ట్రాపర్స్‌పై లోడ్ ఇప్పటికీ 60% స్థాయిలో ఉంది (మూడవ గ్రాఫ్, కుడి ఎగువ). హౌస్‌కీపర్ నడుస్తున్నప్పుడు (దిగువ ఎడమవైపు) హిస్టరీకాష్ ఇప్పటికే చురుకుగా పూరించడం ప్రారంభించింది. ఇది దాదాపు సగం గిగాబైట్, 20% నిండింది.
పనితీరు పరీక్ష. PostgreSQL: 80 వేల NVPలు
అప్పుడు నేను దానిని సెకనుకు 80 వేల విలువలకు పెంచాను:
ఇది సుమారు 400 వేల డేటా అంశాలు, 280 వేల ట్రిగ్గర్లు. ఇన్సర్ట్, మీరు చూడగలిగినట్లుగా, హిస్టరీ సింకర్‌ల లోడ్ పరంగా (వాటిలో 30 ఉన్నాయి) ఇప్పటికే చాలా ఎక్కువగా ఉంది. అప్పుడు నేను వివిధ పారామితులను పెంచాను: హిస్టరీ సింకర్‌లు, కాష్... ఈ హార్డ్‌వేర్‌లో, హిస్టరీ సింకర్‌లపై లోడ్ గరిష్టంగా పెరగడం ప్రారంభమైంది, దాదాపు “షెల్ఫ్లో” - తదనుగుణంగా, హిస్టరీ కాష్ చాలా ఎక్కువ లోడ్‌లోకి వెళ్లింది:
ఈ సమయంలో నేను అన్ని సిస్టమ్ పారామితులను (ప్రాసెసర్ ఎలా ఉపయోగించబడుతుందో, RAM) పర్యవేక్షించాను మరియు డిస్క్ వినియోగం గరిష్టంగా ఉందని కనుగొన్నాను - ఈ హార్డ్‌వేర్‌లో, ఈ వర్చువల్ మెషీన్‌లో నేను ఈ డిస్క్ యొక్క గరిష్ట సామర్థ్యాన్ని సాధించాను. "పోస్ట్‌గ్రెస్" అటువంటి తీవ్రతతో డేటాను చాలా చురుకుగా డంప్ చేయడం ప్రారంభించింది మరియు డిస్క్‌కు వ్రాయడానికి, చదవడానికి సమయం లేదు...
నేను ఇప్పటికే 48 ప్రాసెసర్లు మరియు 128 గిగాబైట్ల RAM కలిగి ఉన్న మరొక సర్వర్‌ని తీసుకున్నాను:
నేను దానిని "ట్యూన్ చేసాను" - హిస్టరీ సింకర్ (60 ముక్కలు) ఇన్‌స్టాల్ చేసాను మరియు ఆమోదయోగ్యమైన పనితీరును సాధించాను. వాస్తవానికి, మేము "షెల్ఫ్లో" లేము, కానీ ఇది బహుశా ఉత్పాదకత యొక్క పరిమితి, ఇక్కడ దాని గురించి ఏదైనా చేయాల్సిన అవసరం ఉంది.
పనితీరు పరీక్ష. టైమ్‌స్కేల్DB: 80 వేల NVPలు
టైమ్‌స్కేల్‌డిబిని ఉపయోగించడం నా ప్రధాన పని. ప్రతి గ్రాఫ్ డిప్ చూపిస్తుంది:
ఈ వైఫల్యాలు ఖచ్చితంగా డేటా మైగ్రేషన్. ఆ తర్వాత, Zabbix సర్వర్‌లో, హిస్టరీ సింకర్‌ల లోడ్ ప్రొఫైల్, మీరు చూడగలిగినట్లుగా, చాలా మార్చబడింది. ఇది దాదాపు 3 రెట్లు వేగంగా డేటాను ఇన్సర్ట్ చేయడానికి మరియు తక్కువ హిస్టరీ కాష్‌ని ఉపయోగించడానికి మిమ్మల్ని అనుమతిస్తుంది - తదనుగుణంగా, మీరు సమయానికి డెలివరీ చేయబడిన డేటాను కలిగి ఉంటారు. మళ్ళీ, సెకనుకు 80 వేల విలువలు చాలా ఎక్కువ రేటు (వాస్తవానికి, Yandex కోసం కాదు). మొత్తంమీద ఇది ఒక సర్వర్‌తో చాలా పెద్ద సెటప్.
PostgreSQL పనితీరు పరీక్ష: 120 వేల NVPలు
తరువాత, నేను డేటా మూలకాల సంఖ్య యొక్క విలువను అర మిలియన్లకు పెంచాను మరియు సెకనుకు 125 వేల లెక్కించిన విలువను పొందాను:
మరియు నేను ఈ గ్రాఫ్‌లను పొందాను:
సూత్రప్రాయంగా, ఇది పని చేసే సెటప్, ఇది చాలా కాలం పాటు పని చేస్తుంది. కానీ నా దగ్గర 1,5 టెరాబైట్ డిస్క్ మాత్రమే ఉంది కాబట్టి, నేను దానిని రెండు రోజుల్లో ఉపయోగించాను. అత్యంత ముఖ్యమైన విషయం ఏమిటంటే, అదే సమయంలో టైమ్‌స్కేల్‌డిబిలో కొత్త విభజనలు సృష్టించబడ్డాయి మరియు ఇది పనితీరు కోసం పూర్తిగా గుర్తించబడలేదు, ఇది MySQL గురించి చెప్పలేము.
సాధారణంగా, విభజనలు రాత్రిపూట సృష్టించబడతాయి, ఎందుకంటే ఇది సాధారణంగా చొప్పించడం మరియు పట్టికలతో పని చేయడం బ్లాక్ చేస్తుంది మరియు సేవ యొక్క అధోకరణానికి దారితీస్తుంది. ఈ సందర్భంలో, ఇది అలా కాదు! TimescaleDB యొక్క సామర్థ్యాలను పరీక్షించడం ప్రధాన పని. ఫలితం క్రింది సంఖ్య: సెకనుకు 120 వేల విలువలు.
సంఘంలో ఉదాహరణలు కూడా ఉన్నాయి:
వ్యక్తి టైమ్‌స్కేల్‌డిబిని కూడా ఆన్ చేసాడు మరియు ప్రాసెసర్‌పై io.weightని ఉపయోగించడంపై లోడ్ పడిపోయింది; మరియు టైమ్‌స్కేల్‌డిబిని చేర్చడం వల్ల అంతర్గత ప్రక్రియ మూలకాల వినియోగం కూడా తగ్గింది. అంతేకాకుండా, ఇవి సాధారణ పాన్‌కేక్ డిస్క్‌లు, అంటే సాధారణ డిస్క్‌లలోని సాధారణ వర్చువల్ మెషీన్ (SSDలు కాదు)!
డిస్క్ పనితీరు ద్వారా పరిమితం చేయబడిన కొన్ని చిన్న సెటప్‌ల కోసం, TimescaleDB, నా అభిప్రాయం ప్రకారం, చాలా మంచి పరిష్కారం. డేటాబేస్ కోసం వేగవంతమైన హార్డ్‌వేర్‌కు తరలించడానికి ముందు పనిని కొనసాగించడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.
నేను మీ అందరినీ మా ఈవెంట్‌లకు ఆహ్వానిస్తున్నాను: మాస్కోలో సమావేశం, రిగాలో సమ్మిట్. మా ఛానెల్‌లను ఉపయోగించండి - టెలిగ్రామ్, ఫోరమ్, IRC. మీకు ఏవైనా ప్రశ్నలు ఉంటే, మా డెస్క్‌కి రండి, మేము ప్రతిదీ గురించి మాట్లాడవచ్చు.
ప్రేక్షకుల ప్రశ్నలు
ప్రేక్షకుల నుండి ప్రశ్న (ఇకపై - A): - టైమ్‌స్కేల్‌డిబిని కాన్ఫిగర్ చేయడం చాలా సులువుగా ఉంటే మరియు అది అటువంటి పనితీరును బూస్ట్ చేస్తే, బహుశా పోస్ట్‌గ్రెస్‌తో Zabbixని కాన్ఫిగర్ చేయడానికి ఇది ఒక ఉత్తమ సాధనగా ఉపయోగించబడుతుందా? మరియు ఈ పరిష్కారంలో ఏవైనా ఆపదలు మరియు అప్రయోజనాలు ఉన్నాయా లేదా అన్నింటికంటే, నేను నా కోసం Zabbixని తయారు చేయాలని నిర్ణయించుకుంటే, నేను పోస్ట్‌గ్రెస్‌ను సులభంగా తీసుకోగలను, టైమ్‌స్కేల్‌ను వెంటనే ఇన్‌స్టాల్ చేయగలను, దాన్ని ఉపయోగించుకోవచ్చు మరియు ఏవైనా సమస్యల గురించి ఆలోచించకూడదా?
AG: – అవును, ఇది మంచి సిఫార్సు అని నేను చెబుతాను: TimescaleDB పొడిగింపుతో వెంటనే Postgresని ఉపయోగించండి. నేను ఇప్పటికే చెప్పినట్లుగా, ఈ "ఫీచర్" ప్రయోగాత్మకంగా ఉన్నప్పటికీ, చాలా మంచి సమీక్షలు. కానీ వాస్తవానికి పరీక్షలు ఇది ఒక గొప్ప పరిష్కారం (టైమ్‌స్కేల్‌డిబితో) అని చూపిస్తున్నాయి మరియు ఇది అభివృద్ధి చెందుతుందని నేను భావిస్తున్నాను! మేము ఈ పొడిగింపు ఎలా అభివృద్ధి చెందుతుందో పర్యవేక్షిస్తున్నాము మరియు అవసరమైన విధంగా మార్పులు చేస్తాము.
అభివృద్ధి సమయంలో కూడా, మేము వారి బాగా తెలిసిన "లక్షణాలలో" ఒకదానిపై ఆధారపడ్డాము: కొంచెం విభిన్నంగా భాగాలతో పని చేయడం సాధ్యమైంది. కానీ తర్వాత వారు దానిని తదుపరి విడుదలలో తగ్గించారు మరియు మేము ఈ కోడ్‌పై ఆధారపడటం మానేయాలి. అనేక సెటప్‌లలో ఈ పరిష్కారాన్ని ఉపయోగించమని నేను సిఫార్సు చేస్తున్నాను. మీరు MySQLని ఉపయోగిస్తే... సగటు సెటప్‌ల కోసం, ఏదైనా పరిష్కారం బాగా పనిచేస్తుంది.
మరియు: – సంఘం నుండి వచ్చిన చివరి గ్రాఫ్‌లలో, “హౌస్ కీపర్”తో గ్రాఫ్ ఉంది:
అతను పని కొనసాగించాడు. టైమ్‌స్కేల్‌డిబితో హౌస్‌కీపర్ ఏమి చేస్తారు?
AG: - ఇప్పుడు నేను ఖచ్చితంగా చెప్పలేను - నేను కోడ్‌ని చూసి మరింత వివరంగా చెబుతాను. ఇది టైమ్‌స్కేల్‌డిబి క్వెరీలను భాగాలను తొలగించడానికి కాదు, వాటిని ఏదో ఒకవిధంగా సమగ్రపరచడానికి ఉపయోగిస్తుంది. ఈ సాంకేతిక ప్రశ్నకు సమాధానం ఇవ్వడానికి నేను ఇంకా సిద్ధంగా లేను. మేము ఈ రోజు లేదా రేపు స్టాండ్‌లో మరిన్నింటిని కనుగొంటాము.
మరియు: – నాకు ఇదే ప్రశ్న ఉంది – టైమ్‌స్కేల్‌లో తొలగింపు ఆపరేషన్ పనితీరు గురించి.
A (ప్రేక్షకుల నుండి సమాధానం): – మీరు పట్టిక నుండి డేటాను తొలగించినప్పుడు, మీరు దానిని తొలగించడం ద్వారా చేస్తే, మీరు టేబుల్ ద్వారా వెళ్లాలి - భవిష్యత్తులో వాక్యూమ్ కోసం ప్రతిదీ తొలగించండి, శుభ్రం చేయండి, గుర్తు పెట్టండి. టైమ్‌స్కేల్‌లో, మీకు భాగాలు ఉన్నందున, మీరు డ్రాప్ చేయవచ్చు. స్థూలంగా చెప్పాలంటే, మీరు పెద్ద డేటాలో ఉన్న ఫైల్‌కి చెప్పండి: “తొలగించు!”
అటువంటి భాగం ఇకపై ఉనికిలో లేదని టైమ్‌స్కేల్ అర్థం చేసుకుంటుంది. మరియు ఇది క్వెరీ ప్లానర్‌లో విలీనం చేయబడినందున, ఎంపిక చేసిన లేదా ఇతర కార్యకలాపాలలో మీ పరిస్థితులను పట్టుకోవడానికి ఇది హుక్స్‌లను ఉపయోగిస్తుంది మరియు ఈ భాగం ఇకపై ఉనికిలో లేదని వెంటనే అర్థం చేసుకుంటుంది - “నేను ఇకపై అక్కడికి వెళ్లను!” (డేటా అందుబాటులో లేదు). అంతే! అంటే, టేబుల్ స్కాన్ బైనరీ ఫైల్ తొలగింపు ద్వారా భర్తీ చేయబడుతుంది, కాబట్టి ఇది వేగంగా ఉంటుంది.
మరియు: – SQL కాని అంశంపై మేము ఇప్పటికే టచ్ చేసాము. నేను అర్థం చేసుకున్నంత వరకు, Zabbix నిజంగా డేటాను సవరించాల్సిన అవసరం లేదు మరియు ఇదంతా లాగ్ లాంటిది. వారి డేటాను మార్చలేని ప్రత్యేక డేటాబేస్‌లను ఉపయోగించడం సాధ్యమేనా, కానీ అదే సమయంలో చాలా వేగంగా సేవ్ చేయడం, పేరుకుపోవడం మరియు పంపిణీ చేయడం సాధ్యమేనా - క్లిక్‌హౌస్, ఉదాహరణకు, కాఫ్కా లాంటిదేనా?.. కాఫ్కా కూడా ఒక లాగ్! వాటిని ఏదో ఒకవిధంగా ఏకీకృతం చేయడం సాధ్యమేనా?
AG: - అన్‌లోడ్ చేయవచ్చు. వెర్షన్ 3.4 నుండి మాకు నిర్దిష్ట "ఫీచర్" ఉంది: మీరు అన్ని చారిత్రక ఫైల్‌లు, ఈవెంట్‌లు, మిగతావన్నీ ఫైల్‌లకు వ్రాయవచ్చు; ఆపై ఏదైనా హ్యాండ్లర్‌ని ఉపయోగించి ఏదైనా ఇతర డేటాబేస్‌కి పంపండి. వాస్తవానికి, చాలా మంది వ్యక్తులు తిరిగి పని చేస్తారు మరియు నేరుగా డేటాబేస్కు వ్రాస్తారు. ఫ్లైలో, హిస్టరీ సింకర్‌లు వీటన్నింటిని ఫైల్‌లుగా వ్రాస్తాయి, ఈ ఫైల్‌లను తిప్పండి మరియు మొదలైనవి, మరియు మీరు దీన్ని క్లిక్‌హౌస్‌కి బదిలీ చేయవచ్చు. నేను ప్లాన్‌ల గురించి చెప్పలేను, కానీ బహుశా NoSQL సొల్యూషన్‌లకు (క్లిక్‌హౌస్ వంటివి) మరింత మద్దతు కొనసాగుతుంది.
మరియు: – సాధారణంగా, మీరు పూర్తిగా పోస్ట్‌గ్రెస్‌ను వదిలించుకోగలరని తేలింది?
AG: - వాస్తవానికి, జబ్బిక్స్‌లో అత్యంత కష్టమైన భాగం చారిత్రక పట్టికలు, ఇది చాలా సమస్యలను మరియు సంఘటనలను సృష్టిస్తుంది. ఈ సందర్భంలో, మీరు చాలా కాలం పాటు ఈవెంట్‌లను నిల్వ చేయకపోతే మరియు చరిత్రను కొన్ని ఇతర ఫాస్ట్ స్టోరేజ్‌లో ట్రెండ్‌లతో నిల్వ చేస్తే, సాధారణంగా, ఎటువంటి సమస్యలు ఉండవని నేను అనుకుంటున్నాను.
మరియు: – మీరు క్లిక్‌హౌస్‌కి మారితే ప్రతిదీ ఎంత వేగంగా పని చేస్తుందో మీరు అంచనా వేయగలరా?
AG: - నేను దానిని పరీక్షించలేదు. క్లిక్‌హౌస్‌కు దాని స్వంత ఇంటర్‌ఫేస్ ఉన్నందున, కనీసం అదే సంఖ్యలను చాలా సరళంగా సాధించవచ్చని నేను భావిస్తున్నాను, కానీ నేను ఖచ్చితంగా చెప్పలేను. పరీక్షించడం మంచిది. ఇది అన్ని కాన్ఫిగరేషన్‌పై ఆధారపడి ఉంటుంది: మీకు ఎన్ని హోస్ట్‌లు ఉన్నాయి మరియు మొదలైనవి. చొప్పించడం ఒక విషయం, కానీ మీరు ఈ డేటాను కూడా తిరిగి పొందాలి - గ్రాఫానా లేదా మరేదైనా.
మరియు: – కాబట్టి మేము సమాన పోరాటం గురించి మాట్లాడుతున్నాము మరియు ఈ వేగవంతమైన డేటాబేస్‌ల యొక్క గొప్ప ప్రయోజనం గురించి కాదా?
AG: – మేము ఏకీకృతం చేసినప్పుడు, మరింత ఖచ్చితమైన పరీక్షలు ఉంటాయని నేను భావిస్తున్నాను.
మరియు: – మంచి పాత RRD ఎక్కడికి వెళ్ళింది? మీరు SQL డేటాబేస్‌లకు మారడానికి కారణం ఏమిటి? ప్రారంభంలో, అన్ని కొలమానాలు RRDలో సేకరించబడ్డాయి.
AG: - Zabbix RRDని కలిగి ఉంది, బహుశా చాలా పురాతన వెర్షన్‌లో ఉండవచ్చు. ఎల్లప్పుడూ SQL డేటాబేస్‌లు ఉన్నాయి - ఒక క్లాసిక్ విధానం. క్లాసిక్ విధానం MySQL, PostgreSQL (అవి చాలా కాలం నుండి ఉన్నాయి). SQL మరియు RRD డేటాబేస్‌ల కోసం మేము దాదాపు ఎప్పుడూ సాధారణ ఇంటర్‌ఫేస్‌ని ఉపయోగించలేదు.
కొన్ని ప్రకటనలు 🙂
మాతో ఉన్నందుకు ధన్యవాదాలు. మీరు మా కథనాలను ఇష్టపడుతున్నారా? మరింత ఆసక్తికరమైన కంటెంట్‌ని చూడాలనుకుంటున్నారా? ఆర్డర్ చేయడం ద్వారా లేదా స్నేహితులకు సిఫార్సు చేయడం ద్వారా మాకు మద్దతు ఇవ్వండి, , ఎంట్రీ-లెవల్ సర్వర్‌ల యొక్క ప్రత్యేకమైన అనలాగ్, ఇది మీ కోసం మా ద్వారా కనుగొనబడింది: (RAID1 మరియు RAID10తో అందుబాటులో ఉంది, గరిష్టంగా 24 కోర్లు మరియు 40GB DDR4 వరకు).
ఆమ్‌స్టర్‌డామ్‌లోని ఈక్వినిక్స్ టైర్ IV డేటా సెంటర్‌లో Dell R730xd 2x చౌకగా ఉందా? ఇక్కడ మాత్రమే నెదర్లాండ్స్‌లో! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 నుండి! గురించి చదవండి
మూలం: www.habr.com