అధిక పనితీరు మరియు స్థానిక విభజన: TimescaleDB మద్దతుతో Zabbix

Zabbix ఒక పర్యవేక్షణ వ్యవస్థ. ఏదైనా ఇతర వ్యవస్థ వలె, ఇది అన్ని పర్యవేక్షణ వ్యవస్థల యొక్క మూడు ప్రధాన సమస్యలను ఎదుర్కొంటుంది: డేటాను సేకరించడం మరియు ప్రాసెస్ చేయడం, చరిత్రను నిల్వ చేయడం మరియు దానిని శుభ్రపరచడం.

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

Zabbixలో సేకరణ మరియు నిల్వ సమయంలో ఆలస్యం యొక్క సమస్యలు కాషింగ్ ద్వారా పరిష్కరించబడతాయి: అనేక రకాల కాష్‌లు, డేటాబేస్‌లో కాషింగ్. మూడవ సమస్యను పరిష్కరించడానికి, కాషింగ్ తగినది కాదు, కాబట్టి Zabbix TimescaleDBని ఉపయోగించింది. అతను దాని గురించి మీకు చెప్తాడు ఆండ్రీ గుష్చిన్ - సాంకేతిక మద్దతు ఇంజనీర్ Zabbix SIA. ఆండ్రీ 6 సంవత్సరాలకు పైగా Zabbixకి మద్దతు ఇస్తున్నారు మరియు పనితీరుతో ప్రత్యక్ష అనుభవం కలిగి ఉన్నారు.

TimescaleDB ఎలా పని చేస్తుంది, సాధారణ PostgreSQLతో పోలిస్తే ఇది ఎలాంటి పనితీరును అందిస్తుంది? TimescaleDB డేటాబేస్ కోసం Zabbix ఏ పాత్ర పోషిస్తుంది? మొదటి నుండి ఎలా ప్రారంభించాలి మరియు PostgreSQL నుండి ఎలా మైగ్రేట్ చేయాలి మరియు ఏ కాన్ఫిగరేషన్ మెరుగైన పనితీరును కలిగి ఉంది? కట్ కింద అన్ని ఈ గురించి.

ఉత్పాదకత సవాళ్లు

ప్రతి పర్యవేక్షణ వ్యవస్థ నిర్దిష్ట పనితీరు సవాళ్లను ఎదుర్కొంటుంది. నేను వాటిలో మూడు గురించి మాట్లాడతాను: డేటా సేకరణ మరియు ప్రాసెసింగ్, నిల్వ మరియు చరిత్ర క్లియరింగ్.

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

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

చరిత్రను క్లియర్ చేస్తోంది. కొన్నిసార్లు మీరు కొలమానాలను నిల్వ చేయవలసిన అవసరం లేని రోజు వస్తుంది. మీకు 5 సంవత్సరాల క్రితం, ఒక నెల లేదా రెండు నెలల క్రితం సేకరించిన డేటా ఎందుకు అవసరం: కొన్ని నోడ్‌లు తొలగించబడ్డాయి, కొన్ని హోస్ట్‌లు లేదా మెట్రిక్‌లు పాతవి మరియు ఇకపై సేకరించబడనందున ఇకపై అవసరం లేదు. మంచి పర్యవేక్షణ వ్యవస్థ చారిత్రక డేటాను నిల్వ చేయాలి మరియు డేటాబేస్ పెరగకుండా ఎప్పటికప్పుడు తొలగించాలి.

పాత డేటాను శుభ్రపరచడం అనేది డేటాబేస్ పనితీరును బాగా ప్రభావితం చేసే క్లిష్టమైన సమస్య.

Zabbixలో కాషింగ్

Zabbixలో, మొదటి మరియు రెండవ కాల్‌లు కాషింగ్ ఉపయోగించి పరిష్కరించబడతాయి. డేటాను సేకరించడానికి మరియు ప్రాసెస్ చేయడానికి RAM ఉపయోగించబడుతుంది. నిల్వ కోసం - ట్రిగ్గర్‌లు, గ్రాఫ్‌లు మరియు లెక్కించిన డేటా మూలకాలలో చరిత్ర. డేటాబేస్ వైపు ప్రాథమిక ఎంపికల కోసం కొంత కాషింగ్ ఉంది, ఉదాహరణకు, గ్రాఫ్‌లు.

Zabbix సర్వర్ వైపున కాషింగ్ చేయడం:

• కాన్ఫిగరేషన్ కాష్;
• ValueCache;
• చరిత్రకాష్;
• TrendsCache.

వాటిని మరింత వివరంగా పరిగణించండి.

కాన్ఫిగరేషన్కాష్

ఇది మేము మెట్రిక్‌లు, హోస్ట్‌లు, డేటా ఐటెమ్‌లు, ట్రిగ్గర్‌లను నిల్వ చేసే ప్రధాన కాష్ - ప్రీప్రాసెసింగ్ కోసం మరియు డేటా సేకరణ కోసం మనకు కావలసినవన్నీ.

డేటాబేస్‌లో అనవసరమైన ప్రశ్నలను సృష్టించకుండా ఉండటానికి ఇవన్నీ కాన్ఫిగరేషన్ కాష్‌లో నిల్వ చేయబడతాయి. సర్వర్ ప్రారంభమైన తర్వాత, మేము ఈ కాష్‌ని అప్‌డేట్ చేస్తాము, కాన్ఫిగరేషన్‌లను సృష్టించండి మరియు క్రమానుగతంగా అప్‌డేట్ చేస్తాము.

వివరాల సేకరణ

రేఖాచిత్రం చాలా పెద్దది, కానీ దానిలో ప్రధాన విషయం పికర్స్. ఇవి వివిధ “పోలర్లు” - అసెంబ్లీ ప్రక్రియలు. వారు వివిధ రకాల అసెంబ్లీకి బాధ్యత వహిస్తారు: వారు SNMP, IPMI ద్వారా డేటాను సేకరిస్తారు మరియు అన్నింటినీ ప్రీప్రాసెసింగ్‌కు బదిలీ చేస్తారు.

కలెక్టర్లు నారింజ రంగులో వివరించబడ్డాయి.

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

ప్రీప్రాసెసింగ్ చరిత్రకాష్

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

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

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

గమనిక: ప్రీప్రాసెసింగ్ అనేది చాలా కష్టమైన ఆపరేషన్. v 4.2 నుండి ఇది ప్రాక్సీకి తరలించబడింది. మీరు పెద్ద సంఖ్యలో డేటా మూలకాలు మరియు సేకరణ ఫ్రీక్వెన్సీతో చాలా పెద్ద Zabbixని కలిగి ఉంటే, ఇది పనిని మరింత సులభతరం చేస్తుంది.

ValueCache, హిస్టరీ & ట్రెండ్స్ కాష్

చరిత్ర సమకాలీకరణ అనేది ప్రతి డేటా మూలకాన్ని, అంటే ప్రతి విలువను పరమాణుపరంగా ప్రాసెస్ చేసే ప్రధాన ప్రక్రియ.

హిస్టరీ సింకర్ హిస్టరీ కాష్ నుండి విలువలను తీసుకుంటుంది మరియు లెక్కల కోసం ట్రిగ్గర్‌ల ఉనికి కోసం కాన్ఫిగరేషన్‌ను తనిఖీ చేస్తుంది. అవి ఉనికిలో ఉంటే, అది లెక్కిస్తుంది.

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

హిస్టరీ సింకర్ మొత్తం డేటాను డేటాబేస్కు వ్రాస్తుంది మరియు అది డిస్క్‌కి వ్రాస్తుంది. ప్రాసెసింగ్ ప్రక్రియ ఇక్కడ ముగుస్తుంది.

డేటాబేస్లో కాషింగ్

మీరు ఈవెంట్‌లపై గ్రాఫ్‌లు లేదా నివేదికలను చూడాలనుకున్నప్పుడు డేటాబేస్ వైపు వివిధ కాష్‌లు ఉన్నాయి:

• Innodb_buffer_pool MySQL వైపు;
• shared_buffers PostgreSQL వైపు;
• effective_cache_size ఒరాకిల్ వైపు;
• shared_pool DB2 వైపు.

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

డేటాబేస్ పనితీరు కీలకం

Zabbix సర్వర్ నిరంతరం డేటాను సేకరిస్తుంది మరియు వ్రాస్తుంది. పునఃప్రారంభించినప్పుడు, ValueCacheని పూరించడానికి ఇది చరిత్ర నుండి కూడా చదువుతుంది. స్క్రిప్ట్‌లు మరియు నివేదికలను ఉపయోగిస్తుంది Zabbix API, ఇది వెబ్ ఇంటర్‌ఫేస్‌లో నిర్మించబడింది. Zabbix API డేటాబేస్‌ను యాక్సెస్ చేస్తుంది మరియు గ్రాఫ్‌లు, నివేదికలు, ఈవెంట్ జాబితాలు మరియు తాజా సమస్యల కోసం అవసరమైన డేటాను తిరిగి పొందుతుంది.

విజువలైజేషన్ కోసం - గ్రాఫనా. ఇది మా వినియోగదారుల మధ్య ఒక ప్రసిద్ధ పరిష్కారం. ఇది నేరుగా Zabbix API ద్వారా మరియు డేటాబేస్కు అభ్యర్థనలను పంపగలదు మరియు డేటాను స్వీకరించడానికి ఒక నిర్దిష్ట పోటీని సృష్టిస్తుంది. అందువల్ల, ఫలితాలు మరియు పరీక్షల వేగవంతమైన డెలివరీకి సరిపోలడానికి డేటాబేస్ యొక్క సూక్ష్మమైన మరియు మెరుగైన ట్యూనింగ్ అవసరం.

ఇంటిలో

Zabbixలో మూడవ పనితీరు సవాలు హౌస్‌కీపర్‌ని ఉపయోగించి హిస్టరీ క్లియరింగ్. ఇది అన్ని సెట్టింగులను అనుసరిస్తుంది - డేటా మూలకాలు రోజులలో మార్పుల డైనమిక్స్ (ధోరణులు) ఎంతకాలం నిల్వ చేయాలో సూచిస్తాయి.

మేము ఫ్లైలో TrendsCacheని లెక్కిస్తాము. డేటా వచ్చినప్పుడు, మేము దానిని ఒక గంట పాటు సమగ్రపరచి, ట్రెండ్ మార్పుల డైనమిక్స్ కోసం పట్టికలలో రికార్డ్ చేస్తాము.

గృహనిర్వాహకుడు సాధారణ "ఎంపికలు" ఉపయోగించి డేటాబేస్ నుండి సమాచారాన్ని ప్రారంభిస్తాడు మరియు తొలగిస్తాడు. ఇది ఎల్లప్పుడూ ప్రభావవంతంగా ఉండదు, అంతర్గత ప్రక్రియల పనితీరు గ్రాఫ్‌ల నుండి చూడవచ్చు.

హిస్టరీ సింకర్ నిరంతరం బిజీగా ఉన్నట్లు ఎరుపు గ్రాఫ్ చూపిస్తుంది. ఎగువన ఉన్న ఆరెంజ్ గ్రాఫ్ హౌస్ కీపర్, ఇది నిరంతరం నడుస్తుంది. అతను పేర్కొన్న అన్ని అడ్డు వరుసలను తొలగించడానికి డేటాబేస్ కోసం అతను వేచి ఉంటాడు.

మీరు హౌస్‌కీపర్‌ని ఎప్పుడు డిసేబుల్ చేయాలి? ఉదాహరణకు, "ఐటెమ్ ID" ఉంది మరియు మీరు నిర్దిష్ట సమయంలో చివరి 5 వేల అడ్డు వరుసలను తొలగించాలి. వాస్తవానికి, ఇది సూచిక ద్వారా జరుగుతుంది. కానీ సాధారణంగా డేటాసెట్ చాలా పెద్దది, మరియు డేటాబేస్ ఇప్పటికీ డిస్క్ నుండి చదివి కాష్‌లో ఉంచుతుంది. ఇది ఎల్లప్పుడూ డేటాబేస్ కోసం చాలా ఖరీదైన ఆపరేషన్ మరియు డేటాబేస్ పరిమాణంపై ఆధారపడి, పనితీరు సమస్యలకు దారి తీస్తుంది.

హౌస్ కీపర్ డిసేబుల్ చేయడం సులభం. వెబ్ ఇంటర్‌ఫేస్‌లో హౌస్‌కీపర్ కోసం "అడ్మినిస్ట్రేషన్ జనరల్"లో సెట్టింగ్ ఉంది. మేము అంతర్గత ట్రెండ్ హిస్టరీ కోసం అంతర్గత హౌస్ కీపింగ్‌ని నిలిపివేస్తాము మరియు అది ఇకపై దానిని నిర్వహించదు.

హౌస్ కీపర్ ఆఫ్ చేయబడింది, గ్రాఫ్‌లు సమం చేయబడ్డాయి - ఈ సందర్భంలో ఏ సమస్యలు ఉండవచ్చు మరియు మూడవ పనితీరు సవాలును పరిష్కరించడానికి ఏది సహాయపడుతుంది?

విభజన - విభజన లేదా విభజన

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

సాధారణంగా, విభజనలు “సెటప్” పై ఆధారపడి కాన్ఫిగర్ చేయబడతాయి - ఒక రోజులో సృష్టించబడిన డేటా మొత్తం. నియమం ప్రకారం, విభజన ఒక రోజులో జారీ చేయబడుతుంది, ఇది కనిష్టం. కొత్త బ్యాచ్ ట్రెండ్‌ల కోసం - 1 నెల.

"సెటప్" చాలా పెద్దగా ఉంటే విలువలు మారవచ్చు. చిన్న “సెటప్” 5 nvps (సెకనుకు కొత్త విలువలు) వరకు ఉంటే, మీడియం 000 నుండి 5 వరకు ఉంటే, పెద్దది 000 nvps కంటే ఎక్కువగా ఉంటుంది. ఇవి డేటాబేస్ యొక్క జాగ్రత్తగా కాన్ఫిగరేషన్ అవసరమయ్యే పెద్ద మరియు చాలా పెద్ద సంస్థాపనలు.

చాలా పెద్ద ఇన్‌స్టాలేషన్‌లలో, ఒక రోజు వ్యవధి సరైనది కాకపోవచ్చు. నేను రోజుకు 40 GB లేదా అంతకంటే ఎక్కువ MySQL విభజనలను చూశాను. ఇది చాలా పెద్ద మొత్తంలో డేటా, ఇది సమస్యలను కలిగిస్తుంది మరియు తగ్గించాల్సిన అవసరం ఉంది.

విభజన ఏమి ఇస్తుంది?

విభజన పట్టికలు. తరచుగా ఇవి డిస్క్‌లోని ప్రత్యేక ఫైల్‌లు. ప్రశ్న ప్రణాళిక ఒక విభజనను మరింత ఉత్తమంగా ఎంచుకుంటుంది. సాధారణంగా విభజన పరిధిని బట్టి ఉపయోగించబడుతుంది - ఇది Zabbixకి కూడా వర్తిస్తుంది. మేము అక్కడ “టైమ్‌స్టాంప్” ఉపయోగిస్తాము - యుగం ప్రారంభం నుండి సమయం. ఇవి మనకు సాధారణ సంఖ్యలు. మీరు రోజు ప్రారంభం మరియు ముగింపును సెట్ చేసారు - ఇది విభజన.

త్వరిత తొలగింపు - DELETE. తొలగింపు కోసం అడ్డు వరుసల ఎంపిక కాకుండా ఒక ఫైల్/సబ్ టేబుల్ ఎంచుకోబడింది.

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

తరచుగా అనేక డేటాబేస్‌లు కూడా వేగవంతం చేయబడతాయి INSERT - చైల్డ్ టేబుల్‌లోకి చొప్పించడం.

టైమ్‌స్కేల్‌డిబి

v 4.2 కోసం, మేము మా దృష్టిని TimescaleDB వైపు మళ్లించాము. ఇది స్థానిక ఇంటర్‌ఫేస్‌తో PostgreSQL కోసం పొడిగింపు. రిలేషనల్ డేటాబేస్ ప్రయోజనాలను కోల్పోకుండా, టైమ్ సిరీస్ డేటాతో ఎక్స్‌టెన్షన్ ప్రభావవంతంగా పనిచేస్తుంది. TimescaleDB కూడా స్వయంచాలకంగా విభజన చేస్తుంది.

TimescaleDBకి ఒక భావన ఉంది హైపర్ టేబుల్ (హైపర్ టేబుల్) మీరు సృష్టించినది. ఇది కలిగి ఉంది ముక్కలు - విభజనలు. భాగాలు స్వయంచాలకంగా నిర్వహించబడే హైపర్ టేబుల్ శకలాలు, ఇవి ఇతర శకలాలను ప్రభావితం చేయవు. ప్రతి భాగం దాని స్వంత సమయ పరిధిని కలిగి ఉంటుంది.

TimescaleDB vs PostgreSQL

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

200 మిలియన్ అడ్డు వరుసల తర్వాత, PostgreSQL సాధారణంగా గణనీయంగా కుంగిపోవడం ప్రారంభమవుతుంది మరియు పనితీరును 0కి కోల్పోతుంది. టైమ్‌స్కేల్‌DB మీరు ఎంత డేటా మొత్తానికి అయినా “ఇన్సర్ట్‌లను” సమర్ధవంతంగా చొప్పించడానికి అనుమతిస్తుంది.

సెట్టింగ్

టైమ్‌స్కేల్‌డిబిని ఇన్‌స్టాల్ చేయడం ఏదైనా ప్యాకేజీకి చాలా సులభం. IN డాక్యుమెంటేషన్ ప్రతిదీ వివరంగా వివరించబడింది - ఇది అధికారిక PostgreSQL ప్యాకేజీలపై ఆధారపడి ఉంటుంది. TimescaleDBని మాన్యువల్‌గా కూడా నిర్మించవచ్చు మరియు కంపైల్ చేయవచ్చు.

Zabbix డేటాబేస్ కోసం మేము కేవలం పొడిగింపును సక్రియం చేస్తాము:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

మీరు సక్రియం చేయండి extension మరియు Zabbix డేటాబేస్ కోసం దీన్ని సృష్టించండి. చివరి దశ హైపర్ టేబుల్‌ని సృష్టించడం.

టైమ్‌స్కేల్‌డిబికి చరిత్ర పట్టికలను తరలిస్తోంది

దీని కోసం ఒక ప్రత్యేక ఫంక్షన్ ఉంది create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

ఫంక్షన్ మూడు పారామితులను కలిగి ఉంటుంది. ప్రధమ - డేటాబేస్లో పట్టిక, దీని కోసం మీరు హైపర్ టేబుల్‌ని సృష్టించాలి. రెండవ - ఫీల్డ్, దీని ప్రకారం మీరు సృష్టించాలి chunk_time_interval - ఉపయోగించాల్సిన విభజన భాగాల విరామం. నా విషయంలో, విరామం ఒక రోజు - 86.

మూడవ పరామితి - migrate_data. మీరు సెట్ చేస్తే true, అప్పుడు మొత్తం ప్రస్తుత డేటా ముందుగా సృష్టించబడిన భాగాలకు బదిలీ చేయబడుతుంది. నేనే వాడాను migrate_data. నాకు దాదాపు 1 TB ఉంది, దీనికి గంటకు పైగా పట్టింది. కొన్ని సందర్భాల్లో కూడా, పరీక్ష సమయంలో, నిల్వ కోసం అవసరం లేని అక్షరాల రకాల చారిత్రక డేటాను నేను వాటిని బదిలీ చేయకుండా తొలగించాను.

చివరి దశ - UPDATE: వద్ద db_extension చాలు timescaledbతద్వారా ఈ పొడిగింపు ఉందని డేటాబేస్ అర్థం చేసుకుంటుంది. Zabbix దీన్ని సక్రియం చేస్తుంది మరియు డేటాబేస్‌కు వాక్యనిర్మాణం మరియు ప్రశ్నలను సరిగ్గా ఉపయోగిస్తుంది - TimescaleDBకి అవసరమైన ఆ లక్షణాలు.

హార్డ్‌వేర్ కాన్ఫిగరేషన్

నేను రెండు సర్వర్‌లను ఉపయోగించాను. ప్రధమ - VMware యంత్రం. ఇది చాలా చిన్నది: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz ప్రాసెసర్‌లు, 16 GB RAM మరియు 200 GB SSD.

నేను దానిపై Debian 10.8-10.8.pgdg1+90 OS మరియు xfs ఫైల్ సిస్టమ్‌తో PostgreSQL 1ని ఇన్‌స్టాల్ చేసాను. ఈ నిర్దిష్ట డేటాబేస్‌ని ఉపయోగించడానికి నేను అన్నింటినీ కనిష్టంగా కాన్ఫిగర్ చేసాను, Zabbix కూడా దేనిని ఉపయోగిస్తుందో మైనస్.

అదే మెషీన్‌లో Zabbix సర్వర్ ఉంది, PostgreSQL మరియు లోడ్ ఏజెంట్లు. నేను ఉపయోగిస్తున్న 50 క్రియాశీల ఏజెంట్లను కలిగి ఉన్నాను LoadableModuleచాలా త్వరగా విభిన్న ఫలితాలను రూపొందించడానికి: సంఖ్యలు, స్ట్రింగ్‌లు. నేను చాలా డేటాతో డేటాబేస్ నింపాను.

ప్రారంభంలో కాన్ఫిగరేషన్ కలిగి ఉంది 5 మూలకాలు ప్రతి హోస్ట్ డేటా. దాదాపు ప్రతి మూలకం నిజమైన ఇన్‌స్టాలేషన్‌లను పోలి ఉండేలా చేయడానికి ఒక ట్రిగ్గర్‌ను కలిగి ఉంటుంది. కొన్ని సందర్భాల్లో ఒకటి కంటే ఎక్కువ ట్రిగ్గర్‌లు ఉన్నాయి. ఒక నెట్‌వర్క్ నోడ్ కోసం ఉన్నాయి 3-000 ట్రిగ్గర్లు.

డేటా అంశం నవీకరణ విరామం − 4-7 సెకన్లు. నేను 50 ఏజెంట్లను మాత్రమే కాకుండా మరిన్నింటిని జోడించడం ద్వారా లోడ్‌ను నియంత్రించాను. అలాగే, డేటా ఎలిమెంట్‌లను ఉపయోగించి, నేను డైనమిక్‌గా లోడ్‌ని సర్దుబాటు చేసాను మరియు అప్‌డేట్ వ్యవధిని 4 సెకన్లకు తగ్గించాను.

PostgreSQL. 35 nvps

ఈ హార్డ్‌వేర్‌పై నా మొదటి పరుగు స్వచ్ఛమైన PostgreSQL - సెకనుకు 35 వేల విలువలు. మీరు చూడగలిగినట్లుగా, డేటాను చొప్పించడం సెకనులో భిన్నాలను తీసుకుంటుంది - ప్రతిదీ మంచిది మరియు వేగంగా ఉంటుంది. ఒకే విషయం ఏమిటంటే 200 GB SSD డిస్క్ త్వరగా నింపుతుంది.

ఇది ప్రామాణిక Zabbix సర్వర్ పనితీరు డాష్‌బోర్డ్.

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

నాల్గవ గ్రాఫ్ HistoryCache వినియోగాన్ని చూపుతుంది. డేటాబేస్‌లోకి చొప్పించే ముందు ఇది ఒక రకమైన బఫర్. ఆకుపచ్చ ఐదవ గ్రాఫ్ ValueCache వినియోగాన్ని చూపుతుంది, అంటే, ట్రిగ్గర్‌ల కోసం ఎన్ని ValueCache హిట్‌లు ఉన్నాయి - ఇది సెకనుకు అనేక వేల విలువలు.

PostgreSQL. 50 nvps

అప్పుడు నేను అదే హార్డ్‌వేర్‌లో సెకనుకు 50 వేల విలువలకు లోడ్‌ని పెంచాను.

హౌస్ కీపర్ నుండి లోడ్ చేస్తున్నప్పుడు, 10 వేల విలువలను చొప్పించడానికి 2-3 సెకన్లు పట్టింది.

హౌస్ కీపర్ ఇప్పటికే పనిలో జోక్యం చేసుకోవడం ప్రారంభించాడు.

మూడవ గ్రాఫ్ సాధారణంగా, ట్రాపర్స్ మరియు హిస్టరీ సింకర్‌లపై లోడ్ ఇప్పటికీ 60% వద్ద ఉందని చూపిస్తుంది. నాల్గవ గ్రాఫ్‌లో, హౌస్‌కీపర్ ఆపరేషన్ సమయంలో హిస్టరీకాష్ ఇప్పటికే చాలా చురుకుగా పూరించడం ప్రారంభించింది. ఇది 20% నిండింది, అంటే దాదాపు 0,5 GB.

PostgreSQL. 80 nvps

అప్పుడు నేను లోడ్‌ను సెకనుకు 80 వేల విలువలకు పెంచాను. ఇది సుమారు 400 వేల డేటా మూలకాలు మరియు 280 వేల ట్రిగ్గర్‌లు.

ముప్పై హిస్టరీ సింకర్‌ల లోడ్ ధర ఇప్పటికే చాలా ఎక్కువగా ఉంది.

నేను వివిధ పారామితులను కూడా పెంచాను: హిస్టరీ సింకర్‌లు, కాష్‌లు.

నా హార్డ్‌వేర్‌లో, హిస్టరీ సింకర్‌ల లోడ్ గరిష్టంగా పెరిగింది. HistoryCache త్వరగా డేటాతో నిండిపోయింది - ప్రాసెసింగ్ కోసం డేటా బఫర్‌లో సేకరించబడింది.

ఈ సమయంలో నేను ప్రాసెసర్, RAM మరియు ఇతర సిస్టమ్ పారామితులను ఎలా ఉపయోగించాలో గమనించాను మరియు డిస్క్ వినియోగం గరిష్టంగా ఉందని కనుగొన్నాను.

నేను ఉపయోగం సాధించాను గరిష్ట డిస్క్ సామర్థ్యాలు ఈ హార్డ్‌వేర్‌లో మరియు ఈ వర్చువల్ మెషీన్‌లో. అటువంటి తీవ్రతతో, PostgreSQL డేటాను చాలా చురుకుగా ఫ్లష్ చేయడం ప్రారంభించింది మరియు డిస్క్‌కు వ్రాయడానికి మరియు చదవడానికి సమయం లేదు.

రెండవ సర్వర్

నేను మరొక సర్వర్ తీసుకున్నాను, ఇది ఇప్పటికే 48 ప్రాసెసర్లు మరియు 128 GB RAM కలిగి ఉంది. నేను దానిని ట్యూన్ చేసాను - దానిని 60 హిస్టరీ సింకర్‌కి సెట్ చేసాను మరియు ఆమోదయోగ్యమైన పనితీరును సాధించాను.

వాస్తవానికి, ఇది ఇప్పటికే ఉత్పాదకత యొక్క పరిమితి, ఇక్కడ ఏదైనా చేయవలసి ఉంటుంది.

టైమ్‌స్కేల్DB. 80 nvps

Zabbix లోడ్‌కు వ్యతిరేకంగా TimescaleDB సామర్థ్యాలను పరీక్షించడం నా ప్రధాన పని. సెకనుకు 80 వేల విలువలు చాలా ఎక్కువ, కొలమానాలను సేకరించే ఫ్రీక్వెన్సీ (యాండెక్స్ మినహా) మరియు చాలా పెద్ద “సెటప్”.

ప్రతి గ్రాఫ్‌లో డిప్ ఉంది - ఇది ఖచ్చితంగా డేటా మైగ్రేషన్. Zabbix సర్వర్‌లో వైఫల్యాల తర్వాత, హిస్టరీ సింకర్ యొక్క లోడ్ ప్రొఫైల్ చాలా మారిపోయింది - ఇది మూడు సార్లు పడిపోయింది.

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

దీని ప్రకారం, మీరు సకాలంలో డేటాను అందుకుంటారు.

టైమ్‌స్కేల్DB. 120 nvps

అప్పుడు నేను డేటా మూలకాల సంఖ్యను 500 వేలకు పెంచాను, టైమ్‌స్కేల్‌డిబి యొక్క సామర్థ్యాలను పరీక్షించడం ప్రధాన పని - నేను సెకనుకు 125 వేల విలువలను పొందాను.

ఇది చాలా కాలం పాటు పని చేసే పని "సెటప్". కానీ నా డిస్క్ 1,5 TB మాత్రమే కాబట్టి, నేను దానిని రెండు రోజుల్లో నింపాను.

అతి ముఖ్యమైన విషయం ఏమిటంటే అదే సమయంలో కొత్త TimescaleDB విభజనలు సృష్టించబడ్డాయి.

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

ఉదాహరణగా, నేను సంఘంలోని చాలా మంది నుండి ఒక గ్రాఫ్‌ని చూపుతాను. చిత్రంలో, TimescaleDB ప్రారంభించబడింది, దీనికి ధన్యవాదాలు ప్రాసెసర్‌పై io.weightని ఉపయోగించడంపై లోడ్ తగ్గింది. అంతర్గత ప్రక్రియ మూలకాల వినియోగం కూడా తగ్గింది. అంతేకాకుండా, ఇది సాధారణ పాన్‌కేక్ డిస్క్‌లలోని సాధారణ వర్చువల్ మెషీన్, SSD కాదు.

కనుగొన్న

TimescaleDB చిన్న "సెటప్" కోసం ఒక మంచి పరిష్కారం, ఇది డిస్క్ పనితీరును ప్రభావితం చేస్తుంది. డేటాబేస్ వీలైనంత త్వరగా హార్డ్‌వేర్‌కు తరలించబడే వరకు ఇది బాగా పని చేయడం కొనసాగించడానికి మిమ్మల్ని అనుమతిస్తుంది.

TimescaleDB కాన్ఫిగర్ చేయడం సులభం, పనితీరు లాభాలను ఇస్తుంది, Zabbixతో బాగా పనిచేస్తుంది మరియు PostgreSQL కంటే ప్రయోజనాలను కలిగి ఉంది.

మీరు PostgreSQLని ఉపయోగిస్తుంటే మరియు దానిని మార్చడానికి ప్లాన్ చేయకపోతే, నేను సిఫార్సు చేస్తున్నాను Zabbixతో కలిపి TimescaleDB పొడిగింపుతో PostgreSQLని ఉపయోగించండి. ఈ పరిష్కారం మీడియం "సెటప్" వరకు ప్రభావవంతంగా పనిచేస్తుంది.

మేము "అధిక పనితీరు" అని చెప్పినప్పుడు మేము అర్థం హైలోడ్++. లక్షలాది మంది వినియోగదారులకు సేవలను అందించడానికి సేవలను ప్రారంభించే సాంకేతికతలు మరియు అభ్యాసాల గురించి తెలుసుకోవడానికి మీరు ఎక్కువ కాలం వేచి ఉండాల్సిన అవసరం లేదు. జాబితా నివేదికలు నవంబర్ 7 మరియు 8 కోసం మేము ఇప్పటికే సంకలనం చేసాము, కానీ ఇక్కడ సమావేశాలు మరింత సూచించవచ్చు.

మా సబ్స్క్రయిబ్ лкуылку и టెలిగ్రామ్, దీనిలో మేము రాబోయే కాన్ఫరెన్స్ యొక్క లక్షణాలను వెల్లడిస్తాము మరియు దాని నుండి అత్యధిక ప్రయోజనాలను ఎలా పొందాలో కనుగొనండి.

మూలం: www.habr.com