NoSQL డేటాబేస్ యొక్క లక్షణాలు

2.1 NoSQL అనే పదం యొక్క ఆవిర్భావం

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

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

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

"NoSQL" అనే పదం పూర్తిగా ఆకస్మికమైనది మరియు దాని వెనుక సాధారణంగా ఆమోదించబడిన నిర్వచనం లేదా శాస్త్రీయ సంస్థ లేదని మరోసారి నొక్కి చెప్పడం విలువ. ఈ పేరు రిలేషనల్ డేటాబేస్‌లకు దూరంగా IT డెవలప్‌మెంట్ యొక్క వెక్టర్‌ను వర్ణిస్తుంది. No SQL యొక్క ప్రత్యక్ష నిర్వచనానికి మద్దతుదారులు ఉన్నప్పటికీ, ఇది SQL మాత్రమే కాదు. ప్రమోద్ సదలాజ్ మరియు మార్టిన్ ఫౌలర్ వారి ఇటీవలి పుస్తకం "NoSQL డిస్టిల్డ్"లో NoSQL ప్రపంచం గురించి జ్ఞానాన్ని సమూహపరచడానికి మరియు క్రమబద్ధీకరించడానికి ప్రయత్నించారు.

2.2 NoSQL డేటాబేస్ యొక్క ప్రాథమిక లక్షణాలు

అన్ని NoSQL కోసం కొన్ని సాధారణ లక్షణాలు ఉన్నాయి, ఎందుకంటే అనేక వైవిధ్య వ్యవస్థలు ఇప్పుడు NoSQL లేబుల్ క్రింద దాచబడ్డాయి (బహుశా అత్యంత పూర్తి జాబితాను http://nosql-database.org/లో కనుగొనవచ్చు). అనేక లక్షణాలు నిర్దిష్ట NoSQL డేటాబేస్‌లకు మాత్రమే విచిత్రంగా ఉంటాయి, జాబితా చేసేటప్పుడు నేను దీన్ని ఖచ్చితంగా ప్రస్తావిస్తాను.

1. SQL ఉపయోగించబడదు

నా ఉద్దేశ్యం ANSI SQL DML, ఎందుకంటే చాలా డేటాబేస్‌లు బాగా తెలిసిన ఇష్టమైన సింటాక్స్‌కు సమానమైన ప్రశ్న భాషలను ఉపయోగించడానికి ప్రయత్నిస్తాయి, కానీ ఎవరూ దానిని పూర్తిగా అమలు చేయలేకపోయారు మరియు విజయవంతం అయ్యే అవకాశం లేదు. SQLని అమలు చేయడానికి ప్రయత్నిస్తున్న పుకారు స్టార్టప్‌లు ఉన్నప్పటికీ, ఉదాహరణకు హడప్‌లో ( http://www.drawntoscalehq.com/ మరియు http://www.hadapt.com/ ).

2. నిర్మాణాత్మకం (స్కీమాలెస్)

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

ఉదాహరణకు, MongoDBలో ఫీల్డ్ పేరు మార్చేటప్పుడు:

BasicDBObject order = new BasicDBObject();
order.put("date", orderDate); // this field was a long time ago
order.put("totalSum", total); // before we just used "sum"

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

మొదటిది అన్ని పత్రాలను క్రాల్ చేయడం మరియు ఇప్పటికే ఉన్న అన్ని పత్రాలలో ఈ ఫీల్డ్‌ను నవీకరించడం. డేటా పరిమాణం కారణంగా, ఈ ప్రక్రియ ఎటువంటి లాక్‌లు లేకుండా జరుగుతుంది (ఆల్టర్ టేబుల్ రీనేమ్ కాలమ్ కమాండ్‌తో పోల్చవచ్చు), కాబట్టి నవీకరణ సమయంలో, ఇప్పటికే ఉన్న డేటాను ఇతర ప్రక్రియల ద్వారా చదవవచ్చు. కాబట్టి, రెండవ ఎంపిక - అప్లికేషన్ కోడ్‌లో తనిఖీ చేయడం - అనివార్యం:

BasicDBObject order = new BasicDBObject();
Double totalSum = order.getDouble("sum"); // This is the old model
if (totalSum  == null)
totalSum = order.getDouble("totalSum"); // This is the updated model

మరియు ఇప్పటికే మేము మళ్లీ రికార్డ్ చేసినప్పుడు, మేము ఈ ఫీల్డ్‌ను డేటాబేస్‌కు కొత్త ఆకృతిలో వ్రాస్తాము.

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

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

(ఇకపై, మేము ప్రధానంగా కీ-విలువ, పత్రం మరియు కాలమ్-కుటుంబ డేటాబేస్‌ల గురించి మాట్లాడుతున్నాము, గ్రాఫ్ డేటాబేస్‌లు ఈ లక్షణాలను కలిగి ఉండకపోవచ్చు)

2.3 సముదాయాల రూపంలో డేటా ప్రాతినిధ్యం (సంకలనాలు)

సాధారణీకరణ ప్రయోజనాల కోసం అప్లికేషన్ యొక్క లాజికల్ బిజినెస్ ఎంటిటీని వివిధ భౌతిక పట్టికలలో నిల్వ చేసే రిలేషనల్ మోడల్ కాకుండా, NoSQL స్టోర్‌లు ఈ ఎంటిటీలపై సంపూర్ణ వస్తువులుగా పనిచేస్తాయి:

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

చాలా మంది అభ్యంతరం వ్యక్తం చేస్తారు, పెద్ద, తరచుగా డీనార్మలైజ్ చేయబడిన, ఆబ్జెక్ట్‌లతో పని చేయడం అనేది డేటాపై ఏకపక్ష ప్రశ్నలను ప్రయత్నించినప్పుడు అనేక సమస్యలతో నిండి ఉంటుంది, ప్రశ్నలు కంకరల నిర్మాణానికి సరిపోవు. మేము ఆర్డర్ లైన్ ఐటెమ్‌లు మరియు పేమెంట్‌లతో పాటు ఆర్డర్‌లను ఉపయోగిస్తే (యాప్ ఈ విధంగా పనిచేస్తుంది), అయితే గత నెలలో నిర్దిష్ట ఉత్పత్తికి చెందిన ఎన్ని యూనిట్లు విక్రయించబడిందో లెక్కించమని వ్యాపారం మమ్మల్ని అడుగుతుంది? ఈ సందర్భంలో, OrderItem పట్టికను స్కాన్ చేయడానికి బదులుగా (రిలేషనల్ మోడల్ విషయంలో), మేము మొత్తం ఆర్డర్‌లను NoSQL నిల్వలో తిరిగి పొందవలసి ఉంటుంది, అయినప్పటికీ మాకు ఈ సమాచారం చాలా అవసరం లేదు. దురదృష్టవశాత్తూ, ఇది పంపిణీ చేయబడిన సిస్టమ్‌లో చేయవలసిన రాజీ: మేము సాంప్రదాయ సింగిల్-సర్వర్ సిస్టమ్‌లో వలె డేటాను సాధారణీకరించలేము,

నేను పట్టికలో రెండు విధానాల యొక్క లాభాలు మరియు నష్టాలను సమూహపరచడానికి ప్రయత్నించాను: