NoSQLలో డేటా, స్థిరత్వం మరియు విశ్వాసాన్ని కోల్పోకుండా కసాండ్రా కళ్ళలోకి ఎలా చూడాలి

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

కాసాండ్రా DBMS ఆధారంగా పరిష్కారాన్ని అమలు చేయడంలో మా అనుభవం గురించి నేను మీకు చెప్తాను: మనం ఏమి ఎదుర్కోవలసి వచ్చింది, క్లిష్ట పరిస్థితుల నుండి మనం ఎలా బయటపడ్డాము, NoSQLని ఉపయోగించడం ద్వారా మనం ప్రయోజనం పొందగలిగామా మరియు మేము అదనపు ప్రయత్నాలు/నిధులను ఎక్కడ పెట్టుబడి పెట్టాలి .
ఒక రకమైన నిల్వలో కాల్‌లను రికార్డ్ చేసే సిస్టమ్‌ను రూపొందించడం ప్రారంభ పని.

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

వారు కాసాండ్రాను ఎందుకు ఎంచుకున్నారనేది చాలా స్పష్టంగా ఉంది - ఆమె మెషిన్ గన్ లాగా వ్రాస్తుంది, సులభంగా స్కేలబుల్ మరియు తప్పులను తట్టుకుంటుంది.

కాబట్టి, ఇది మాకు అనుభవం ఇచ్చింది

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

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

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

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

మేము టెస్ట్ జోన్‌లకు డేటాను బదిలీ చేయడంలో సమస్యను ఎదుర్కొన్నాము (పరీక్షలో 5 నోడ్‌లు వర్సెస్ ప్రామ్‌లో 20). ఈ సందర్భంలో, డంప్ ఉపయోగించబడదు.

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

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

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

మేము ఎలా నిర్ణయించుకున్నాము

నోడ్ మునిగిపోకుండా నిరోధించడానికి, SWAP నిలిపివేయబడింది. మరియు ఇప్పుడు, మెమరీ లేకపోవడం ఉంటే, నోడ్ క్రిందికి వెళ్లాలి మరియు పెద్ద gc పాజ్‌లను సృష్టించకూడదు.

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

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

ఎంపిక ప్రశ్నలకు కాసాండ్రా చాలా సౌకర్యవంతంగా లేదని కూడా నేను గమనించాలనుకుంటున్నాను. వాస్తవానికి, CQL అనేది వినియోగదారులకు ఒక పెద్ద ముందడుగు (ట్రిఫ్ట్‌తో పోలిస్తే). కానీ మీరు అటువంటి అనుకూలమైన చేరికలకు అలవాటుపడిన మొత్తం విభాగాలను కలిగి ఉంటే, ఏదైనా ఫీల్డ్ ద్వారా ఉచిత ఫిల్టరింగ్ మరియు ఆప్టిమైజేషన్ సామర్థ్యాలను ప్రశ్నించడం మరియు ఈ విభాగాలు ఫిర్యాదులు మరియు ప్రమాదాలను పరిష్కరించడానికి కృషి చేస్తున్నట్లయితే, కాసాండ్రాపై పరిష్కారం వారికి ప్రతికూలంగా మరియు తెలివితక్కువదని అనిపిస్తుంది. మరియు మా సహోద్యోగులు నమూనాలను ఎలా తయారు చేయాలో మేము నిర్ణయించడం ప్రారంభించాము.

మేము రెండు ఎంపికలను పరిగణించాము. మొదటి ఎంపికలో, మేము C*లో మాత్రమే కాకుండా, ఆర్కైవ్ చేయబడిన Oracle డేటాబేస్‌లో కూడా కాల్‌లను వ్రాస్తాము. C* వలె కాకుండా, ఈ డేటాబేస్ ప్రస్తుత నెలలో మాత్రమే కాల్‌లను నిల్వ చేస్తుంది (కేసులను రీఛార్జ్ చేయడానికి తగినంత కాల్ నిల్వ లోతు). ఇక్కడ మేము వెంటనే క్రింది సమస్యను చూశాము: మేము సమకాలీకరణగా వ్రాస్తే, మేము వేగంగా చొప్పించడంతో అనుబంధించబడిన C* యొక్క అన్ని ప్రయోజనాలను కోల్పోతాము; మేము అసమకాలికంగా వ్రాస్తే, అవసరమైన అన్ని కాల్‌లు ఒరాకిల్‌లోకి వచ్చాయని ఎటువంటి హామీ లేదు. ఒక ప్లస్ ఉంది, కానీ పెద్దది: ఆపరేషన్ కోసం అదే సుపరిచితమైన PL/SQL డెవలపర్ మిగిలి ఉంది, అంటే మేము ఆచరణాత్మకంగా "ముఖభాగం" నమూనాను అమలు చేస్తాము. ప్రత్యామ్నాయ ఎంపిక. మేము C* నుండి కాల్‌లను అన్‌లోడ్ చేసే మెకానిజమ్‌ని అమలు చేస్తాము, Oracleలోని సంబంధిత పట్టికల నుండి సుసంపన్నం కోసం కొంత డేటాను లాగి, ఫలిత నమూనాలను చేర్చి, ఫలితాన్ని మాకు అందిస్తాము, దానిని మేము ఎలాగైనా ఉపయోగిస్తాము (వెనక్కి వెళ్లండి, పునరావృతం చేయండి, విశ్లేషించండి, ఆరాధించండి). కాన్స్: ప్రక్రియ చాలా బహుళ దశలు, మరియు అదనంగా, ఆపరేషన్ ఉద్యోగులకు ఇంటర్ఫేస్ లేదు.

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

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

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

కాసాండ్రా యొక్క నిరంతర లభ్యతను నిర్ధారించడానికి, మీకు dba అవసరం మరియు అతనికి మాత్రమే కాదు. అప్లికేషన్‌తో పనిచేసే ప్రతి ఒక్కరూ ప్రస్తుత పరిస్థితిని ఎక్కడ మరియు ఎలా చూడాలి మరియు సకాలంలో సమస్యలను ఎలా నిర్ధారించాలో అర్థం చేసుకోవాలి. దీన్ని చేయడానికి, మేము DataStax OpsCenter (పనిభారం యొక్క నిర్వహణ మరియు పర్యవేక్షణ), Cassandra డ్రైవర్ సిస్టమ్ మెట్రిక్‌లను చురుకుగా ఉపయోగిస్తాము (C*కి వ్రాయడానికి గడువు ముగిసే సమయాల సంఖ్య, C* నుండి చదవడానికి సమయం ముగిసే సమయాల సంఖ్య, గరిష్ట జాప్యం మొదలైనవి), ఆపరేషన్‌ని పర్యవేక్షిస్తాము. అప్లికేషన్ యొక్క స్వయంగా, కాసాండ్రాతో పని చేస్తుంది.

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

ఫలితంగా, ప్రస్తుతానికి చదవడం కోసం EACH_QUORUM రాయడం కోసం స్థిరత్వ స్థాయిలో ఆగిపోయింది - LOCAL_QUORUM

సంక్షిప్త ముద్రలు మరియు ముగింపులు

కార్యాచరణ మద్దతు మరియు తదుపరి అభివృద్ధికి అవకాశాల కోణం నుండి ఫలిత పరిష్కారాన్ని అంచనా వేయడానికి, అటువంటి అభివృద్ధిని ఎక్కడ ఉపయోగించవచ్చో ఆలోచించాలని మేము నిర్ణయించుకున్నాము.

బ్యాట్‌లోనే ఉండి, ఆపై “సౌకర్యవంతంగా ఉన్నప్పుడు చెల్లించండి” (మేము సమాచారాన్ని C*లోకి లోడ్ చేస్తాము, స్పార్క్ స్క్రిప్ట్‌లను ఉపయోగించి లెక్కింపు చేస్తాము), ప్రాంతం వారీగా అగ్రిగేషన్‌తో క్లెయిమ్‌లను లెక్కించడం, పాత్రలను నిల్వ చేయడం మరియు పాత్ర ఆధారంగా వినియోగదారు యాక్సెస్ హక్కులను గణించడం వంటి ప్రోగ్రామ్‌ల కోసం డేటా స్కోరింగ్ మాతృక.

మీరు చూడగలిగినట్లుగా, కచేరీలు విస్తృతంగా మరియు వైవిధ్యంగా ఉంటాయి. మరియు మేము NoSQL యొక్క మద్దతుదారులు/ప్రత్యర్థుల శిబిరాన్ని ఎంచుకుంటే, మేము మా ప్రయోజనాలను పొందాము మరియు మేము ఆశించిన చోటనే మేము మద్దతుదారులతో చేరుతాము.

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

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

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

డేటాబేస్ మరియు స్పార్క్ రెండింటినీ ఒకే నోడ్‌లలో ఉంచవద్దు (లేదా అనుమతించదగిన వనరుల వినియోగంతో ఖచ్చితంగా విభజించండి), ఎందుకంటే స్పార్క్ ఊహించిన దాని కంటే ఎక్కువ OPని తినగలదు మరియు మేము మా జాబితా నుండి త్వరగా సమస్య సంఖ్య 1ని పొందుతాము.

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

సాధ్యమైన ఆప్టిమైజేషన్ కోసం ఫలిత సర్క్యూట్‌ను అనేకసార్లు తిప్పండి. ఏ ఫీల్డ్‌లను సీరియలైజ్ చేయవచ్చో ఎంచుకోండి. అత్యంత సరిగ్గా మరియు ఉత్తమంగా పరిగణనలోకి తీసుకోవడానికి మనం ఏ అదనపు పట్టికలను తయారు చేయాలో అర్థం చేసుకోండి, ఆపై అభ్యర్థనపై అవసరమైన సమాచారాన్ని అందించండి (ఉదాహరణకు, మేము ఒకే డేటాను వేర్వేరు పట్టికలలో నిల్వ చేయగలమని భావించడం ద్వారా, వివిధ బ్రేక్‌డౌన్‌లను పరిగణనలోకి తీసుకుంటాము వివిధ ప్రమాణాలు, రీడ్ రిక్వెస్ట్‌ల కోసం మేము గణనీయంగా CPU సమయాన్ని ఆదా చేయవచ్చు).

చెడు కాదు TTLని జోడించడం మరియు పాత డేటాను క్లీన్ చేయడం కోసం తక్షణమే అందించండి.

కాసాండ్రా నుండి డేటాను డౌన్‌లోడ్ చేస్తున్నప్పుడు అప్లికేషన్ లాజిక్ FETCH సూత్రంపై పని చేయాలి, తద్వారా అన్ని అడ్డు వరుసలు ఒకేసారి మెమరీలోకి లోడ్ చేయబడవు, కానీ బ్యాచ్‌లలో ఎంపిక చేయబడతాయి.

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

మేము క్లిష్టమైన సమాచారంతో (బిల్లింగ్ కోసం డేటా, చందాదారుల రుణాన్ని లెక్కించడం వంటివి) పని చేస్తే, DBMS యొక్క లక్షణాల కారణంగా ఉత్పన్నమయ్యే నష్టాలను తగ్గించే సాధనాలపై కూడా శ్రద్ధ చూపడం విలువ. ఉదాహరణకు, nodesync యుటిలిటీ (డేటాస్టాక్స్) ఉపయోగించండి, క్రమంలో దాని ఉపయోగం కోసం సరైన వ్యూహాన్ని అభివృద్ధి చేసింది స్థిరత్వం కొరకు, కాసాండ్రాపై అధిక భారాన్ని సృష్టించవద్దు మరియు నిర్దిష్ట వ్యవధిలో నిర్దిష్ట పట్టికల కోసం మాత్రమే దీన్ని ఉపయోగించండి.

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

మూలం: www.habr.com