Redisకి [సంభావ్య] ప్రత్యామ్నాయంగా KeyDB

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

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

సమస్యలు

సాధారణంగా Redis గురించి

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

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

నేను ఈ లేదా ఆ అభిప్రాయాన్ని అంచనా వేయను. బదులుగా, నేను మా నిర్దిష్ట కేసును మరియు మేము దానిని ఎలా పరిష్కరించామో పంచుకుంటాను.

మా కేసు

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

వరుస లోడ్ పరీక్షల తర్వాత, మేము పరిస్థితిని విశ్లేషించాము మరియు Redis ఒక కోర్ ("షెల్ఫ్" అని పిలుస్తారు)కి పరిమితం చేయబడిందని కనుగొన్నాము, ఆ తర్వాత అప్లికేషన్ యొక్క వేగవంతమైన క్షీణత. "ఉక్కిరిబిక్కిరి చేయడం" ఘాతాంకం: రెడిస్ పనితీరు పరిమితిని చేరుకున్న వెంటనే, ప్రతిదీ పని చేయడం ఆగిపోయింది.

ఇది ఇలా కనిపిస్తుంది:

కొత్త రెలిక్ సమస్యను స్పష్టంగా గుర్తించింది:

ఆపరేషన్ కోసం గణాంకాలు ఇక్కడ ఉన్నాయి: get Redis లో:

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

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

KeyDB వద్ద త్వరిత వీక్షణ

సమస్యకు సాధ్యమైన పరిష్కారం కోసం చూస్తున్నప్పుడు, మేము కనుగొన్నాము KeyDB అనే అప్లికేషన్. ఇది అభివృద్ధి చేసిన రెడిస్ ఫోర్క్ కెనడియన్ కంపెనీ మరియు ఉచిత BSD లైసెన్స్ క్రింద పంపిణీ చేయబడుతుంది. ప్రాజెక్ట్ చాలా చిన్నది: ఇది 2019 ప్రారంభం నుండి ఉనికిలో ఉంది. దీని చరిత్ర ఏమిటంటే, రచయితలు కూడా ఒకప్పుడు రెడిస్ యొక్క పరిమితులను ఎదుర్కొన్నారు మరియు వారి స్వంత ఫోర్క్‌ను తయారు చేయాలని నిర్ణయించుకున్నారు. అంతేకాకుండా, ఇది తెలిసిన సమస్యలను పరిష్కరించడమే కాకుండా, Redis యొక్క Enterpise సంస్కరణలో మాత్రమే అందుబాటులో ఉన్న అదనపు లక్షణాలను కూడా పొందింది.

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

అన్నింటిలో మొదటిది, మా సమస్యలకు సంభావ్య పరిష్కారం ద్వారా మేము KeyDBకి ఆకర్షితులమయ్యాము మరియు అదే సమయంలో మేము కొన్ని అదనపు లక్షణాలపై ఆసక్తి కలిగి ఉన్నాము. KeyDBని ఉపయోగించడం వల్ల ఈ క్రింది ప్రయోజనాలు లభిస్తాయి:

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

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

వలస మరియు ఫలితాలు

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

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

టెస్టింగ్ ప్రారంభమైంది, ఇది ఒక వారం పాటు కొనసాగింది మరియు మేము డైవ్ చేయలేదు. PHP డ్రైవర్‌ని ఉపయోగించి Redisతో పనిచేసే ప్రామాణిక ఫంక్షన్‌లను కస్టమర్ పరీక్షించారని మాత్రమే మాకు తెలుసు phpredis, మరియు వినియోగదారు ఇంటర్‌ఫేస్ యొక్క QA పరీక్షను కూడా నిర్వహించింది. ఆ తర్వాత, మాకు గ్రీన్ లైట్ ఇవ్వబడింది: కొత్త సాఫ్ట్‌వేర్‌ను ఉపయోగించడంలో ఎటువంటి దుష్ప్రభావాలు కనుగొనబడలేదు. అంటే అప్లికేషన్ కోణం నుండి, ఏమీ మారలేదు.

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

వీటన్నింటికీ ధన్యవాదాలు, అప్లికేషన్‌ను కొత్త DBMSకి మార్చిన తర్వాత, మీరు దేనినీ మార్చలేరు, కానీ “స్థిరీకరణ కొలత”గా మీరు కొంత సమయం పాటు పోరాటంలో పని చేయడానికి ఈ రూపంలో వదిలివేయవచ్చు. అయితే, మీరు పనితీరు పెరుగుదల (లేదా ఏవైనా మార్పులు) చూడాలనుకుంటే, మీరు దానిని మర్చిపోకూడదు అప్రమేయంగా మల్టీథ్రెడింగ్‌కు బాధ్యత వహించే కీడిబి పరామితి (server-threads), ఒకదానికి సమానం, అంటే DBMS సరిగ్గా Redis వలె పనిచేస్తుంది.

కొత్త అప్లికేషన్‌లో (KeyDBతో) మారడం, పరీక్షించడం మరియు కొంత సమయం గడిపిన తర్వాత, మేము Redis కోసం ఉపయోగించిన అదే పారామితులతో లోడ్ పరీక్షను పునరావృతం చేయాలని నిర్ణయించుకున్నాము. దాని ఫలితాలు ఏమిటి?...

CPU వినియోగ గ్రాఫ్ ప్రకారం, ఒక కోర్ యొక్క “సీలింగ్” తో సమస్యలను తొలగించడం వెంటనే గుర్తించదగినది: ప్రక్రియ అందుబాటులో ఉన్న వనరులను ఉపయోగించడం ప్రారంభించింది:

ఆపై నేను అప్లికేషన్‌ను చాలా బలంగా "హింసించడానికి" ప్రయత్నించాను మరియు మూడు కోర్ల వరకు వినియోగాన్ని చూశాను...

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

కొత్త డేటాబేస్ (KeyDB) యొక్క జాప్యం కూడా మరింత దిగజారింది, కానీ ఆమోదయోగ్యమైన విలువల్లోనే ఉంది:

KeyDBకి అభ్యర్థనల సంఖ్య సమానంగా ఉందని క్రింది గ్రాఫ్ స్పష్టంగా చూపిస్తుంది:

ఈ సింథటిక్ పరీక్షలను సంగ్రహించేందుకు, సమాంతర కనెక్షన్‌ల (40+) సంఖ్యలో గణనీయమైన పెరుగుదలతో Redis మరియు KeyDB రెండూ జాప్యం (1000 ms+)లో గణనీయమైన పనితీరు క్షీణతను చూపుతాయని మేము చెప్పగలం. మా విషయంలో, వెబ్ అప్లికేషన్ రెడిస్ జాప్యాన్ని తక్కువ సంఖ్యలో కనెక్షన్‌లతో (400+) "వృధా" చేయగలిగింది, అయినప్పటికీ KeyDBకి అటువంటి లోడ్ ఆమోదయోగ్యమైనది.

కనుగొన్న

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

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

సాధారణంగా, KeyDB ఆశాజనకంగా కనిపిస్తుంది: మేము ఈ DBMSతో ఆచరణాత్మక అనుభవాన్ని పొందుతాము (మరియు మేము దానిని ఇంకా పొందవలసి ఉంది!) మరియు ప్రాజెక్ట్‌ను అభివృద్ధి చేయడం ద్వారా, మేము దానిని ఇతర పరిస్థితులలో ఉపయోగించగల అవకాశాన్ని పరిశీలిస్తాము.

ఏది ఏమైనప్పటికీ, ఈ కథనాన్ని KeyDBకి అనుకూలంగా Redis విస్తృతంగా వదిలివేయడం కోసం చర్య తీసుకోవడానికి ఒక మార్గదర్శిగా (కాల్ మాత్రమే కాకుండా) పరిగణించరాదు. మా సానుకూల అనుభవం ఉన్నప్పటికీ, ఇది వెండి బుల్లెట్ కాదని స్పష్టమైంది. కేసు చాలా నిర్దిష్టంగా ఉంది: ప్రత్యేకంగా త్వరగా మరియు తక్కువ ఖర్చుతో చేయాల్సిన పరిస్థితిలో క్షణిక సమస్యను పరిష్కరించడానికి, ఈ పరిష్కారం సమర్థించబడింది. మీ విషయంలో KeyDB ఉపయోగకరంగా ఉంటుందా? కనీసం ఇప్పుడు ఈ సంభావ్య అవకాశం ఉందని మీకు తెలుసు.

PS

మా బ్లాగులో కూడా చదవండి:

• «డేటాబేస్‌లు మరియు కుబెర్నెట్స్ (సమీక్ష మరియు వీడియో నివేదిక)";
• «కుబెర్నెటీస్‌కు కాసాండ్రా వలస: లక్షణాలు మరియు పరిష్కారాలు";
• «కుబెర్నెటీస్‌కు మొంగోడిబి యొక్క అతుకులు లేని వలస";
• «కుబెర్నెటీస్‌కు రాబిట్‌ఎమ్‌క్యూ అతుకులు లేని వలస".

మూలం: www.habr.com