NewSQL = NoSQL+ACID

ఇటీవలి వరకు, Odnoklassniki SQL సర్వర్‌లో నిజ సమయంలో ప్రాసెస్ చేయబడిన దాదాపు 50 TB డేటాను నిల్వ చేసింది. అటువంటి వాల్యూమ్ కోసం, SQL DBMSని ఉపయోగించి వేగంగా మరియు నమ్మదగినదిగా మరియు డేటా సెంటర్ వైఫల్యాన్ని తట్టుకునే యాక్సెస్‌ను అందించడం దాదాపు అసాధ్యం. సాధారణంగా, అటువంటి సందర్భాలలో, NoSQL నిల్వలలో ఒకటి ఉపయోగించబడుతుంది, కానీ ప్రతిదీ NoSQLకి బదిలీ చేయబడదు: కొన్ని ఎంటిటీలకు ACID లావాదేవీ హామీలు అవసరం.

ఇది NewSQL స్టోరేజ్‌ని ఉపయోగించుకునేలా చేసింది, అంటే, NoSQL సిస్టమ్‌ల యొక్క తప్పు సహనం, స్కేలబిలిటీ మరియు పనితీరును అందించే DBMS, అయితే అదే సమయంలో ACIDని నిర్వహించడం అనేది క్లాసికల్ సిస్టమ్‌లకు సుపరిచితమైన హామీలను అందిస్తుంది. ఈ కొత్త తరగతికి చెందిన కొన్ని పని చేసే పారిశ్రామిక వ్యవస్థలు ఉన్నాయి, కాబట్టి మేము అలాంటి వ్యవస్థను స్వయంగా అమలు చేసాము మరియు దానిని వాణిజ్యపరమైన కార్యాచరణలో ఉంచాము.

ఇది ఎలా పని చేస్తుంది మరియు ఏమి జరిగింది - కట్ కింద చదవండి.

నేడు, Odnoklassniki యొక్క నెలవారీ ప్రేక్షకుల సంఖ్య 70 మిలియన్లకు పైగా ప్రత్యేక సందర్శకులు. మేము మేము మొదటి ఐదు స్థానాల్లో ఉన్నాము ప్రపంచంలోని అతిపెద్ద సోషల్ నెట్‌వర్క్‌లు మరియు వినియోగదారులు ఎక్కువ సమయం గడిపే ఇరవై సైట్‌లలో ఒకటి. OK ఇన్‌ఫ్రాస్ట్రక్చర్ చాలా ఎక్కువ లోడ్‌లను నిర్వహిస్తుంది: ఒక ముందు ముందు ఒక మిలియన్ కంటే ఎక్కువ HTTP అభ్యర్థనలు/సెక. 8000 కంటే ఎక్కువ ముక్కల సర్వర్ ఫ్లీట్ యొక్క భాగాలు ఒకదానికొకటి దగ్గరగా ఉన్నాయి - నాలుగు మాస్కో డేటా సెంటర్లలో, వాటి మధ్య 1 ms కంటే తక్కువ నెట్‌వర్క్ జాప్యాన్ని అనుమతిస్తుంది.

మేము వెర్షన్ 2010తో ప్రారంభించి 0.6 నుండి కాసాండ్రాను ఉపయోగిస్తున్నాము. నేడు అనేక డజన్ల క్లస్టర్లు పనిచేస్తున్నాయి. వేగవంతమైన క్లస్టర్ సెకనుకు 4 మిలియన్ల కంటే ఎక్కువ కార్యకలాపాలను ప్రాసెస్ చేస్తుంది మరియు అతిపెద్దది 260 TBని నిల్వ చేస్తుంది.

అయితే, ఇవన్నీ నిల్వ కోసం ఉపయోగించే సాధారణ NoSQL క్లస్టర్‌లు బలహీనంగా సమన్వయం సమాచారం. మేము Odnoklassniki స్థాపించినప్పటి నుండి ఉపయోగించబడుతున్న ప్రధాన స్థిరమైన నిల్వ, Microsoft SQL సర్వర్‌ని భర్తీ చేయాలనుకుంటున్నాము. నిల్వ 300 కంటే ఎక్కువ SQL సర్వర్ స్టాండర్డ్ ఎడిషన్ మెషీన్‌లను కలిగి ఉంది, ఇందులో 50 TB డేటా - వ్యాపార సంస్థలు ఉన్నాయి. ఈ డేటా ACID లావాదేవీలలో భాగంగా సవరించబడింది మరియు అవసరం అధిక స్థిరత్వం.

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

భాగస్వామ్యం చేసినందుకు మరియు SQLని వేగవంతం చేసినందుకు ధన్యవాదాలు:

• మేము ఫారిన్ కీ పరిమితులను ఉపయోగించము, ఎందుకంటే భాగస్వామ్య ID మరొక సర్వర్‌లో ఉండవచ్చు.
• DBMS CPUలో అదనపు లోడ్ కారణంగా మేము నిల్వ చేసిన విధానాలు మరియు ట్రిగ్గర్‌లను ఉపయోగించము.
• పైన పేర్కొన్నవన్నీ మరియు డిస్క్ నుండి చాలా యాదృచ్ఛిక రీడ్‌ల కారణంగా మేము JOINలను ఉపయోగించము.
• లావాదేవీ వెలుపల, డెడ్‌లాక్‌లను తగ్గించడానికి మేము రీడ్ అన్‌కమిటెడ్ ఐసోలేషన్ స్థాయిని ఉపయోగిస్తాము.
• మేము చిన్న లావాదేవీలను మాత్రమే నిర్వహిస్తాము (సగటున 100 ms కంటే తక్కువ).
• పెద్ద సంఖ్యలో డెడ్‌లాక్‌ల కారణంగా మేము బహుళ-వరుసల UPDATE మరియు DELETEని ఉపయోగించము - మేము ఒకేసారి ఒక రికార్డ్‌ను మాత్రమే నవీకరిస్తాము.
• మేము ఎల్లప్పుడూ ఇండెక్స్‌లపై మాత్రమే ప్రశ్నలను నిర్వహిస్తాము - మాకు పూర్తి టేబుల్ స్కాన్ ప్లాన్‌తో కూడిన ప్రశ్న అంటే డేటాబేస్‌ను ఓవర్‌లోడ్ చేయడం మరియు అది విఫలమయ్యేలా చేయడం.

ఈ దశలు SQL సర్వర్‌ల నుండి దాదాపు గరిష్ట పనితీరును స్క్వీజ్ చేయడానికి మాకు అనుమతినిచ్చాయి. అయితే, సమస్యలు మరింత ఎక్కువయ్యాయి. వాటిని చూద్దాం.

SQLతో సమస్యలు

• మేము స్వీయ-వ్రాతపూర్వక షార్డింగ్‌ని ఉపయోగించాము కాబట్టి, కొత్త ముక్కలను జోడించడం నిర్వాహకులచే మాన్యువల్‌గా చేయబడింది. ఈ సమయంలో, స్కేలబుల్ డేటా ప్రతిరూపాలు రిక్వెస్ట్‌లను సర్వీసింగ్ చేయలేదు.
• పట్టికలో రికార్డుల సంఖ్య పెరిగేకొద్దీ, చొప్పించడం మరియు సవరించడం యొక్క వేగం తగ్గుతుంది; ఇప్పటికే ఉన్న పట్టికకు సూచికలను జోడించేటప్పుడు, వేగం ఒక కారకం ద్వారా పడిపోతుంది; సూచికల సృష్టి మరియు పునఃసృష్టి పనికిరాని సమయంలో జరుగుతుంది.
• ఉత్పత్తిలో SQL సర్వర్ కోసం తక్కువ మొత్తంలో Windows కలిగి ఉండటం వలన మౌలిక సదుపాయాల నిర్వహణ కష్టమవుతుంది

కానీ ప్రధాన సమస్య

తప్పు సహనం

క్లాసిక్ SQL సర్వర్ పేలవమైన తప్పు సహనాన్ని కలిగి ఉంది. మీకు ఒక డేటాబేస్ సర్వర్ మాత్రమే ఉందని చెప్పండి మరియు ఇది ప్రతి మూడు సంవత్సరాలకు ఒకసారి విఫలమవుతుంది. ఈ సమయంలో, సైట్ 20 నిమిషాల పాటు నిలిపివేయబడుతుంది, ఇది ఆమోదయోగ్యమైనది. మీకు 64 సర్వర్‌లు ఉంటే, ప్రతి మూడు వారాలకు ఒకసారి సైట్ డౌన్ అవుతుంది. మరియు మీకు 200 సర్వర్లు ఉంటే, ప్రతి వారం సైట్ పని చేయదు. ఇది సమస్య.

SQL సర్వర్ యొక్క తప్పు సహనాన్ని మెరుగుపరచడానికి ఏమి చేయవచ్చు? వికీపీడియా నిర్మించమని మమ్మల్ని ఆహ్వానిస్తుంది అత్యంత అందుబాటులో ఉన్న క్లస్టర్: ఏదైనా భాగాలు విఫలమైతే బ్యాకప్ ఒకటి ఉంటుంది.

దీనికి ఖరీదైన పరికరాల సముదాయం అవసరం: అనేక డూప్లికేషన్‌లు, ఆప్టికల్ ఫైబర్, షేర్డ్ స్టోరేజ్ మరియు రిజర్వ్‌ను చేర్చడం విశ్వసనీయంగా పని చేయదు: దాదాపు 10% స్విచ్‌లు ప్రధాన నోడ్ వెనుక రైలు వంటి బ్యాకప్ నోడ్ వైఫల్యంతో ముగుస్తాయి.

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

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

ఈ సమస్యలన్నింటికీ సమూల పరిష్కారం అవసరం, మరియు మేము వాటిని వివరంగా విశ్లేషించడం ప్రారంభించాము. ఇక్కడ మనం SQL సర్వర్ ప్రధానంగా ఏమి చేస్తుందో తెలుసుకోవాలి - లావాదేవీలు.

సాధారణ లావాదేవీ

అనువర్తిత SQL ప్రోగ్రామర్ దృక్కోణం నుండి సరళమైన లావాదేవీని పరిశీలిద్దాం: ఆల్బమ్‌కి ఫోటోను జోడించడం. ఆల్బమ్‌లు మరియు ఛాయాచిత్రాలు వేర్వేరు ప్లేట్లలో నిల్వ చేయబడతాయి. ఆల్బమ్‌లో పబ్లిక్ ఫోటో కౌంటర్ ఉంది. అటువంటి లావాదేవీ క్రింది దశలుగా విభజించబడింది:

1. మేము ఆల్బమ్‌ను కీ ద్వారా లాక్ చేస్తాము.
2. ఫోటో పట్టికలో ఒక ఎంట్రీని సృష్టించండి.
3. ఫోటో పబ్లిక్ స్టేటస్‌ని కలిగి ఉన్నట్లయితే, ఆల్బమ్‌కి పబ్లిక్ ఫోటో కౌంటర్‌ని జోడించి, రికార్డ్‌ను అప్‌డేట్ చేసి, లావాదేవీని చేయండి.

లేదా సూడోకోడ్‌లో:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

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

లావాదేవీని అమలు చేస్తున్నప్పుడు, మరొక సిస్టమ్ నుండి అదే డేటా యొక్క ఏకకాల సవరణ సంభవించవచ్చు. ఉదాహరణకు, Antispam వినియోగదారు అనుమానాస్పదంగా ఉన్నట్లు నిర్ణయించవచ్చు మరియు అందువల్ల వినియోగదారు యొక్క అన్ని ఫోటోలు ఇకపై పబ్లిక్‌గా ఉండకూడదు, వాటిని మోడరేషన్ కోసం పంపాలి, అంటే photo.statusని వేరే విలువకు మార్చడం మరియు సంబంధిత కౌంటర్లను ఆఫ్ చేయడం. సహజంగానే, ఈ ఆపరేషన్ అప్లికేషన్ యొక్క పరమాణు గ్యారంటీ లేకుండా జరిగితే మరియు పోటీ మార్పుల యొక్క ఐసోలేషన్, లో వలె ACID, అప్పుడు ఫలితం అవసరమైనది కాదు - ఫోటో కౌంటర్ తప్పు విలువను చూపుతుంది లేదా అన్ని ఫోటోలు మోడరేషన్ కోసం పంపబడవు.

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

ఇతర, తక్కువ ప్రాముఖ్యత లేని అవసరాలు:

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

నిర్ణయాలు, నిర్ణయాలు

సాధ్యమయ్యే పరిష్కారాలను విశ్లేషిస్తూ, మేము రెండు సాధ్యమైన నిర్మాణ ఎంపికలకు వచ్చాము:

మొదటిది ఏదైనా SQL సర్వర్‌ని తీసుకొని, అవసరమైన ఫాల్ట్ టాలరెన్స్, స్కేలింగ్ మెకానిజం, ఫెయిల్‌ఓవర్ క్లస్టర్, సంఘర్షణ రిజల్యూషన్ మరియు పంపిణీ చేయబడిన, నమ్మదగిన మరియు వేగవంతమైన ACID లావాదేవీలను అమలు చేయడం. మేము ఈ ఎంపికను చాలా అల్పమైనది మరియు శ్రమతో కూడుకున్నదిగా రేట్ చేసాము.

రెండవ ఎంపిక ఏమిటంటే, అమలు చేయబడిన స్కేలింగ్, ఫెయిల్‌ఓవర్ క్లస్టర్, సంఘర్షణ రిజల్యూషన్‌తో రెడీమేడ్ NoSQL నిల్వను తీసుకోవడం మరియు లావాదేవీలు మరియు SQLని మీరే అమలు చేయడం. మొదటి చూపులో, ACID లావాదేవీల గురించి చెప్పనవసరం లేకుండా SQLని అమలు చేసే పని కూడా సంవత్సరాలు పట్టే పనిలా కనిపిస్తోంది. కానీ మేము ఆచరణలో ఉపయోగించే SQL ఫీచర్ సెట్ ANSI SQL నుండి చాలా దూరంలో ఉందని మేము గ్రహించాము కాసాండ్రా CQL ANSI SQL నుండి చాలా దూరంలో ఉంది. CQLని మరింత నిశితంగా పరిశీలిస్తే, అది మనకు అవసరమైన దానికి చాలా దగ్గరగా ఉందని మేము గ్రహించాము.

కాసాండ్రా మరియు CQL

కాబట్టి, కాసాండ్రా గురించి ఆసక్తికరమైనది ఏమిటి, దానికి ఏ సామర్థ్యాలు ఉన్నాయి?

ముందుగా, ఇక్కడ మీరు వివిధ డేటా రకాలకు మద్దతు ఇచ్చే పట్టికలను సృష్టించవచ్చు; మీరు ప్రాథమిక కీపై SELECT లేదా UPDATE చేయవచ్చు.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

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

మేము మూడు నోడ్‌లను సంప్రదించినప్పుడు మరియు రెండు నుండి ప్రతిస్పందనను స్వీకరించే విధానాన్ని అంటారు ఊహాగానాలు: అదనపు ప్రతిరూపాల కోసం అభ్యర్థన "పడిపోవడానికి" ముందే పంపబడుతుంది.

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

కాసాండ్రాలో లావాదేవీలకు దగ్గరగా ఉన్నవి "" అని పిలవబడేవితేలికైన లావాదేవీలు". కానీ అవి "నిజమైన" ACID లావాదేవీలకు దూరంగా ఉన్నాయి: వాస్తవానికి, ఇది చేయడానికి ఒక అవకాశం CAS హెవీవెయిట్ పాక్సోస్ ప్రోటోకాల్‌ని ఉపయోగించి ఏకాభిప్రాయాన్ని ఉపయోగించి ఒకే ఒక రికార్డ్ నుండి డేటాపై. అందువల్ల, అటువంటి లావాదేవీల వేగం తక్కువగా ఉంటుంది.

కాసాండ్రాలో మనం ఏమి కోల్పోయాము

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

సి*వన్

అలా కొత్త DBMS పుట్టింది సి*వన్, మూడు రకాల సర్వర్ నోడ్‌లను కలిగి ఉంటుంది:

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

అన్ని రకాల సర్వర్‌లు ఒక సాధారణ క్లస్టర్‌లో భాగం, ఒకదానితో ఒకటి కమ్యూనికేట్ చేయడానికి అంతర్గత Cassandra సందేశ ప్రోటోకాల్‌ను ఉపయోగించండి మరియు గాసిప్ క్లస్టర్ సమాచారం మార్పిడి కోసం. హృదయ స్పందనతో, సర్వర్‌లు పరస్పర వైఫల్యాల గురించి నేర్చుకుంటాయి, ఒకే డేటా స్కీమాను నిర్వహిస్తాయి - పట్టికలు, వాటి నిర్మాణం మరియు ప్రతిరూపం; విభజన పథకం, క్లస్టర్ టోపోలాజీ మొదలైనవి.

క్లయింట్లు

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

C*వన్ లావాదేవీ సమన్వయకర్త

కోఆర్డినేటర్ అనేది మేము మొదటి నుండి C*Oన్ కోసం అమలు చేసాము. లావాదేవీలు, తాళాలు మరియు లావాదేవీలు వర్తించే క్రమంలో నిర్వహణకు ఇది బాధ్యత వహిస్తుంది.

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

తాళాలు

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

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

మా విషయంలో డేటా ఇప్పటికే SQLలోని స్థానిక లావాదేవీల సమూహాల మధ్య పంపిణీ చేయబడినందున, స్థానిక లావాదేవీల సమూహాలను సమన్వయకర్తలకు కేటాయించాలని నిర్ణయించారు: ఒక సమన్వయకర్త అన్ని లావాదేవీలను 0 నుండి 9 వరకు టోకెన్‌లతో నిర్వహిస్తారు, రెండవది - 10 నుండి 19 వరకు టోకెన్‌లతో, మరియు అందువలన న. ఫలితంగా, ప్రతి కోఆర్డినేటర్ ఉదంతాలు లావాదేవీ సమూహం యొక్క మాస్టర్‌గా మారతాయి.

అప్పుడు తాళాలు సమన్వయకర్త యొక్క మెమరీలో సామాన్యమైన HashMap రూపంలో అమలు చేయబడతాయి.

కోఆర్డినేటర్ వైఫల్యాలు

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

ప్రతి డేటా సెంటర్ కనీసం రెండు కోఆర్డినేటర్ నోడ్‌లను హోస్ట్ చేస్తుంది. క్రమానుగతంగా, ప్రతి కోఆర్డినేటర్ ఇతర సమన్వయకర్తలకు హృదయ స్పందన సందేశాన్ని పంపుతారు మరియు దాని పనితీరు గురించి వారికి తెలియజేస్తారు, అలాగే చివరిసారి క్లస్టర్‌లోని ఏ కోఆర్డినేటర్‌ల నుండి ఏ హార్ట్‌బీట్ సందేశాలు అందుకున్నారో తెలియజేస్తారు.

వారి హృదయ స్పందన సందేశాలలో భాగంగా ఇతరుల నుండి సారూప్య సమాచారాన్ని స్వీకరించడం ద్వారా, ప్రతి కోఆర్డినేటర్ కోరం సూత్రం ద్వారా మార్గనిర్దేశం చేయబడిన క్లస్టర్ నోడ్‌లు ఏవి పని చేస్తున్నాయో మరియు ఏది పని చేయకూడదో స్వయంగా నిర్ణయించుకుంటారు: నోడ్ X క్లస్టర్‌లోని మెజారిటీ నోడ్‌ల నుండి సాధారణ సమాచారం పొందినట్లయితే నోడ్ Y నుండి సందేశాల రసీదు, ఆపై , Y పనిచేస్తుంది. మరియు వైస్ వెర్సా, నోడ్ Y నుండి మెజారిటీ తప్పిపోయిన సందేశాలను నివేదించిన వెంటనే, Y నిరాకరించింది. కోరం నోడ్ Xకి దాని నుండి సందేశాలను స్వీకరించడం లేదని తెలియజేసినట్లయితే, నోడ్ X స్వయంగా విఫలమైనట్లు భావించడం ఆసక్తికరం.

హృదయ స్పందన సందేశాలు అధిక పౌనఃపున్యంతో, సెకనుకు దాదాపు 20 సార్లు, 50 ms వ్యవధితో పంపబడతాయి. జావాలో, చెత్త సేకరించేవారి వల్ల పోల్చదగిన పాజ్‌ల పొడవు కారణంగా 50 msలోపు అప్లికేషన్ ప్రతిస్పందనకు హామీ ఇవ్వడం కష్టం. మేము G1 చెత్త కలెక్టర్‌ని ఉపయోగించి ఈ ప్రతిస్పందన సమయాన్ని సాధించగలిగాము, ఇది GC పాజ్‌ల వ్యవధి కోసం లక్ష్యాన్ని పేర్కొనడానికి అనుమతిస్తుంది. అయితే, కొన్నిసార్లు, చాలా అరుదుగా, కలెక్టర్ పాజ్ 50 ms కంటే ఎక్కువగా ఉంటుంది, ఇది తప్పు తప్పు గుర్తింపుకు దారి తీస్తుంది. ఇది జరగకుండా నిరోధించడానికి, కోఆర్డినేటర్ రిమోట్ నోడ్ నుండి మొదటి హృదయ స్పందన సందేశం అదృశ్యమైనప్పుడు దాని వైఫల్యాన్ని నివేదించదు, వరుసగా అనేక అదృశ్యమైనప్పుడు మాత్రమే. ఈ విధంగా మేము 200లో కోఆర్డినేటర్ నోడ్ యొక్క వైఫల్యాన్ని గుర్తించగలిగాము. కుమారి.

కానీ ఏ నోడ్ పనిచేయడం ఆగిపోయిందో త్వరగా అర్థం చేసుకోవడానికి ఇది సరిపోదు. దీని గురించి మనం ఏదైనా చేయాలి.

రిజర్వేషన్

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

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

ఈ పథకం సార్వత్రిక అల్గోరిథం కంటే నమ్మదగినది, ఎందుకంటే కొత్త మాస్టర్‌ను సక్రియం చేయడానికి పాత దాని వైఫల్యాన్ని గుర్తించడం సరిపోతుంది.

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

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

లావాదేవీ ఎలా పనిచేస్తుంది

అటువంటి మరియు అటువంటి ప్రాథమిక కీతో అటువంటి మరియు అటువంటి ఎంటిటీ కోసం లావాదేవీని తెరవడానికి ఒక క్లయింట్ కోఆర్డినేటర్‌కు అభ్యర్థనను పంపారని అనుకుందాం. సమన్వయకర్త ఈ ఎంటిటీని లాక్ చేసి, మెమరీలో లాక్ టేబుల్‌లో ఉంచుతారు. అవసరమైతే, కోఆర్డినేటర్ నిల్వ నుండి ఈ ఎంటిటీని చదివి, ఫలితంగా డేటాను కోఆర్డినేటర్ మెమరీలో లావాదేవీ స్థితిలో నిల్వ చేస్తుంది.

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

సక్రియ లావాదేవీలో భాగంగా క్లయింట్ దాని స్వంత మార్చబడిన డేటాను అభ్యర్థించినప్పుడు, కోఆర్డినేటర్ ఈ క్రింది విధంగా వ్యవహరిస్తారు:

• ID ఇప్పటికే లావాదేవీలో ఉంటే, అప్పుడు డేటా మెమరీ నుండి తీసుకోబడుతుంది;
• మెమరీలో ID లేకపోతే, తప్పిపోయిన డేటా నిల్వ నోడ్‌ల నుండి చదవబడుతుంది, ఇది ఇప్పటికే మెమరీలో ఉన్న వాటితో కలిపి, ఫలితంగా క్లయింట్‌కు అందించబడుతుంది.

అందువల్ల, క్లయింట్ దాని స్వంత మార్పులను చదవగలరు, కానీ ఇతర క్లయింట్లు ఈ మార్పులను చూడలేరు, ఎందుకంటే అవి సమన్వయకర్త యొక్క మెమరీలో మాత్రమే నిల్వ చేయబడతాయి; అవి ఇంకా కాసాండ్రా నోడ్‌లలో లేవు.

క్లయింట్ కమిట్‌ని పంపినప్పుడు, సర్వీస్ మెమరీలో ఉన్న స్థితిని కోఆర్డినేటర్ లాగ్ చేసిన బ్యాచ్‌లో సేవ్ చేస్తారు మరియు లాగ్ చేసిన బ్యాచ్‌గా కాసాండ్రా స్టోరేజ్‌కి పంపబడుతుంది. ఈ ప్యాకేజీ అటామిక్‌గా (పూర్తిగా) వర్తింపజేయబడిందని నిర్ధారించడానికి దుకాణాలు అవసరమైన ప్రతిదాన్ని చేస్తాయి మరియు తాళాలను విడుదల చేసి, క్లయింట్‌కు లావాదేవీ విజయాన్ని నిర్ధారించే కోఆర్డినేటర్‌కు ప్రతిస్పందనను అందిస్తుంది.

మరియు రోల్‌బ్యాక్ చేయడానికి, కోఆర్డినేటర్ లావాదేవీ స్థితి ద్వారా ఆక్రమించబడిన మెమరీని మాత్రమే ఖాళీ చేయాలి.

పై మెరుగుదలల ఫలితంగా, మేము ACID సూత్రాలను అమలు చేసాము:

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

సూచికల వారీగా చదవడం

ఒక సాధారణ పట్టికను తీసుకుందాం:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

దీనికి ID (ప్రాధమిక కీ), యజమాని మరియు సవరణ తేదీ ఉంది. మీరు చాలా సులభమైన అభ్యర్థనను చేయాలి - "చివరి రోజు" మార్పు తేదీతో యజమానిపై డేటాను ఎంచుకోండి.

SELECT *
WHERE owner=?
AND modified>?

అటువంటి ప్రశ్నను త్వరగా ప్రాసెస్ చేయడానికి, క్లాసిక్ SQL DBMSలో మీరు నిలువు వరుసల ద్వారా సూచికను రూపొందించాలి (యజమాని, సవరించబడింది). మేము ఇప్పుడు ACID హామీని కలిగి ఉన్నందున మేము దీన్ని చాలా సులభంగా చేయవచ్చు!

సి*వన్‌లో సూచికలు

ఫోటోగ్రాఫ్‌లతో సోర్స్ టేబుల్ ఉంది, దీనిలో రికార్డ్ ID ప్రాథమిక కీ.

ఇండెక్స్ కోసం, సి*వన్ ఒరిజినల్ కాపీ అయిన కొత్త పట్టికను సృష్టిస్తుంది. కీ ఇండెక్స్ ఎక్స్‌ప్రెషన్ మాదిరిగానే ఉంటుంది మరియు ఇది సోర్స్ టేబుల్ నుండి రికార్డ్ యొక్క ప్రాథమిక కీని కూడా కలిగి ఉంటుంది:

ఇప్పుడు "చివరి రోజు యజమాని" కోసం ప్రశ్న మరొక పట్టిక నుండి ఎంపికగా తిరిగి వ్రాయబడుతుంది:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

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

ACIDని ఉపయోగించి, మేము SQL-వంటి సూచికలను అమలు చేయగలిగాము. అవి స్థిరమైనవి, స్కేలబుల్, వేగవంతమైనవి, కంపోజిబుల్ మరియు CQL ప్రశ్న భాషలో నిర్మించబడ్డాయి. ఇండెక్స్‌లకు మద్దతు ఇవ్వడానికి అప్లికేషన్ కోడ్‌లో ఎటువంటి మార్పులు అవసరం లేదు. ప్రతిదీ SQL లో వలె సులభం. మరియు ముఖ్యంగా, ఇండెక్స్‌లు అసలు లావాదేవీల పట్టికకు సవరణల అమలు వేగాన్ని ప్రభావితం చేయవు.

ఏమి జరిగినది

మేము మూడు సంవత్సరాల క్రితం C*Oన్‌ని అభివృద్ధి చేసాము మరియు దానిని వాణిజ్య కార్యకలాపాలకు ప్రారంభించాము.

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

మేము రెప్లికేషన్ ఫ్యాక్టర్ = 1తో SQLని ఉపయోగించినప్పుడు (కానీ RAID 10లో), మైక్రోసాఫ్ట్ SQL సర్వర్ (ప్లస్ 32 బ్యాకప్‌లు) నడుస్తున్న 11 మెషీన్‌ల యొక్క అత్యంత అందుబాటులో ఉన్న క్లస్టర్‌లో ఫోటో మెటైన్‌ఫర్మేషన్ నిల్వ చేయబడింది. బ్యాకప్‌లను నిల్వ చేయడానికి 10 సర్వర్‌లను కూడా కేటాయించారు. మొత్తం 50 ఖరీదైన కార్లు. అదే సమయంలో, సిస్టమ్ రిజర్వ్ లేకుండా, రేటెడ్ లోడ్ వద్ద నిర్వహించబడుతుంది.

కొత్త సిస్టమ్‌కి మారిన తర్వాత, మేము ప్రతి డేటా సెంటర్‌లో ప్రతిరూపణ అంశం = 3 - ఒక కాపీని అందుకున్నాము. సిస్టమ్‌లో 63 కాసాండ్రా స్టోరేజ్ నోడ్‌లు మరియు 6 కోఆర్డినేటర్ మెషీన్‌లు, మొత్తం 69 సర్వర్‌లు ఉన్నాయి. కానీ ఈ యంత్రాలు చాలా చౌకగా ఉంటాయి, వాటి మొత్తం ఖర్చు SQL వ్యవస్థ ఖర్చులో 30%. అదే సమయంలో, లోడ్ 30% వద్ద ఉంచబడుతుంది.

C*Oన్ పరిచయంతో, జాప్యం కూడా తగ్గింది: SQLలో, వ్రాత ఆపరేషన్ 4,5 ms పట్టింది. C*వన్‌లో - సుమారు 1,6 ms. లావాదేవీ వ్యవధి సగటున 40 ms కంటే తక్కువగా ఉంటుంది, కమిట్ 2 msలో పూర్తవుతుంది, చదవడం మరియు వ్రాయడం వ్యవధి సగటు 2 ms. 99వ పర్సంటైల్ - కేవలం 3-3,1 ms మాత్రమే, గడువు ముగిసే సమయాల సంఖ్య 100 రెట్లు తగ్గింది - అన్నీ ఊహాగానాల విస్తృత వినియోగం కారణంగా.

ఇప్పటికి, చాలా SQL సర్వర్ నోడ్‌లు నిలిపివేయబడ్డాయి; కొత్త ఉత్పత్తులు C*Oన్‌ని ఉపయోగించి మాత్రమే అభివృద్ధి చేయబడుతున్నాయి. మేము మా క్లౌడ్‌లో పని చేయడానికి C*వన్‌ని స్వీకరించాము ఒక-మేఘం, ఇది కొత్త క్లస్టర్‌ల విస్తరణను వేగవంతం చేయడం, కాన్ఫిగరేషన్‌ను సులభతరం చేయడం మరియు ఆపరేషన్‌ను ఆటోమేట్ చేయడం సాధ్యపడింది. సోర్స్ కోడ్ లేకుండా, దీన్ని చేయడం చాలా కష్టం మరియు గజిబిజిగా ఉంటుంది.

ఇప్పుడు మేము మా ఇతర నిల్వ సౌకర్యాలను క్లౌడ్‌కి బదిలీ చేయడానికి పని చేస్తున్నాము - కానీ అది పూర్తిగా భిన్నమైన కథ.

మూలం: www.habr.com