6.1 సంక్షిప్తాల యుద్ధం: BASE vs. ఆమ్లము
|
"కెమిస్ట్రీలో, pH సజల ద్రావణం యొక్క సాపేక్ష ఆమ్లతను కొలుస్తుంది. pH స్కేల్ 0 (బలమైన ఆమ్ల పదార్థాలు) నుండి 14 (బలమైన ఆల్కలీన్ పదార్థాలు) వరకు నడుస్తుంది; 25 ° C వద్ద స్వచ్ఛమైన నీరు 7 pH కలిగి ఉంటుంది మరియు తటస్థంగా ఉంటుంది. లావాదేవీల విశ్వసనీయతకు సంబంధించిన డేటాబేస్‌లను పోల్చడానికి డేటా ఇంజనీర్లు ఈ రూపకాన్ని తీసుకున్నారు." బహుశా, ఆలోచన ఇది: pH ఎక్కువ, అనగా. డేటాబేస్ "ఆల్కలీన్" ("BASE")కి దగ్గరగా ఉంటే, లావాదేవీలు తక్కువ విశ్వసనీయంగా ఉంటాయి. |
MySQL వంటి ప్రసిద్ధ రిలేషనల్ డేటాబేస్‌లు కేవలం ACID ఆధారంగా కనిపించాయి. కానీ గత పదేళ్లలో, ఈ పేరుతో చాలా విభిన్న రకాల డేటాబేస్‌లను మిళితం చేసే NoSQL డేటాబేస్‌లు, ACID లేకుండా చాలా బాగా పనిచేశాయి. వాస్తవానికి, NoSQL డేటాబేస్‌లతో పనిచేసే డెవలపర్‌లు పెద్ద సంఖ్యలో ఉన్నారు మరియు లావాదేవీలు మరియు వాటి విశ్వసనీయత గురించి అస్సలు పట్టించుకోరు. అవి సరైనవో కాదో చూద్దాం.
మీరు NoSQL డేటాబేస్ గురించి సాధారణంగా మాట్లాడలేరు, ఎందుకంటే ఇది మంచి సంగ్రహణ మాత్రమే. NoSQL డేటాబేస్‌లు డేటా స్టోరేజ్ సబ్‌సిస్టమ్‌ల రూపకల్పనలో మరియు డేటా మోడల్‌లలో కూడా ఒకదానికొకటి భిన్నంగా ఉంటాయి: NoSQL అనేది డాక్యుమెంట్-ఓరియెంటెడ్ CouchDB మరియు గ్రాఫ్ Neo4J రెండూ. కానీ మేము లావాదేవీల సందర్భంలో వాటి గురించి మాట్లాడినట్లయితే, అవన్నీ ఒక విషయంలో సమానంగా ఉంటాయి: అవి పరమాణుత్వం మరియు ఐసోలేషన్ యొక్క పరిమిత సంస్కరణలను అందిస్తాయి మరియు అందువల్ల ACID హామీలను అందించవు. దీని అర్థం ఏమిటో అర్థం చేసుకోవడానికి, ప్రశ్నకు సమాధానమివ్వండి: ACID కాకపోతే వారు ఏమి అందిస్తారు? ఏమిలేదు?
నిజంగా కాదు. అన్నింటికంటే, వారు, రిలేషనల్ డేటాబేస్‌ల వలె, తమను తాము అందమైన ప్యాకేజీలో విక్రయించాలి. మరియు వారు తమ స్వంత "రసాయన" సంక్షిప్తీకరణతో ముందుకు వచ్చారు - BASE.
6.2 BASE విరోధిగా
మరియు ఇక్కడ మళ్ళీ నేను అక్షరాల క్రమంలో వెళ్ళను, కానీ నేను ప్రాథమిక పదంతో ప్రారంభిస్తాను - స్థిరత్వం. నేను మీ గుర్తింపు ప్రభావాన్ని సమం చేయాల్సి ఉంటుంది, ఎందుకంటే ఈ స్థిరత్వానికి ACID నుండి స్థిరత్వంతో సంబంధం లేదు. స్థిరత్వం అనే పదానికి సంబంధించిన సమస్య ఏమిటంటే అది చాలా సందర్భాలలో ఉపయోగించబడుతుంది. కానీ ఈ అనుగుణ్యత ఉపయోగం యొక్క విస్తృత సందర్భాన్ని కలిగి ఉంది మరియు వాస్తవానికి ఇది పంపిణీ వ్యవస్థలను చర్చించేటప్పుడు చర్చించబడే స్థిరత్వం.
మేము పైన మాట్లాడిన రిలేషనల్ డేటాబేస్‌లు వివిధ స్థాయిల లావాదేవీల ఐసోలేషన్‌ను అందిస్తాయి మరియు వాటిలో అత్యంత కఠినమైనవి ఒక లావాదేవీ మరొక లావాదేవీ ద్వారా చేసిన చెల్లని మార్పులను చూడకుండా చూస్తాయి. మీరు దుకాణంలో చెక్అవుట్ వద్ద నిలబడి, ఆ సమయంలో అద్దెకు డబ్బు మీ ఖాతా నుండి ఉపసంహరించబడితే, కానీ అద్దెకు డబ్బు బదిలీతో లావాదేవీ విఫలమైతే మరియు మీ ఖాతా దాని మునుపటి విలువకు తిరిగి వస్తుంది (డబ్బు డెబిట్ చేయబడలేదు), అప్పుడు చెక్అవుట్‌లో మీ చెల్లింపు లావాదేవీ ప్రతి ఒక్కరూ ఈ సంజ్ఞలను గమనించదు - అన్నింటికంటే, ఆ లావాదేవీ ఎప్పుడూ జరగలేదు మరియు లావాదేవీ ఐసోలేషన్ యొక్క ఆవశ్యకత ఆధారంగా, దాని తాత్కాలిక మార్పులు ఇతర లావాదేవీల ద్వారా గమనించబడవు.
అనేక NoSQL డేటాబేస్‌లు ఐసోలేషన్ గ్యారెంటీని విస్మరించి, "చివరికి అనుగుణ్యత"ని అందిస్తాయి, దీని ద్వారా మీరు చివరికి చెల్లుబాటు అయ్యే డేటాను చూస్తారు, కానీ మీ లావాదేవీ చెల్లని విలువలను చదివే అవకాశం ఉంది - అంటే తాత్కాలికం లేదా పాక్షికంగా నవీకరించబడింది లేదా పాతది. చదివేటప్పుడు డేటా "లేజీ" మోడ్‌లో స్థిరంగా మారే అవకాశం ఉంది ("చదువుతున్న సమయంలో సోమరితనం").
NoSQL నిజ-సమయ విశ్లేషణల కోసం డేటాబేస్‌గా రూపొందించబడింది మరియు ఎక్కువ వేగాన్ని సాధించడానికి, వారు స్థిరత్వాన్ని త్యాగం చేశారు. మరియు ఎరిక్ బ్రూవర్, BASE అనే పదాన్ని రూపొందించిన అదే వ్యక్తి, "CAP సిద్ధాంతం" అని పిలవబడే సూత్రాన్ని రూపొందించాడు, దీని ప్రకారం:
పంపిణీ చేయబడిన కంప్యూటింగ్ యొక్క ఏదైనా అమలు కోసం, కింది మూడు లక్షణాలలో రెండు కంటే ఎక్కువ అందించడం సాధ్యం కాదు:
- డేటా అనుగుణ్యత ( స్థిరత్వం ) - వేర్వేరు నోడ్‌లలోని డేటా (ఉదాహరణలు) ఒకదానికొకటి విరుద్ధంగా ఉండవు;
- లభ్యత ( లభ్యత ) - పంపిణీ చేయబడిన సిస్టమ్‌కు ఏదైనా అభ్యర్థన సరైన ప్రతిస్పందనతో ముగుస్తుంది, అయితే అన్ని సిస్టమ్ నోడ్‌ల ప్రతిస్పందనలు ఒకేలా ఉంటాయని హామీ లేకుండా;
- విభజన సహనం (విభజన సహనం ) - నోడ్‌ల మధ్య ఎటువంటి సంబంధం లేకపోయినా, అవి ఒకదానికొకటి స్వతంత్రంగా పని చేస్తూనే ఉంటాయి.
మీకు CAP గురించి చాలా సులభమైన వివరణ కావాలంటే, ఇక్కడ మీరు వెళ్ళండి.
CAP సిద్ధాంతం పని చేయదని అభిప్రాయాలు ఉన్నాయి మరియు సాధారణంగా చాలా నైరూప్యంగా రూపొందించబడింది. ఒక మార్గం లేదా మరొక విధంగా, NoSQL డేటాబేస్‌లు తరచుగా CAP సిద్ధాంతం యొక్క సందర్భంలో స్థిరత్వాన్ని నిరాకరిస్తాయి, ఇది క్రింది పరిస్థితిని వివరిస్తుంది: డేటా అనేక సందర్భాల్లో క్లస్టర్‌లో నవీకరించబడింది, అయితే మార్పులు ఇంకా అన్ని సందర్భాల్లో సమకాలీకరించబడలేదు. గుర్తుంచుకోండి, నేను పైన పేర్కొన్న DynamoDB ఉదాహరణను పేర్కొన్నాను, అది నాకు చెప్పింది: మీ మార్పులు మన్నికైనవిగా మారాయి - ఇదిగో మీ కోసం HTTP 200 - కానీ నేను మార్పులను 10 సెకన్ల తర్వాత మాత్రమే చూశాను? డెవలపర్ యొక్క రోజువారీ జీవితంలో మరొక ఉదాహరణ DNS, డొమైన్ నేమ్ సిస్టమ్. ఎవరికైనా తెలియకపోతే, ఇది ఖచ్చితంగా http (లు) చిరునామాలను IP చిరునామాలుగా అనువదించే “నిఘంటువు”.
నవీకరించబడిన DNS రికార్డ్ కాషింగ్ ఇంటర్వెల్ సెట్టింగ్‌ల ప్రకారం సర్వర్‌లకు ప్రచారం చేయబడుతుంది - కాబట్టి నవీకరణలు వెంటనే గుర్తించబడవు. సరే, రిలేషనల్ డేటాబేస్ క్లస్టర్‌కి (అంటే, MySQL) ఇదే విధమైన తాత్కాలిక అస్థిరత (అంటే, చివరికి స్థిరత్వం) సంభవించవచ్చు - అన్నింటికంటే, ఈ స్థిరత్వానికి ACID నుండి స్థిరత్వంతో సంబంధం లేదు. అందువల్ల, ఈ కోణంలో, క్లస్టర్‌లోని అనేక సందర్భాలకు వచ్చినప్పుడు SQL మరియు NoSQL డేటాబేస్‌లు చాలా భిన్నంగా ఉండే అవకాశం లేదని అర్థం చేసుకోవడం ముఖ్యం.
అదనంగా, ఎండ్-టు-ఎండ్ అనుగుణ్యత అంటే వ్రాత అభ్యర్థనలు క్రమం లేకుండా చేయబడతాయని అర్థం: అంటే, మొత్తం డేటా వ్రాయబడుతుంది, కానీ చివరికి స్వీకరించే విలువ రైట్ క్యూలో చివరిది కాదు. .
నాన్-ACID NoSQL డేటాబేస్‌లు ఎండ్-టు-ఎండ్ స్థిరత్వ నమూనా కారణంగా "సాఫ్ట్ స్టేట్" అని పిలవబడేవి, అంటే ఇన్‌పుట్ లేకుండా కూడా సిస్టమ్ స్థితి కాలక్రమేణా మారవచ్చు. కానీ అలాంటి వ్యవస్థలు ఎక్కువ ప్రాప్యతను అందించడానికి ప్రయత్నిస్తాయి. 100% లభ్యతను అందించడం అనేది ఒక చిన్న పని కాదు, కాబట్టి మేము "ప్రాథమిక లభ్యత" గురించి మాట్లాడుతున్నాము. మరియు ఈ మూడు భావనలు కలిసి: “ప్రాథమికంగా అందుబాటులో”, “సాఫ్ట్ స్టేట్” (“సాఫ్ట్ స్టేట్”) మరియు “చివరికి అనుగుణ్యత” BASE అనే సంక్షిప్త రూపాన్ని ఏర్పరుస్తాయి.
నిజం చెప్పాలంటే, BASE అనే భావన నాకు ACID కంటే ఎక్కువ ఖాళీ మార్కెటింగ్ రేపర్‌గా అనిపిస్తుంది - ఎందుకంటే ఇది కొత్తది ఏమీ ఇవ్వదు మరియు డేటాబేస్ను ఏ విధంగానూ వర్గీకరించదు. మరియు నిర్దిష్ట డేటాబేస్‌లకు లేబుల్‌లను (ACID, BASE, CAP) జోడించడం డెవలపర్‌లను మాత్రమే గందరగోళానికి గురి చేస్తుంది. నేను ఈ పదాన్ని ఏమైనప్పటికీ మీకు పరిచయం చేయాలని నిర్ణయించుకున్నాను, ఎందుకంటే డేటాబేస్ను అధ్యయనం చేస్తున్నప్పుడు దాన్ని దాటవేయడం కష్టం, కానీ ఇప్పుడు అది ఏమిటో మీకు తెలుసు, మీరు వీలైనంత త్వరగా దాని గురించి మరచిపోవాలని నేను కోరుకుంటున్నాను. మరియు ఐసోలేషన్ భావనకు తిరిగి వెళ్దాం.
6.3 కాబట్టి BASE డేటాబేస్‌లు ACID ప్రమాణాలకు అనుగుణంగా లేవా?
ముఖ్యంగా, ACID డేటాబేస్‌లు నాన్-ACIDల నుండి విభిన్నంగా ఉన్న చోట నాన్-ACIDలు నిజానికి ఐసోలేషన్‌ను వదులుకుంటాయి. ఇది అర్థం చేసుకోవడం ముఖ్యం. కానీ డేటాబేస్ డాక్యుమెంటేషన్‌ను చదవడం మరియు హెర్మిటేజ్ ప్రాజెక్ట్‌లోని అబ్బాయిలు చేసే విధంగా వాటిని పరీక్షించడం మరింత ముఖ్యం. ACID లేదా BASE, CAP లేదా CAP కాదా - ఈ లేదా ఆ డేటాబేస్ యొక్క సృష్టికర్తలు వారి మెదడును ఎలా పిలుస్తారనేది అంత ముఖ్యమైనది కాదు. ముఖ్యమైన విషయం ఏమిటంటే ఈ లేదా ఆ డేటాబేస్ సరిగ్గా ఏమి అందిస్తుంది.
డేటాబేస్ సృష్టికర్తలు ఇది ACID హామీలను అందిస్తుందని క్లెయిమ్ చేస్తే, దీనికి బహుశా ఒక కారణం ఉండవచ్చు, అయితే ఇది అలా ఉందో లేదో మరియు ఎంతవరకు ఉందో అర్థం చేసుకోవడానికి మీరే పరీక్షించుకోవడం మంచిది. వారి డేటాబేస్ అటువంటి హామీలను అందించదని వారు ప్రకటిస్తే, దీని అర్థం క్రింది విషయాలు కావచ్చు:
-
DB పరమాణుత్వానికి ఎటువంటి హామీని ఇవ్వదు. కొన్ని NoSQL డేటాబేస్‌లు పరమాణు కార్యకలాపాల కోసం ప్రత్యేక APIని అందిస్తాయి (ఉదా. DynamoDB);
- DB ఏ ఐసోలేషన్ హామీని అందించదు. ఉదాహరణకు, డేటాబేస్ వారు వ్రాసిన క్రమంలో డేటాను వ్రాయదని దీని అర్థం.
మన్నిక హామీ విషయానికొస్తే, పనితీరు కోసం అనేక డేటాబేస్‌లు ఈ పాయింట్‌పై రాజీ పడతాయి. డిస్క్‌కి వ్రాయడం చాలా సుదీర్ఘమైన పని, మరియు ఈ సమస్యను పరిష్కరించడానికి అనేక మార్గాలు ఉన్నాయి. నేను డేటాబేస్ సిద్ధాంతంలోకి పెద్దగా వెళ్లాలనుకోవడం లేదు, కానీ మీరు ఏ విధంగా చూడాలో దాదాపుగా అర్థం చేసుకునేలా, వివిధ డేటాబేస్‌లు మన్నికతో సమస్యను ఎలా పరిష్కరిస్తాయో నేను సాధారణ పరంగా వివరిస్తాను.
విభిన్న డేటాబేస్‌లను సరిపోల్చడానికి, ఇతర విషయాలతోపాటు, నిర్దిష్ట డేటాబేస్ యొక్క డేటా నిల్వ మరియు పునరుద్ధరణ ఉపవ్యవస్థలో ఏ డేటా స్ట్రక్చర్‌లు ఆధారపడి ఉన్నాయో మీరు తెలుసుకోవాలి. సంక్షిప్తంగా: విభిన్న డేటాబేస్‌లు ఇండెక్సింగ్ యొక్క విభిన్న అమలులను కలిగి ఉంటాయి - అంటే, డేటాకు ప్రాప్యతను నిర్వహించడం. వాటిలో కొన్ని డేటాను వేగంగా వ్రాయడానికి మిమ్మల్ని అనుమతిస్తాయి, మరికొన్ని - వేగంగా చదవడానికి. కానీ కొన్ని డేటా స్ట్రక్చర్‌లు మన్నికను ఎక్కువ లేదా తక్కువ చేస్తాయి అని సాధారణంగా చెప్పలేము.
6.4 వివిధ డేటాబేస్ ఇండెక్స్ డేటా మరియు ఇది మన్నికను ఎలా ప్రభావితం చేస్తుంది మరియు మరిన్ని
డేటాను నిల్వ చేయడానికి మరియు తిరిగి పొందడానికి రెండు ప్రధాన విధానాలు ఉన్నాయి.
డేటాను సేవ్ చేయడానికి సులభమైన మార్గం ఏమిటంటే, లాగ్-వంటి పద్ధతిలో ఫైల్ ముగింపుకు ఆపరేషన్‌లను జోడించడం (అంటే, అనుబంధ ఆపరేషన్ ఎల్లప్పుడూ జరుగుతుంది): మనం డేటాను జోడించాలనుకున్నా, మార్చాలనుకున్నా లేదా తొలగించాలనుకున్నా పర్వాలేదు - అన్నీ CRUD కార్యకలాపాలు కేవలం లాగ్‌కు వ్రాయబడతాయి. లాగ్‌ను శోధించడం అసమర్థమైనది మరియు ఇక్కడే సూచిక వస్తుంది - డేటా ఎక్కడ నిల్వ చేయబడిందనే దాని గురించి మెటాడేటాను నిల్వ చేసే ప్రత్యేక డేటా నిర్మాణం. లాగ్‌ల కోసం సరళమైన ఇండెక్సింగ్ వ్యూహం కీలు మరియు విలువలను ట్రాక్ చేసే హాష్ మ్యాప్. విలువలు ఫైల్ లోపల వ్రాసిన డేటా కోసం బైట్ ఆఫ్‌సెట్‌కు సూచనలుగా ఉంటాయి, ఇది లాగ్ (లాగ్) మరియు డిస్క్‌లో నిల్వ చేయబడుతుంది. ఈ డేటా నిర్మాణం పూర్తిగా మెమరీలో నిల్వ చేయబడుతుంది, అయితే డేటా డిస్క్‌లో ఉంటుంది మరియు దీనిని LSM ట్రీ (లాగ్ స్ట్రక్చర్డ్ మెర్జ్) అంటారు.
మీరు బహుశా ఆశ్చర్యపోయారు: మేము మా కార్యకలాపాలను ఎప్పటికప్పుడు పత్రికకు వ్రాస్తే, అది విపరీతంగా పెరుగుతుందా? అవును, అందువల్ల కాంపాక్షన్ టెక్నిక్ కనుగొనబడింది, ఇది డేటాను కొంత ఆవర్తనతతో "క్లీన్ చేస్తుంది", అనగా, ప్రతి కీకి అత్యంత సంబంధిత విలువను మాత్రమే వదిలివేస్తుంది లేదా దానిని తొలగిస్తుంది. మరియు మేము డిస్క్‌లో ఒకటి కంటే ఎక్కువ లాగ్‌లను కలిగి ఉంటే, కానీ అవి అన్నీ క్రమబద్ధీకరించబడి ఉంటే, అప్పుడు మేము SSTable (“క్రమబద్ధీకరించబడిన స్ట్రింగ్ టేబుల్”) అనే కొత్త డేటా నిర్మాణాన్ని పొందుతాము మరియు ఇది నిస్సందేహంగా మా పనితీరును మెరుగుపరుస్తుంది. మేము మెమరీలో క్రమబద్ధీకరించాలనుకుంటే, మేము ఇదే విధమైన నిర్మాణాన్ని పొందుతాము - అని పిలవబడే MemTable, కానీ దానితో సమస్య ఏమిటంటే, ప్రాణాంతక డేటాబేస్ క్రాష్ సంభవించినట్లయితే, చివరిగా వ్రాసిన డేటా (MemTableలో ఉంది, కానీ ఇంకా వ్రాయబడలేదు. డిస్క్) పోతుంది. నిజానికి,
ఇండెక్సింగ్‌కు మరొక విధానం B-ట్రీస్ ("B-ట్రీస్")పై ఆధారపడి ఉంటుంది. B-ట్రీలో, డేటా స్థిర సైజు పేజీలలో డిస్క్‌కి వ్రాయబడుతుంది. ఈ డేటా బ్లాక్‌లు తరచుగా 4 KB పరిమాణంలో ఉంటాయి మరియు కీ-విలువ జతలను కీ ద్వారా క్రమబద్ధీకరించబడతాయి. ఒక B-ట్రీ నోడ్ అనేది పేజీల పరిధికి లింక్‌లతో కూడిన శ్రేణి లాంటిది. గరిష్టంగా శ్రేణిలోని లింక్‌ల సంఖ్యను బ్రాంచ్ ఫ్యాక్టర్ అంటారు. ప్రతి పేజీ పరిధి ఇతర పేజీ పరిధులకు లింక్‌లతో మరొక B-ట్రీ నోడ్.
చివరికి, షీట్ స్థాయిలో, మీరు వ్యక్తిగత పేజీలను కనుగొంటారు. ఈ ఆలోచన తక్కువ-స్థాయి ప్రోగ్రామింగ్ భాషలలోని పాయింటర్‌ల మాదిరిగానే ఉంటుంది, ఈ పేజీ సూచనలు మెమరీలో కాకుండా డిస్క్‌లో నిల్వ చేయబడతాయి. డేటాబేస్‌లో ఇన్‌సర్ట్‌లు మరియు డిలీట్‌లు సంభవించినప్పుడు, బ్రాంకింగ్ ఫ్యాక్టర్‌తో సరిపోలడానికి కొన్ని నోడ్‌లు రెండు సబ్‌ట్రీలుగా విడిపోతాయి. ప్రాసెస్ మధ్యలో ఏదైనా కారణం చేత డేటాబేస్ విఫలమైతే, డేటా యొక్క సమగ్రత రాజీపడవచ్చు. ఇది జరగకుండా నిరోధించడానికి, B-ట్రీలను ఉపయోగించే డేటాబేస్‌లు "వ్రైట్-ఎహెడ్ లాగ్" లేదా WALను నిర్వహిస్తాయి, దీనిలో ప్రతి ఒక్క లావాదేవీ రికార్డ్ చేయబడుతుంది. B-ట్రీ పాడైపోయినట్లయితే దాని స్థితిని పునరుద్ధరించడానికి ఈ WAL ఉపయోగించబడుతుంది. మరియు మన్నిక పరంగా B-ట్రీలను ఉపయోగించే డేటాబేస్‌లను మెరుగ్గా చేస్తుంది. కానీ LSM-ఆధారిత డేటాబేస్‌లు తప్పనిసరిగా WAL వలె అదే పనితీరును చేసే ఫైల్‌ను కూడా నిర్వహించగలవు. అందువల్ల, నేను ఇప్పటికే చెప్పినదాన్ని పునరావృతం చేస్తాను మరియు బహుశా ఒకటి కంటే ఎక్కువసార్లు: మీరు ఎంచుకున్న డేటాబేస్ యొక్క ఆపరేషన్ యొక్క విధానాలను అర్థం చేసుకోండి.
అయితే, B-ట్రీల గురించి ఖచ్చితంగా చెప్పాల్సిన విషయం ఏమిటంటే, అవి లావాదేవీలకు మంచివి: ప్రతి కీ సూచికలో ఒకే చోట మాత్రమే ఉంటుంది, అయితే జర్నల్డ్ స్టోరేజ్ సబ్‌సిస్టమ్‌లు ఒకే కీ యొక్క బహుళ కాపీలను వేర్వేరు షార్డ్‌లలో కలిగి ఉంటాయి (ఉదాహరణకు, వరకు తదుపరి సంపీడనం నిర్వహిస్తారు).
అయితే, సూచిక రూపకల్పన నేరుగా డేటాబేస్ పనితీరును ప్రభావితం చేస్తుంది. LSM ట్రీతో, డిస్క్‌కి వ్రాసేవి వరుసగా ఉంటాయి మరియు B-ట్రీలు బహుళ యాదృచ్ఛిక డిస్క్ యాక్సెస్‌లకు కారణమవుతాయి, కాబట్టి B-ట్రీలతో కంటే LSMతో వ్రాత కార్యకలాపాలు వేగంగా ఉంటాయి. మాగ్నెటిక్ హార్డ్ డిస్క్ డ్రైవ్‌లకు (HDDలు) వ్యత్యాసం ముఖ్యంగా ముఖ్యమైనది, ఇక్కడ యాదృచ్ఛికంగా వ్రాసే వాటి కంటే సీక్వెన్షియల్ రైట్‌లు చాలా వేగంగా ఉంటాయి. LSM చెట్లపై పఠనం నెమ్మదిగా ఉంటుంది, ఎందుకంటే మీరు వివిధ డేటా స్ట్రక్చర్‌లు మరియు SS టేబుల్‌ల ద్వారా వివిధ దశల్లో ఉండే కాంపాక్షన్‌ను చూడాలి. మరింత వివరంగా ఇది ఇలా కనిపిస్తుంది. మేము LSMతో ఒక సాధారణ డేటాబేస్ ప్రశ్నను చేస్తే, మేము ముందుగా MemTableలో కీని చూస్తాము. అది అక్కడ లేకుంటే, మేము ఇటీవలి SSTableని చూస్తాము; అక్కడ లేకపోతే, మేము చివరి SSTable మరియు మొదలైనవాటిని చూస్తాము. అభ్యర్థించిన కీ ఉనికిలో లేకుంటే, LSMతో మనకు ఇది చివరిగా తెలుస్తుంది. LSM ట్రీలు ఉపయోగించబడతాయి, ఉదాహరణకు: LevelDB, RocksDB, Cassandra మరియు HBase.
నేను అన్నింటినీ చాలా వివరంగా వివరిస్తాను, తద్వారా మీరు డేటాబేస్ను ఎన్నుకునేటప్పుడు, మీరు అనేక విభిన్న విషయాలను పరిగణించాలని అర్థం చేసుకుంటారు: ఉదాహరణకు, మీరు డేటాను మరింత రాయాలని లేదా చదవాలని భావిస్తున్నారా. మరియు నేను డేటా మోడల్‌లలోని వ్యత్యాసాన్ని ఇంకా పేర్కొనలేదు (గ్రాఫ్ మోడల్ అనుమతించినట్లుగా మీరు డేటాను దాటాల్సిన అవసరం ఉందా? మీ డేటాలోని వివిధ యూనిట్ల మధ్య ఏవైనా సంబంధాలు ఉన్నాయా - అప్పుడు రిలేషనల్ డేటాబేస్‌లు రక్షించబడతాయి?), మరియు 2 రకాల డేటా స్కీమాలు - వ్రాసేటప్పుడు (అనేక NoSQL లాగా) మరియు చదివేటప్పుడు (రిలేషనల్ వలె).
మేము మన్నిక యొక్క అంశానికి తిరిగి వస్తే, ముగింపు ఈ క్రింది విధంగా ఉంటుంది: ఇండెక్సింగ్ మెకానిజమ్‌లతో సంబంధం లేకుండా డిస్క్‌కి వ్రాసే ఏదైనా డేటాబేస్ మీ డేటా యొక్క మన్నికకు మంచి హామీలను అందిస్తుంది, కానీ మీరు ప్రతి నిర్దిష్ట డేటాబేస్‌తో వ్యవహరించాలి. , ఇది ఖచ్చితంగా ఏమి అందిస్తుంది.
6.5 ఇన్-మెమరీ DBలు ఎలా పని చేస్తాయి
మార్గం ద్వారా, డిస్క్‌కు వ్రాసే డేటాబేస్‌లతో పాటు, ప్రధానంగా RAMతో పనిచేసే "ఇన్-మెమరీ" డేటాబేస్‌లు కూడా ఉన్నాయి. సంక్షిప్తంగా, ఇన్-మెమరీ డేటాబేస్‌లు సాధారణంగా వేగంగా వ్రాయడం మరియు చదవడం వేగం కోసం తక్కువ మన్నికను అందిస్తాయి, అయితే ఇది కొన్ని అనువర్తనాలకు తగినది కావచ్చు.
వాస్తవం ఏమిటంటే RAM మెమరీ చాలా కాలంగా డిస్క్‌ల కంటే ఖరీదైనది, కానీ ఇటీవల ఇది వేగంగా చౌకగా మారడం ప్రారంభించింది, ఇది కొత్త రకం డేటాబేస్‌కు దారితీసింది - ఇది తార్కికంగా ఉంటుంది, RAM నుండి డేటాను చదవడం మరియు వ్రాయడం యొక్క వేగం కారణంగా. కానీ మీరు సరిగ్గా అడుగుతారు: ఈ డేటాబేస్‌ల డేటా భద్రత గురించి ఏమిటి? ఇక్కడ మళ్ళీ, మీరు అమలు వివరాలను చూడాలి. సాధారణంగా, అటువంటి డేటాబేస్‌ల డెవలపర్‌లు ఈ క్రింది విధానాలను అందిస్తారు:
- మీరు బ్యాటరీల ద్వారా నడిచే RAMని ఉపయోగించవచ్చు;
- మార్పు లాగ్‌లను డిస్క్‌కి వ్రాయడం సాధ్యమవుతుంది (పైన పేర్కొన్న WALల వంటిది), కానీ డేటా కాదు;
- మీరు క్రమానుగతంగా డిస్క్‌కి డేటాబేస్ స్థితి యొక్క కాపీలను వ్రాయవచ్చు (ఇది ఇతర ఎంపికలను ఉపయోగించకుండా, హామీని ఇవ్వదు, కానీ మన్నికను మాత్రమే మెరుగుపరుస్తుంది);
- మీరు RAM స్థితిని ఇతర యంత్రాలకు ప్రతిరూపం చేయవచ్చు.
ఉదాహరణకు, మెసేజ్ క్యూ లేదా కాష్‌గా ప్రధానంగా ఉపయోగించబడే ఇన్-మెమరీ Redis డేటాబేస్, ACID నుండి మన్నికను కలిగి ఉండదు: Redis డేటాను డిస్క్‌కి ఫ్లష్ చేస్తుంది కాబట్టి విజయవంతంగా అమలు చేయబడిన కమాండ్ డిస్క్‌లో నిల్వ చేయబడుతుందని ఇది హామీ ఇవ్వదు (మీరు అయితే నిలకడ ఎనేబుల్ చెయ్యబడి) మాత్రమే అసమకాలికంగా, క్రమ వ్యవధిలో.
అయితే, ఇది అన్ని అప్లికేషన్‌లకు కీలకం కాదు: ఈథర్‌ప్యాడ్ కోఆపరేటివ్ ఆన్‌లైన్ ఎడిటర్ యొక్క ఉదాహరణను నేను కనుగొన్నాను, ఇది ప్రతి 1-2 సెకన్లకు ఫ్లష్ అవుతుంది మరియు వినియోగదారు రెండు అక్షరాలు లేదా పదాలను కోల్పోవచ్చు, ఇది చాలా క్లిష్టమైనది కాదు. లేకపోతే, ఇన్-మెమరీ డేటాబేస్‌లు మంచివి కాబట్టి అవి డిస్క్ ఇండెక్స్‌లతో అమలు చేయడం కష్టంగా ఉండే డేటా మోడల్‌లను అందిస్తాయి, లావాదేవీలను అమలు చేయడానికి Redisని ఉపయోగించవచ్చు - దీని ప్రాధాన్యత క్యూ దీన్ని చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.