ఆధునిక సమాచార వ్యవస్థలు చాలా క్లిష్టమైనవి. అన్నింటికంటే తక్కువ కాదు, వాటి సంక్లిష్టత వాటిలో ప్రాసెస్ చేయబడిన డేటా యొక్క సంక్లిష్టత కారణంగా ఉంటుంది. డేటా సంక్లిష్టత తరచుగా ఉపయోగించే వివిధ డేటా మోడల్‌లలో ఉంటుంది. కాబట్టి, ఉదాహరణకు, డేటా "పెద్దది" అయినప్పుడు, సమస్యాత్మక లక్షణాలలో ఒకటి దాని వాల్యూమ్ ("వాల్యూమ్"), కానీ దాని వైవిధ్యం ("వైవిధ్యం") మాత్రమే.
మీరు ఇంకా తార్కికంలో లోపాన్ని కనుగొనలేకపోతే, చదవండి.
కంటెంట్
బహుభాషా పట్టుదల
పైన పేర్కొన్నది కొన్నిసార్లు ఒక సిస్టమ్ యొక్క ఫ్రేమ్‌వర్క్‌లో కూడా డేటాను నిల్వ చేయడానికి మరియు వాటిని ప్రాసెస్ చేయడంలో వివిధ సమస్యలను పరిష్కరించడానికి అనేక విభిన్న DBMSలను ఉపయోగించడం అవసరం, వీటిలో ప్రతి ఒక్కటి దాని స్వంత డేటా మోడల్‌కు మద్దతు ఇస్తుంది. M. ఫౌలర్ యొక్క తేలికపాటి చేతితో, అనేక ప్రసిద్ధ పుస్తకాలు మరియు వాటిలో ఒకటి ఎజైల్ మ్యానిఫెస్టో, ఈ పరిస్థితి అంటారు బహుళ-వైవిధ్య నిల్వ ("బహుభాషా పట్టుదల").
ఫౌలర్ ఈ-కామర్స్ రంగంలో పూర్తి-ఫీచర్ చేయబడిన మరియు అధిక-లోడ్ అప్లికేషన్‌లో డేటా నిల్వను నిర్వహించడానికి క్రింది ఉదాహరణను కూడా కలిగి ఉంది.
ఈ ఉదాహరణ, వాస్తవానికి, కొంత అతిశయోక్తి, కానీ సంబంధిత ప్రయోజనం కోసం ఒకటి లేదా మరొక DBMS ఎంచుకోవడానికి అనుకూలంగా కొన్ని పరిగణనలు కనుగొనవచ్చు, ఉదాహరణకు, .
అలాంటి జంతుప్రదర్శనశాలలో సేవకుడిగా ఉండటం అంత సులభం కాదని స్పష్టమైంది.
- డేటా నిల్వను నిర్వహించే కోడ్ మొత్తం ఉపయోగించిన DBMSల సంఖ్యకు అనులోమానుపాతంలో పెరుగుతుంది; కోడ్ సింక్రొనైజింగ్ డేటా మొత్తం ఈ సంఖ్య యొక్క వర్గానికి అనులోమానుపాతంలో లేకపోతే మంచిది.
- ఉపయోగించిన DBMSల సంఖ్యకు బహుళంగా, ఉపయోగించిన ప్రతి DBMSల యొక్క ఎంటర్‌ప్రైజ్ లక్షణాలను (స్కేలబిలిటీ, ఫాల్ట్ టాలరెన్స్, అధిక లభ్యత) అందించే ఖర్చులు పెరుగుతాయి.
- మొత్తంగా స్టోరేజ్ సబ్‌సిస్టమ్ యొక్క ఎంటర్‌ప్రైజ్ లక్షణాలను నిర్ధారించడం అసాధ్యం - ముఖ్యంగా లావాదేవీ.
జూ డైరెక్టర్ దృక్కోణం నుండి, ప్రతిదీ ఇలా కనిపిస్తుంది:
- DBMS తయారీదారు నుండి లైసెన్స్‌లు మరియు సాంకేతిక మద్దతు ధరలో బహుళ పెరుగుదల.
- అధిక సిబ్బంది మరియు పెరిగిన గడువులు.
- డేటా అస్థిరత కారణంగా ప్రత్యక్ష ఆర్థిక నష్టాలు లేదా జరిమానాలు.
సిస్టమ్ యాజమాన్యం యొక్క మొత్తం ఖర్చు (TCO)లో గణనీయమైన పెరుగుదల ఉంది. "బహుళ నిల్వ ఎంపికల" పరిస్థితి నుండి ఏదైనా మార్గం ఉందా?
బహుళ మోడల్
"మల్టీవియారిట్ స్టోరేజ్" అనే పదం 2011లో వాడుకలోకి వచ్చింది. విధానం యొక్క సమస్యలపై అవగాహన మరియు పరిష్కారం కోసం అన్వేషణ చాలా సంవత్సరాలు పట్టింది మరియు 2015 నాటికి, గార్ట్‌నర్ విశ్లేషకుల నోటి ద్వారా, సమాధానం రూపొందించబడింది:
- నుండి "»:
DBMSల భవిష్యత్తు, వాటి నిర్మాణాలు మరియు వాటిని ఉపయోగించే మార్గాలు బహుళ నమూనా.
- నుండి "»:
ప్రముఖ కార్యాచరణ DBMSలు ఒకే ప్లాట్‌ఫారమ్‌లో భాగంగా బహుళ మోడళ్లను-సంబంధిత మరియు నాన్-రిలేషనల్-ని అందిస్తాయి.
ఈసారి గార్ట్‌నర్ విశ్లేషకులు వారి అంచనాతో సరిగ్గా ఉన్నట్లు తెలుస్తోంది. తో పేజీకి వెళితే DB-ఇంజిన్‌లపై DBMS, మీరు దానిని చూడవచ్చుоదానిలోని చాలా మంది నాయకులు తమను తాము ప్రత్యేకంగా మల్టీ-మోడల్ DBMSలుగా ఉంచుకుంటారు. ఏదైనా ప్రైవేట్ రేటింగ్ ఉన్న పేజీలో అదే చూడవచ్చు.
దిగువన ఉన్న పట్టిక DBMSని చూపుతుంది - ప్రతి ప్రైవేట్ రేటింగ్‌లోని లీడర్‌లు, అవి బహుళ-మోడల్ అని చెప్పుకుంటాయి. ప్రతి DBMS కోసం, అసలైన మద్దతు ఉన్న మోడల్ (ఒకప్పుడు ఇది ఒక్కటే) మరియు దానితో పాటు ప్రస్తుతం మద్దతు ఉన్న మోడల్‌లు సూచించబడతాయి. "వాస్తవానికి బహుళ-మోడల్"గా తమను తాము ఉంచుకునే DBMSలు కూడా జాబితా చేయబడ్డాయి మరియు సృష్టికర్తల ప్రకారం, ఏ ప్రారంభ వారసత్వ నమూనాను కలిగి ఉండవు.
| DBMS | ప్రారంభ నమూనా | అదనపు నమూనాలు |
|---|---|---|
| ఒరాకిల్ | రిలేషనల్ | గ్రాఫ్, డాక్యుమెంట్ |
| MS SQL | రిలేషనల్ | గ్రాఫ్, డాక్యుమెంట్ |
| PostgreSQL | రిలేషనల్ | గ్రాఫ్*, పత్రం |
| మార్క్ లాజిక్ | డాక్యుమెంటరీ | గ్రాఫ్, రిలేషనల్ |
| MongoDB | డాక్యుమెంటరీ | కీలక విలువ, గ్రాఫ్* |
| డేటాస్టాక్స్ | విస్తృత కాలమ్ | డాక్యుమెంటరీ, గ్రాఫ్ |
| Redis | కీ-విలువ | డాక్యుమెంటరీ, గ్రాఫ్* |
| అరంగోడిబి | - | గ్రాఫ్, డాక్యుమెంట్ |
| OrientDB | - | గ్రాఫ్, డాక్యుమెంట్, రిలేషనల్ |
| అజూర్ కాస్మోస్డిబి | - | గ్రాఫ్, డాక్యుమెంట్, రిలేషనల్ |
టేబుల్ మీద నోట్స్
టేబుల్‌లోని ఆస్టరిస్క్‌లు రిజర్వేషన్‌లు అవసరమయ్యే స్టేట్‌మెంట్‌లను సూచిస్తాయి:
- PostgreSQL DBMS గ్రాఫ్ డేటా మోడల్‌కు మద్దతు ఇవ్వదు, కానీ ఈ ఉత్పత్తి దానికి మద్దతు ఇస్తుంది , AgensGraph వంటివి.
- MongoDBకి సంబంధించి, ప్రశ్న భాషలో గ్రాఫ్ ఆపరేటర్ల ఉనికి గురించి మాట్లాడటం మరింత సరైనది (, ) గ్రాఫ్ మోడల్‌కు మద్దతు ఇవ్వడం కంటే, అయితే, వారి పరిచయం గ్రాఫ్ మోడల్‌కు మద్దతు ఇచ్చే దిశలో భౌతిక నిల్వ స్థాయిలో కొన్ని ఆప్టిమైజేషన్లు అవసరం.
- Redisకి సంబంధించి, మేము పొడిగింపు అని అర్థం .
తర్వాత, ప్రతి తరగతికి, ఈ తరగతి నుండి DBMSలో అనేక మోడల్‌లకు మద్దతు ఎలా అమలు చేయబడుతుందో మేము చూపుతాము. మేము రిలేషనల్, డాక్యుమెంట్ మరియు గ్రాఫ్ మోడల్‌లను అత్యంత ముఖ్యమైనవిగా పరిగణిస్తాము మరియు "తప్పిపోయినవి" ఎలా అమలు చేయబడతాయో చూపించడానికి నిర్దిష్ట DBMSల ఉదాహరణలను ఉపయోగిస్తాము.
రిలేషనల్ మోడల్ ఆధారంగా మల్టీ-మోడల్ DBMS
ప్రస్తుతం ప్రముఖ DBMSలు రిలేషనల్‌గా ఉన్నాయి; RDBMSలు మల్టీ-మోడలింగ్ దిశలో కదలికను చూపకపోతే గార్ట్‌నర్ సూచన నిజమని పరిగణించబడదు. మరియు వారు ప్రదర్శిస్తారు. ఇప్పుడు మల్టీ-మోడల్ DBMS అనేది స్విస్ నైఫ్ లాంటిది, అది ఏమీ బాగా చేయలేకపోవడాన్ని నేరుగా లారీ ఎల్లిసన్‌కు పంపవచ్చు.
రచయిత, అయితే, మైక్రోసాఫ్ట్ SQL సర్వర్‌లో బహుళ-మోడలింగ్ అమలును ఇష్టపడతారు, దీని ఉదాహరణలో డాక్యుమెంట్ మరియు గ్రాఫ్ మోడల్‌లకు RDBMS మద్దతు వివరించబడుతుంది.
MS SQL సర్వర్‌లో డాక్యుమెంట్ మోడల్
డాక్యుమెంట్ మోడల్‌కు MS SQL సర్వర్ మద్దతును ఎలా అమలు చేస్తుందనే దాని గురించి హాబ్రేపై ఇప్పటికే రెండు అద్భుతమైన కథనాలు వచ్చాయి; నేను సంక్షిప్త రీటెల్లింగ్ మరియు వ్యాఖ్యానానికి పరిమితం చేస్తాను:
MS SQL సర్వర్‌లో డాక్యుమెంట్ మోడల్‌కు మద్దతు ఇచ్చే మార్గం రిలేషనల్ DBMSలకు చాలా విలక్షణమైనది: JSON పత్రాలు సాధారణ టెక్స్ట్ ఫీల్డ్‌లలో నిల్వ చేయడానికి ప్రతిపాదించబడ్డాయి. ఈ JSONని అన్వయించడానికి ప్రత్యేక ఆపరేటర్‌లను అందించడం డాక్యుమెంట్ మోడల్‌కు మద్దతు:
- స్కేలార్ అట్రిబ్యూట్ విలువలను సంగ్రహించడానికి,
- ఉప పత్రాలను సంగ్రహించడానికి.
రెండు ఆపరేటర్ల యొక్క రెండవ వాదన JSONPath-వంటి సింటాక్స్‌లోని వ్యక్తీకరణ.
వియుక్తంగా, ఈ విధంగా నిల్వ చేయబడిన పత్రాలు టుపుల్స్ వలె కాకుండా రిలేషనల్ DBMSలో "ఫస్ట్-క్లాస్ ఎంటిటీలు" కాదని మనం చెప్పగలం. ప్రత్యేకంగా, MS SQL సర్వర్‌లో ప్రస్తుతం JSON డాక్యుమెంట్‌ల ఫీల్డ్‌లలో ఇండెక్స్‌లు లేవు, ఈ ఫీల్డ్‌ల విలువలను ఉపయోగించి టేబుల్‌లలో చేరడం కష్టతరం చేస్తుంది మరియు ఈ విలువలను ఉపయోగించి పత్రాలను కూడా ఎంచుకోవచ్చు. అయితే, అటువంటి ఫీల్డ్ కోసం లెక్కించిన నిలువు వరుసను మరియు దానిపై సూచికను సృష్టించడం సాధ్యమవుతుంది.
అదనంగా, MS SQL సర్వర్ ఆపరేటర్‌ని ఉపయోగించి పట్టికలలోని విషయాల నుండి JSON పత్రాన్ని సౌకర్యవంతంగా నిర్మించగల సామర్థ్యాన్ని అందిస్తుంది. - ఒక అవకాశం, ఒక నిర్దిష్ట కోణంలో, మునుపటి దానికి విరుద్ధంగా, సంప్రదాయ నిల్వ. RDBMS ఎంత వేగవంతమైనదైనా, ఈ విధానం డాక్యుమెంట్ DBMSల భావజాలానికి విరుద్ధంగా ఉందని స్పష్టంగా తెలుస్తుంది, ఇది తప్పనిసరిగా జనాదరణ పొందిన ప్రశ్నలకు సిద్ధంగా ఉన్న సమాధానాలను నిల్వ చేస్తుంది మరియు అభివృద్ధి యొక్క సౌలభ్యం సమస్యలను మాత్రమే పరిష్కరించగలదు, కానీ వేగం కాదు.
చివరగా, MS SQL సర్వర్ డాక్యుమెంట్ నిర్మాణం యొక్క విలోమ సమస్యను పరిష్కరించడానికి మిమ్మల్ని అనుమతిస్తుంది: మీరు ఉపయోగించి JSONని పట్టికలుగా విడదీయవచ్చు . పత్రం పూర్తిగా ఫ్లాట్ కాకపోతే, మీరు ఉపయోగించాల్సి ఉంటుంది CROSS APPLY.
MS SQL సర్వర్‌లో గ్రాఫ్ మోడల్
గ్రాఫ్ (LPG) మోడల్‌కు మద్దతు Microsoft SQL సర్వర్‌లో కూడా పూర్తిగా అమలు చేయబడింది : నోడ్‌లను నిల్వ చేయడానికి మరియు గ్రాఫ్ అంచులను నిల్వ చేయడానికి ప్రత్యేక పట్టికలను ఉపయోగించాలని ప్రతిపాదించబడింది. ఇటువంటి పట్టికలు వ్యక్తీకరణలను ఉపయోగించి సృష్టించబడతాయి CREATE TABLE AS NODE и CREATE TABLE AS EDGE వరుసగా.
మొదటి రకం పట్టికలు రికార్డ్‌లను నిల్వ చేయడానికి సాధారణ పట్టికల మాదిరిగానే ఉంటాయి, బాహ్య వ్యత్యాసం ఏమిటంటే టేబుల్ సిస్టమ్ ఫీల్డ్‌ను కలిగి ఉంటుంది. $node_id — డేటాబేస్‌లోని గ్రాఫ్ నోడ్ యొక్క ప్రత్యేక ఐడెంటిఫైయర్.
అదేవిధంగా, రెండవ రకం పట్టికలు సిస్టమ్ ఫీల్డ్‌లను కలిగి ఉంటాయి $from_id и $to_id, అటువంటి పట్టికలలోని ఎంట్రీలు నోడ్‌ల మధ్య కనెక్షన్‌లను స్పష్టంగా నిర్వచించాయి. ప్రతి రకమైన సంబంధాలను నిల్వ చేయడానికి ప్రత్యేక పట్టిక ఉపయోగించబడుతుంది.
దీనిని ఒక ఉదాహరణతో ఉదహరిద్దాం. గ్రాఫ్ డేటా చిత్రంలో చూపిన విధంగా లేఅవుట్‌ను కలిగి ఉండనివ్వండి. డేటాబేస్లో సంబంధిత నిర్మాణాన్ని సృష్టించడానికి మీరు క్రింది DDL ప్రశ్నలను అమలు చేయాలి:
CREATE TABLE Person (
ID INTEGER NOT NULL,
name VARCHAR(100)
) AS NODE;
CREATE TABLE Cafe (
ID INTEGER NOT NULL,
name VARCHAR(100),
) AS NODE;
CREATE TABLE likes (
rating INTEGER
) AS EDGE;
CREATE TABLE friendOf
AS EDGE;
ALTER TABLE likes
ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe);అటువంటి పట్టికల యొక్క ప్రధాన విశిష్టత ఏమిటంటే, వాటికి వ్యతిరేకంగా ఉన్న ప్రశ్నలలో సైఫర్-వంటి సింటాక్స్‌తో గ్రాఫ్ నమూనాలను ఉపయోగించడం సాధ్యమవుతుంది (అయితే, "*"మొదలైనవి ఇంకా మద్దతు ఇవ్వలేదు). పనితీరు కొలతల ఆధారంగా, ఈ పట్టికలలో డేటా నిల్వ చేయబడే విధానం సాధారణ పట్టికలలో డేటా నిల్వ చేయబడే విధానానికి భిన్నంగా ఉంటుందని మరియు అటువంటి గ్రాఫ్ ప్రశ్నలను అమలు చేయడానికి ఆప్టిమైజ్ చేయబడిందని కూడా భావించవచ్చు.
SELECT Cafe.name
FROM Person, likes, Cafe
WHERE MATCH (Person-(friendOf)-(likes)->Cafe)
AND Person.name = 'John';అంతేకాకుండా, అటువంటి పట్టికలతో పనిచేసేటప్పుడు ఈ గ్రాఫ్ నమూనాలను ఉపయోగించకుండా ఉండటం చాలా కష్టం, ఎందుకంటే ఇలాంటి సమస్యలను పరిష్కరించడానికి సాధారణ SQL ప్రశ్నలలో సిస్టమ్ "గ్రాఫ్" నోడ్ ఐడెంటిఫైయర్లను పొందేందుకు అదనపు ప్రయత్నాలు చేయవలసి ఉంటుంది ($node_id, $from_id, $to_id; అదే కారణంగా, డేటాను చొప్పించడం కోసం ప్రశ్నలు అనవసరంగా గజిబిజిగా ఉన్నందున ఇక్కడ చూపబడవు).
MS SQL సర్వర్‌లోని డాక్యుమెంట్ మరియు గ్రాఫ్ మోడల్‌ల అమలుల వివరణను సంగ్రహించేందుకు, ఒక మోడల్‌పై మరొక మోడల్‌ని అమలు చేయడం విజయవంతం కాదని నేను గమనించాను, ప్రధానంగా భాష రూపకల్పన కోణం నుండి. ఒక భాషను మరొక భాషతో విస్తరించడం అవసరం, భాషలు పూర్తిగా “ఆర్తోగోనల్” కావు, అనుకూలత నియమాలు చాలా విచిత్రంగా ఉంటాయి.
డాక్యుమెంట్ మోడల్ ఆధారంగా బహుళ-మోడల్ DBMS
ఈ విభాగంలో, డాక్యుమెంట్ DBMSలలో బహుళ-మోడల్ అమలును నేను వివరించాలనుకుంటున్నాను, వాటిలో అత్యంత ప్రజాదరణ లేని MongoDB (చెప్పినట్లు, ఇది షరతులతో కూడిన గ్రాఫ్ ఆపరేటర్‌లను మాత్రమే కలిగి ఉంది $lookup и $graphLookup, భాగమైన సేకరణలపై పని చేయడం లేదు), కానీ మరింత పరిణతి చెందిన మరియు "ఎంటర్‌ప్రైజ్" DBMS యొక్క ఉదాహరణను ఉపయోగించడం .
కాబట్టి, సేకరణ క్రింది రకం XML పత్రాల సమితిని కలిగి ఉండనివ్వండి (JSON పత్రాలను నిల్వ చేయడానికి MarkLogic మిమ్మల్ని అనుమతిస్తుంది):
<Person INN="631803299804">
<name>John</name>
<surname>Smith</surname>
</Person>మార్క్‌లాజిక్‌లో రిలేషనల్ మోడల్
పత్రాల సేకరణ యొక్క సంబంధిత వీక్షణను ఉపయోగించి సృష్టించవచ్చు (మూలకాల యొక్క కంటెంట్ value దిగువ ఉదాహరణలో ఏకపక్ష XPath ఉండవచ్చు):
<template >
<context>/Person</context>
<rows>
<row>
<view-name>Person</view-name>
<columns>
<column>
<name>SSN</name>
<value>@SSN</value>
<type>string</type>
</column>
<column>
<name>name</name>
<value>name</value>
</column>
<column>
<name>surname</name>
<value>surname</value>
</column>
</columns>
</row>
<rows>
</template>మీరు సృష్టించిన వీక్షణను SQL ప్రశ్నతో పరిష్కరించవచ్చు (ఉదాహరణకు, ODBC ద్వారా):
SELECT name, surname FROM Person WHERE name="John"దురదృష్టవశాత్తు, ప్రదర్శన టెంప్లేట్ ద్వారా సృష్టించబడిన రిలేషనల్ వీక్షణ చదవడానికి మాత్రమే. దాని కోసం అభ్యర్థనను ప్రాసెస్ చేస్తున్నప్పుడు, MarkLogic ఉపయోగించడానికి ప్రయత్నిస్తుంది . ఇంతకుముందు, మార్క్‌లాజిక్ పూర్తిగా పరిమిత రిలేషనల్ వీక్షణలను కలిగి ఉంది మరియు వ్రాయదగినవి, కానీ ఇప్పుడు అవి తిరస్కరించబడినవిగా పరిగణించబడుతున్నాయి.
మార్క్‌లాజిక్‌లో గ్రాఫ్ మోడల్
గ్రాఫ్ (RDF) మోడల్‌కు మద్దతుతో, ప్రతిదీ దాదాపు ఒకే విధంగా ఉంటుంది. మళ్ళీ సహాయంతో మీరు ఎగువ ఉదాహరణ నుండి పత్రాల సేకరణ యొక్క RDF ప్రాతినిధ్యాన్ని సృష్టించవచ్చు:
<template >
<context>/Person</context>
<vars>
<var>
<name>PREFIX</name>
<val>"http://example.org/example#"</val>
</var>
</vars>
<triples>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || surname )</value></predicate>
<object><value>xs:string( surname )</value></object>
</triple>
<triple>
<subject><value>sem:iri( $PREFIX || @SSN )</value></subject>
<predicate><value>sem:iri( $PREFIX || name )</value></predicate>
<object><value>xs:string( name )</value></object>
</triple>
</triples>
</template>మీరు SPARQL ప్రశ్నతో ఫలిత RDF గ్రాఫ్‌ను పరిష్కరించవచ్చు:
PREFIX : <http://example.org/example#>
SELECT ?name ?surname {
:631803299804 :name ?name ; :surname ?surname .
}రిలేషనల్ ఒకటి కాకుండా, MarkLogic గ్రాఫ్ మోడల్‌కు మరో రెండు మార్గాల్లో మద్దతు ఇస్తుంది:
- DBMS అనేది RDF డేటా యొక్క పూర్తి స్థాయి ప్రత్యేక నిల్వగా ఉంటుంది (దానిలోని ట్రిపుల్స్ అంటారు పైన వివరించిన వాటికి విరుద్ధంగా ).
- ప్రత్యేక సీరియలైజేషన్‌లోని RDF కేవలం XML లేదా JSON డాక్యుమెంట్‌లలోకి చొప్పించబడుతుంది (మరియు త్రిపాదిలను అప్పుడు అంటారు ) ఇది బహుశా యంత్రాంగాలకు ప్రత్యామ్నాయం
idrefమరియు ఇతరులు.
మార్క్‌లాజిక్‌లో విషయాలు “నిజంగా” ఎలా పనిచేస్తాయనే దాని గురించి మంచి ఆలోచన ఇవ్వబడింది , ఈ కోణంలో, ఇది తక్కువ-స్థాయి, అయితే దాని ప్రయోజనం విరుద్ధంగా ఉన్నప్పటికీ - ఉపయోగించిన డేటా మోడల్ నుండి సంగ్రహించడానికి ప్రయత్నించడం, విభిన్న నమూనాలలో డేటాతో స్థిరమైన పనిని నిర్ధారించడం, లావాదేవీలు మొదలైనవి.
బహుళ-మోడల్ DBMS "ప్రధాన మోడల్ లేకుండా"
మార్కెట్‌లో DBMSలు కూడా ఉన్నాయి, అవి ఎటువంటి వారసత్వ ప్రధాన మోడల్ లేకుండా, ప్రారంభంలో బహుళ-మోడల్‌గా ఉన్నాయి. వీటితొ పాటు , (2018 నుండి అభివృద్ధి సంస్థ SAPకి చెందినది) మరియు (మైక్రోసాఫ్ట్ అజూర్ క్లౌడ్ ప్లాట్‌ఫారమ్‌లో భాగంగా సేవ).
వాస్తవానికి, ArangoDB మరియు OrientDBలలో "కోర్" నమూనాలు ఉన్నాయి. రెండు సందర్భాల్లో, ఇవి వారి స్వంత డేటా నమూనాలు, ఇవి పత్రం యొక్క సాధారణీకరణలు. సాధారణీకరణలు ప్రధానంగా గ్రాఫ్ మరియు రిలేషనల్ స్వభావం యొక్క ప్రశ్నలను నిర్వహించే సామర్థ్యాన్ని సులభతరం చేయడం.
పేర్కొన్న DBMSలో ఉపయోగించడానికి ఈ మోడల్‌లు మాత్రమే అందుబాటులో ఉన్నాయి; వారి స్వంత ప్రశ్న భాషలు వాటితో పని చేయడానికి రూపొందించబడ్డాయి. వాస్తవానికి, ఇటువంటి నమూనాలు మరియు DBMSలు ఆశాజనకంగా ఉన్నాయి, కానీ ప్రామాణిక నమూనాలు మరియు భాషలతో అనుకూలత లేకపోవడం వల్ల ఈ DBMSలను లెగసీ సిస్టమ్‌లలో ఉపయోగించడం అసాధ్యం-అక్కడ ఇప్పటికే ఉపయోగించిన DBMSలను భర్తీ చేయడానికి.
Habréలో ArangoDB మరియు OrientDB గురించి ఇప్పటికే అద్భుతమైన కథనం ఉంది: .
అరంగోడిబి
ArangoDB గ్రాఫ్ డేటా మోడల్‌కు మద్దతును క్లెయిమ్ చేస్తుంది.
ArangoDBలోని గ్రాఫ్ యొక్క నోడ్‌లు సాధారణ పత్రాలు మరియు అంచులు సాధారణ సిస్టమ్ ఫీల్డ్‌లతో పాటు (_key, _id, _rev) సిస్టమ్ ఫీల్డ్‌లు _from и _to. డాక్యుమెంట్ DBMSలలోని పత్రాలు సాంప్రదాయకంగా సేకరణలుగా మిళితం చేయబడతాయి. అంచులను సూచించే పత్రాల సేకరణలను ArangoDBలో అంచు సేకరణలు అంటారు. మార్గం ద్వారా, అంచు సేకరణ పత్రాలు కూడా పత్రాలు, కాబట్టి ArangoDBలోని అంచులు కూడా నోడ్‌లుగా పని చేస్తాయి.
మూల డేటా
మాకు సేకరణను కలిగి ఉండండి persons, దీని పత్రాలు ఇలా ఉన్నాయి:
[
{
"_id" : "people/alice" ,
"_key" : "alice" ,
"name" : "Алиса"
},
{
"_id" : "people/bob" ,
"_key" : "bob" ,
"name" : "Боб"
}
]సేకరణ కూడా ఉండనివ్వండి cafes:
[
{
"_id" : "cafes/jd" ,
"_key" : "jd" ,
"name" : "Джон Донн"
},
{
"_id" : "cafes/jj" ,
"_key" : "jj" ,
"name" : "Жан-Жак"
}
]అప్పుడు సేకరణ likes ఇలా ఉండవచ్చు:
[
{
"_id" : "likes/1" ,
"_key" : "1" ,
"_from" : "persons/alice" ,
"_to" : "cafes/jd",
"since" : 2010
},
{
"_id" : "likes/2" ,
"_key" : "2" ,
"_from" : "persons/alice" ,
"_to" : "cafes/jj",
"since" : 2011
} ,
{
"_id" : "likes/3" ,
"_key" : "3" ,
"_from" : "persons/bob" ,
"_to" : "cafes/jd",
"since" : 2012
}
]ప్రశ్నలు మరియు ఫలితాలు
ArangoDBలో ఉపయోగించిన AQL భాషలో గ్రాఫ్-శైలి ప్రశ్న, ఏ కేఫ్‌ను ఎవరు ఇష్టపడుతున్నారు అనే దాని గురించి మానవులు చదవగలిగే రూపంలో సమాచారాన్ని అందించడం ఇలా కనిపిస్తుంది:
FOR p IN persons
FOR c IN OUTBOUND p likes
RETURN { person : p.name , likes : c.name }రిలేషనల్ స్టైల్‌లో, మేము సంబంధాలను నిల్వ చేయడం కంటే వాటిని “కంప్యూటింగ్” చేస్తున్నప్పుడు, ఈ ప్రశ్నను ఇలా తిరిగి వ్రాయవచ్చు (మార్గం ద్వారా, సేకరణ లేకుండా likes లేకుండా చేయవచ్చు):
FOR p IN persons
FOR l IN likes
FILTER p._key == l._from
FOR c IN cafes
FILTER l._to == c._key
RETURN { person : p.name , likes : c.name }రెండు సందర్భాలలో ఫలితం ఒకే విధంగా ఉంటుంది:
[
{ "person" : "Алиса" , likes : "Жан-Жак" } ,
{ "person" : "Алиса" , likes : "Джон Донн" } ,
{ "person" : "Боб" , likes : "Джон Донн" }
]మరిన్ని ప్రశ్నలు మరియు ఫలితాలు
ఎగువన ఉన్న ఫలిత ఆకృతి DBMS డాక్యుమెంట్ కంటే రిలేషనల్ DBMSకి విలక్షణమైనదిగా అనిపిస్తే, మీరు ఈ ప్రశ్నను ప్రయత్నించవచ్చు (లేదా మీరు ఉపయోగించవచ్చు ):
FOR p IN persons
RETURN {
person : p.name,
likes : (
FOR c IN OUTBOUND p likes
RETURN c.name
)
}ఫలితం ఇలా కనిపిస్తుంది:
[
{ "person" : "Алиса" , likes : ["Жан-Жак" , "Джон Донн"] } ,
{ "person" : "Боб" , likes : ["Джон Донн"] }
]OrientDB
OrientDBలో డాక్యుమెంట్ మోడల్ పైన గ్రాఫ్ మోడల్‌ని అమలు చేయడానికి ఆధారం డాక్యుమెంట్ ఫీల్డ్‌లు, ఎక్కువ లేదా తక్కువ ప్రామాణిక స్కేలార్ విలువలతో పాటు, వంటి రకాల విలువలను కూడా కలిగి ఉంటాయి LINK, LINKLIST, LINKSET, LINKMAP и LINKBAG. ఈ రకాల విలువలు లింక్‌లు లేదా లింక్‌ల సేకరణలు పత్రాలు.
సిస్టమ్ ద్వారా కేటాయించబడిన డాక్యుమెంట్ ఐడెంటిఫైయర్ "భౌతిక అర్ధం"ని కలిగి ఉంది, ఇది డేటాబేస్లో రికార్డ్ యొక్క స్థానాన్ని సూచిస్తుంది మరియు ఇలా కనిపిస్తుంది: @rid : #3:16. అందువల్ల, రిఫరెన్స్ లక్షణాల విలువలు ఎంపిక పరిస్థితుల కంటే (రిలేషనల్ మోడల్‌లో వలె) నిజంగా పాయింటర్‌లు (గ్రాఫ్ మోడల్‌లో వలె).
ArangoDB వలె, OrientDBలోని అంచులు ప్రత్యేక పత్రాలుగా సూచించబడతాయి (అయితే ఒక అంచు దాని స్వంత లక్షణాలను కలిగి లేనప్పటికీ, దానిని తయారు చేయవచ్చు , మరియు ఇది ప్రత్యేక పత్రానికి అనుగుణంగా ఉండదు).
మూల డేటా
దగ్గరగా ఉన్న ఆకృతిలో OrientDB డేటాబేస్, ArangoDB కోసం మునుపటి ఉదాహరణ నుండి డేటా ఇలా కనిపిస్తుంది:
[
{
"@type": "document",
"@rid": "#11:0",
"@class": "Person",
"name": "Алиса",
"out_likes": [
"#30:1",
"#30:2"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#12:0",
"@class": "Person",
"name": "Боб",
"out_likes": [
"#30:3"
],
"@fieldTypes": "out_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#21:0",
"@class": "Cafe",
"name": "Жан-Жак",
"in_likes": [
"#30:2",
"#30:3"
],
"@fieldTypes": "in_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#22:0",
"@class": "Cafe",
"name": "Джон Донн",
"in_likes": [
"#30:1"
],
"@fieldTypes": "in_likes=LINKBAG"
},
{
"@type": "document",
"@rid": "#30:1",
"@class": "likes",
"in": "#22:0",
"out": "#11:0",
"since": 1262286000000,
"@fieldTypes": "in=LINK,out=LINK,since=date"
},
{
"@type": "document",
"@rid": "#30:2",
"@class": "likes",
"in": "#21:0",
"out": "#11:0",
"since": 1293822000000,
"@fieldTypes": "in=LINK,out=LINK,since=date"
},
{
"@type": "document",
"@rid": "#30:3",
"@class": "likes",
"in": "#21:0",
"out": "#12:0",
"since": 1325354400000,
"@fieldTypes": "in=LINK,out=LINK,since=date"
}
]మనం చూడగలిగినట్లుగా, శీర్షాలు ఇన్‌కమింగ్ మరియు అవుట్‌గోయింగ్ అంచుల గురించి సమాచారాన్ని కూడా నిల్వ చేస్తాయి. వద్ద డాక్యుమెంట్ API రెఫరెన్షియల్ సమగ్రతను స్వయంగా పర్యవేక్షించవలసి ఉంటుంది మరియు గ్రాఫ్ API ఈ పనిని తీసుకుంటుంది. అయితే ప్రోగ్రామింగ్ లాంగ్వేజ్‌లలో విలీనం చేయని “స్వచ్ఛమైన” ప్రశ్న భాషలలో OrientDBకి యాక్సెస్ ఎలా ఉంటుందో చూద్దాం.
ప్రశ్నలు మరియు ఫలితాలు
OrientDBలో ArangoDB కోసం ఉదాహరణ నుండి ప్రశ్నకు సమానమైన ప్రశ్న ఇలా కనిపిస్తుంది:
SELECT name AS person_name, OUT('likes').name AS cafe_name
FROM Person
UNWIND cafe_nameఫలితం క్రింది రూపంలో పొందబడుతుంది:
[
{ "person_name": "Алиса", "cafe_name": "Джон Донн" },
{ "person_name": "Алиса", "cafe_name": "Жан-Жак" },
{ "person_name": "Боб", "cafe_name": "Жан-Жак" }
]ఫలితం ఫార్మాట్ మళ్లీ చాలా "సంబంధమైనది" అనిపిస్తే, మీరు లైన్‌ను తీసివేయాలి :
[
{ "person_name": "Алиса", "cafe_name": [ "Джон Донн", "Жан-Жак" ] },
{ "person_name": "Боб", "cafe_name": [ "Жан-Жак" ' }
]OrientDB యొక్క ప్రశ్న భాషను గ్రెమ్లిన్-వంటి ఇన్సర్ట్‌లతో SQLగా వర్ణించవచ్చు. వెర్షన్ 2.2లో, సైఫర్ లాంటి అభ్యర్థన ఫారమ్ కనిపించింది, :
MATCH {CLASS: Person, AS: person}-likes->{CLASS: Cafe, AS: cafe}
RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name
GROUP BY person_nameఫలిత ఆకృతి మునుపటి అభ్యర్థనలో వలెనే ఉంటుంది. మొదటి ప్రశ్నలో వలె దీన్ని మరింత "సంబంధం"గా మార్చడానికి ఏమి తీసివేయాలి అనే దాని గురించి ఆలోచించండి.
అజూర్ కాస్మోస్డిబి
కొంత వరకు, ArangoDB మరియు OrientDB గురించి పైన చెప్పబడినది Azure CosmosDBకి వర్తిస్తుంది. CosmosDB కింది డేటా యాక్సెస్ APIలను అందిస్తుంది: SQL, MongoDB, గ్రెమ్లిన్ మరియు కాసాండ్రా.
డాక్యుమెంట్ మోడల్‌లో డేటాను యాక్సెస్ చేయడానికి SQL API మరియు MongoDB API ఉపయోగించబడతాయి. గ్రెమ్లిన్ API మరియు కాసాండ్రా API - వరుసగా గ్రాఫ్ మరియు కాలమ్ ఫార్మాట్‌లలో డేటాను యాక్సెస్ చేయడానికి. అన్ని మోడళ్లలోని డేటా CosmosDB అంతర్గత మోడల్ ఆకృతిలో సేవ్ చేయబడుతుంది: (“atom-record-sequence”), ఇది పత్రానికి దగ్గరగా ఉంటుంది.
కానీ వినియోగదారు ఎంచుకున్న డేటా మోడల్ మరియు ఉపయోగించిన API సేవలో ఖాతాను సృష్టించే సమయంలో పరిష్కరించబడతాయి. ఒక మోడల్‌లో లోడ్ చేయబడిన డేటాను మరొక మోడల్ ఫార్మాట్‌లో యాక్సెస్ చేయడం సాధ్యం కాదు, ఇలాంటి వాటి ద్వారా వివరించబడింది:
ఈ విధంగా, అజూర్ కాస్మోస్‌డిబిలోని బహుళ-మోడల్ నేడు ఒక తయారీదారు నుండి వివిధ మోడళ్లకు మద్దతు ఇచ్చే అనేక డేటాబేస్‌లను ఉపయోగించగల సామర్థ్యం మాత్రమే, ఇది బహుళ-వేరియంట్ నిల్వ యొక్క అన్ని సమస్యలను పరిష్కరించదు.
గ్రాఫ్ మోడల్ ఆధారంగా మల్టీ-మోడల్ DBMS?
గ్రాఫ్ మోడల్‌పై ఆధారపడిన బహుళ-మోడల్ DBMSలు మార్కెట్‌లో ఇంకా ఏవీ లేవు (ఏకకాలంలో రెండు గ్రాఫ్ మోడల్‌లకు బహుళ-మోడల్ మద్దతు మినహా: RDF మరియు LPG; ఇందులో చూడండి ) రిలేషనల్ కంటే గ్రాఫ్ మోడల్ పైన డాక్యుమెంట్ మోడల్‌ని అమలు చేయడం వల్ల చాలా ఇబ్బందులు ఎదురవుతాయి.
గ్రాఫ్ మోడల్ పైన రిలేషనల్ మోడల్‌ను ఎలా అమలు చేయాలి అనే ప్రశ్న తరువాతి ఏర్పాటు సమయంలో కూడా పరిగణించబడింది. ఎలా ఉదాహరణకు :
గ్రాఫ్ డేటాబేస్లో లేయర్‌ను (ఉదా., తగిన ఇండెక్సింగ్ ద్వారా) సృష్టించడాన్ని నిరోధించే గ్రాఫ్ విధానంలో అంతర్లీనంగా ఏమీ లేదు, ఇది (1) సాధారణ కీ విలువ జతల నుండి (2) టుపుల్స్ రికవరీ మరియు (XNUMX) గ్రూపింగ్‌తో రిలేషనల్ వీక్షణను అనుమతిస్తుంది. సంబంధం రకం ద్వారా tuples.
గ్రాఫ్ మోడల్ పైన డాక్యుమెంట్ మోడల్‌ను అమలు చేస్తున్నప్పుడు, మీరు గుర్తుంచుకోవాలి, ఉదాహరణకు, కింది వాటిని:
- JSON శ్రేణి యొక్క మూలకాలు క్రమం చేయబడినవిగా పరిగణించబడతాయి, కానీ గ్రాఫ్ యొక్క అంచు యొక్క శీర్షం నుండి వెలువడేవి కాదు;
- డాక్యుమెంట్ మోడల్‌లోని డేటా సాధారణంగా డీనార్మలైజ్ చేయబడుతుంది; మీరు ఇప్పటికీ ఒకే ఎంబెడెడ్ డాక్యుమెంట్ యొక్క అనేక కాపీలను నిల్వ చేయకూడదనుకుంటున్నారు మరియు సబ్‌డాక్యుమెంట్‌లలో సాధారణంగా ఐడెంటిఫైయర్లు ఉండవు;
- మరోవైపు, డాక్యుమెంట్ DBMSల యొక్క భావజాలం ఏమిటంటే, పత్రాలు ప్రతిసారీ కొత్తగా నిర్మించాల్సిన అవసరం లేని "సంకలనాలు" సిద్ధంగా ఉంటాయి. పూర్తయిన పత్రానికి సంబంధించిన సబ్‌గ్రాఫ్‌ను త్వరగా పొందగల సామర్థ్యంతో గ్రాఫ్ మోడల్‌ను అందించడం అవసరం.
ఒక చిన్న ప్రకటన
వ్యాసం యొక్క రచయిత NitrosBase DBMS అభివృద్ధికి సంబంధించినది, దీని అంతర్గత నమూనా గ్రాఫ్, మరియు బాహ్య నమూనాలు - రిలేషనల్ మరియు డాక్యుమెంట్ - దాని ప్రాతినిధ్యాలు. అన్ని మోడల్‌లు సమానంగా ఉంటాయి: దాదాపు ఏదైనా డేటా సహజమైన ప్రశ్న భాషను ఉపయోగించి వాటిలో దేనిలోనైనా అందుబాటులో ఉంటుంది. అంతేకాకుండా, ఏ వీక్షణలోనైనా, డేటాను మార్చవచ్చు. మార్పులు అంతర్గత నమూనాలో మరియు తదనుగుణంగా, ఇతర వీక్షణలలో ప్రతిబింబిస్తాయి.
కింది కథనాలలో ఒకదానిలో NitrosBaseలో మోడల్ మ్యాచింగ్ ఎలా ఉంటుందో నేను ఆశాజనకంగా వివరిస్తాను.
తీర్మానం
బహుళ-మోడలింగ్ అని పిలవబడే సాధారణ రూపురేఖలు పాఠకులకు ఎక్కువ లేదా తక్కువ స్పష్టంగా ఉన్నాయని నేను ఆశిస్తున్నాను. మల్టీ-మోడల్ DBMSలు చాలా భిన్నంగా ఉంటాయి మరియు “మల్టీ-మోడల్ సపోర్ట్” భిన్నంగా కనిపించవచ్చు. ప్రతి నిర్దిష్ట సందర్భంలో "మల్టీ-మోడల్" అని పిలవబడేదాన్ని అర్థం చేసుకోవడానికి, ఈ క్రింది ప్రశ్నలకు సమాధానం ఇవ్వడం ఉపయోగకరంగా ఉంటుంది:
- మేము సంప్రదాయ నమూనాలు లేదా కొన్ని రకాల "హైబ్రిడ్" మోడల్‌కు మద్దతు ఇవ్వడం గురించి మాట్లాడుతున్నామా?
- నమూనాలు "సమానమైనవి", లేదా వాటిలో ఒకటి ఇతరులకు సంబంధించినదా?
- నమూనాలు ఒకదానికొకటి "ఉదాసీనంగా" ఉన్నాయా? ఒక మోడల్‌లో వ్రాసిన డేటాను మరొక మోడల్‌లో చదవవచ్చా లేదా ఓవర్‌రైట్ చేయవచ్చా?
మల్టీ-మోడల్ DBMS యొక్క ఔచిత్యం గురించిన ప్రశ్నకు ఇప్పటికే సానుకూలంగా సమాధానం ఇవ్వవచ్చని నేను భావిస్తున్నాను, అయితే సమీప భవిష్యత్తులో వాటిలో ఏ రకాలు ఎక్కువ డిమాండ్‌లో ఉంటాయి అనేది ఆసక్తికరమైన ప్రశ్న. సాంప్రదాయ నమూనాలకు మద్దతు ఇచ్చే బహుళ-మోడల్ DBMSలు, ప్రధానంగా రిలేషనల్, ఎక్కువ డిమాండ్‌లో ఉన్నట్లు తెలుస్తోంది; బహుళ-మోడల్ DBMSల యొక్క జనాదరణ, వివిధ సాంప్రదాయిక వాటి ప్రయోజనాలను మిళితం చేసే కొత్త మోడల్‌లను అందించడం అనేది మరింత సుదూర భవిష్యత్తుకు సంబంధించిన విషయం.
నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. దయచేసి.
మీరు బహుళ-మోడల్ DBMS ఉపయోగిస్తున్నారా?
-
మేము దానిని ఉపయోగించము, మేము ఒక DBMS మరియు ఒక నమూనాలో ప్రతిదీ నిల్వ చేస్తాము
-
మేము సాంప్రదాయ DBMSల యొక్క బహుళ-మోడల్ సామర్థ్యాలను ఉపయోగిస్తాము
-
మేము బహుభాషా పట్టుదలను పాటిస్తాము
-
మేము కొత్త బహుళ-మోడల్ DBMS (Arango, Orient, CosmosDB)ని ఉపయోగిస్తాము
19 మంది వినియోగదారులు ఓటు వేశారు. 4 వినియోగదారులు దూరంగా ఉన్నారు.
మూలం: www.habr.com