షార్డింగ్: రివర్స్ సైడ్

2.1 N సమయాలను ముక్కలు చేయడం మరియు వేగాన్ని తగ్గించడం ఎలా?

మీరు ఈ విధంగా సరిగ్గా N సార్లు ముక్కలు చేయవచ్చు మరియు వేగాన్ని తగ్గించవచ్చు:

• docs00...docs15 అభ్యర్థనలను సమాంతరంగా కాకుండా వరుసగా పంపండి .
• సాధారణ ప్రశ్నలలో, కీ ద్వారా కాకుండా ఎంపిక చేయండి , WHERE something=234.

ఈ సందర్భంలో, ధారావాహిక భాగం (సీరియల్) 1% కాదు మరియు 5% కాదు, ఆధునిక డేటాబేస్‌లలో సుమారు 20% పడుతుంది. మీరు విపరీతమైన సమర్థవంతమైన బైనరీ ప్రోటోకాల్‌ని ఉపయోగించి డేటాబేస్‌ను యాక్సెస్ చేసినట్లయితే లేదా పైథాన్ స్క్రిప్ట్‌కి డైనమిక్ లైబ్రరీగా లింక్ చేసినట్లయితే మీరు 50% సీరియలైజ్ చేసిన భాగాన్ని కూడా పొందవచ్చు.

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

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

అకస్మాత్తుగా, షార్డింగ్ చేసేటప్పుడు ప్రోగ్రామింగ్ లాంగ్వేజ్ ఎంపిక ముఖ్యం.

ప్రోగ్రామింగ్ లాంగ్వేజ్ ఎంపిక గురించి గుర్తుంచుకోండి, ఎందుకంటే మీరు డేటాబేస్ (లేదా శోధన సర్వర్)కి వరుసగా ప్రశ్నలను పంపితే, త్వరణం ఎక్కడ నుండి వస్తుంది? బదులుగా, మందగమనం ఉంటుంది.

2.2 సెమీ ఆటోమేటిక్ గురించి

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

వ్యక్తిగత DBAల నేపథ్యంలో మానవత్వంతో బాధపడుతున్న మానవత్వం సంవత్సరాలుగా వేధించబడింది మరియు ఏమీ లేకుండా అనేక చెడ్డ షార్డింగ్ పరిష్కారాలను వ్రాస్తుంది. ఆ తర్వాత, ProxySQL (MariaDB/Spider, PG/pg_shard/Citus, ...) అని పిలువబడే ఒకటి ఎక్కువ లేదా తక్కువ మంచి షార్డింగ్ సొల్యూషన్ వ్రాయబడుతుంది. ఈ మచ్చకు ఇది బాగా తెలిసిన ఉదాహరణ.

ProxySQL మొత్తంగా, ఓపెన్ సోర్స్, రూటింగ్ మరియు మరిన్నింటి కోసం పూర్తి స్థాయి ఎంటర్‌ప్రైజ్-క్లాస్ పరిష్కారం. కానీ పరిష్కరించాల్సిన పనులలో ఒకటి డేటాబేస్ కోసం షేడింగ్ చేయడం, ఇది మానవ మార్గంలో విభజించబడదు. మీరు చూడండి, "షార్డ్స్ = 16" స్విచ్ లేదు, మీరు అప్లికేషన్‌లోని ప్రతి అభ్యర్థనను తిరిగి వ్రాయాలి మరియు వాటిలో చాలా ప్రదేశాలలో ఉన్నాయి లేదా కనిపించే అప్లికేషన్ మరియు డేటాబేస్ మధ్య కొన్ని ఇంటర్మీడియట్ లేయర్‌ను ఉంచండి: "హ్మ్ ... పత్రాల నుండి * ఎంచుకోండి? అవును, ఇది తప్పనిసరిగా 16 చిన్న SELECT * FROM server1.document1, SELECT * FROM server2.document2 - అటువంటి లాగిన్ / పాస్‌వర్డ్‌తో ఈ సర్వర్‌కు, మరొక దానితో విభజించబడాలి. ఒకరు సమాధానం ఇవ్వకపోతే, అప్పుడు ... ", మొదలైనవి. సరిగ్గా ఇది ఇంటర్మీడియట్ బ్లాట్చెస్ ద్వారా చేయవచ్చు. అవి అన్ని డేటాబేస్‌ల కంటే కొంచెం తక్కువగా ఉంటాయి. PostgreSQL కోసం, నేను అర్థం చేసుకున్నంత వరకు,

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

2.3 సంపూర్ణ పరిపూర్ణ ఆటోమేషన్?

ఈ అక్షరం F() లో షార్డింగ్ విషయంలో ఎక్కువ పొందే మొత్తం సిద్ధాంతం , ప్రాథమిక సూత్రం ఎల్లప్పుడూ దాదాపు ఒకే విధంగా ఉంటుంది: shard_id = F(ఆబ్జెక్ట్).

షార్డింగ్ - ఇది దేని గురించి? మాకు 2 బిలియన్ రికార్డులు ఉన్నాయి (లేదా 64). మేము వాటిని అనేక ముక్కలుగా విభజించాలనుకుంటున్నాము. ఊహించని ప్రశ్న తలెత్తుతుంది - ఎలా? నాకు అందుబాటులో ఉన్న 16 సర్వర్‌లలో నేను నా 2 బిలియన్ రికార్డులను (లేదా 64) ఏ సూత్రం ప్రకారం వెదజల్లాలి?

మనలోని గుప్త గణిత శాస్త్రజ్ఞుడు ప్రతి పత్రానికి (వస్తువు, పంక్తి, మొదలైనవి) ఏ ముక్కలో ఉంచాలో నిర్ణయించే కొన్ని మ్యాజిక్ ఫంక్షన్ ఎల్లప్పుడూ ఉంటుందని సూచించాలి.

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

shard_func = F1(object); 
shard_id = F2(shard_func, ...); 
shard_id = F2(F1(object), current_num_shards, ...). 

అయితే మేము వ్యక్తిగత ఫంక్షన్ల యొక్క ఈ వైల్డ్‌లను త్రవ్వము, F () అనే మ్యాజిక్ ఫంక్షన్‌ల గురించి మాట్లాడుతాము.

2.4 F() అంటే ఏమిటి?

వారు అనేక విభిన్న మరియు అనేక విభిన్న అమలు విధానాలతో రావచ్చు. నమూనా సారాంశం:

• F = rand() % nums_shards
• F = somehash(object.id) % num_shards
• F = object.date % num_shards
• F = object.user_id % num_shards
• ...
• F = shard_table [ somehash() |… object.date |… ]

ఒక ఆసక్తికరమైన వాస్తవం - మీరు సహజంగా మొత్తం డేటాను యాదృచ్ఛికంగా చెదరగొట్టవచ్చు - మేము తదుపరి రికార్డును ఏకపక్ష సర్వర్‌లో, ఏకపక్ష కోర్‌లో, ఏకపక్ష పట్టికలో త్రోసివేస్తాము. ఇందులో చాలా ఆనందం ఉండదు, కానీ అది పని చేస్తుంది.

పునరుత్పాదక లేదా స్థిరమైన హాష్ ఫంక్షన్ ద్వారా లేదా కొంత లక్షణం ద్వారా షార్డ్ చేయడానికి కొంచెం ఎక్కువ తెలివైన పద్ధతులు ఉన్నాయి. ఒక్కో పద్ధతిని పరిశీలిద్దాం.

F = రాండ్()

చుట్టూ చెదరగొట్టడం చాలా సరైన పద్ధతి కాదు. ఒక సమస్య: మేము మా 2 బిలియన్ రికార్డ్‌లను యాదృచ్ఛికంగా వెయ్యి సర్వర్‌లలో చెల్లాచెదురు చేసాము మరియు రికార్డ్ ఎక్కడ ఉందో మాకు తెలియదు. మేము user_1ని తీసివేయాలి, కానీ అది ఎక్కడ ఉందో మాకు తెలియదు. మేము వెయ్యి సర్వర్‌లకు వెళ్లి ప్రతిదానిని క్రమబద్ధీకరిస్తాము - ఏదో ఒకవిధంగా ఇది అసమర్థమైనది.

F = సోమ్‌హాష్()

వినియోగదారులను వయోజన మార్గంలో స్కాటర్ చేద్దాం: user_id నుండి పునరుత్పాదక హాష్ ఫంక్షన్‌ను లెక్కించండి, సర్వర్‌ల సంఖ్య ద్వారా మిగిలిన విభజనను తీసుకోండి మరియు వెంటనే కావలసిన సర్వర్‌ను సంప్రదించండి.

ఎందుకు ఇలా చేస్తున్నాం? ఆపై, మనకు హైలోడ్ ఉంది మరియు మరేమీ ఒక సర్వర్‌కి సరిపోదు. అది సరిపోతే, జీవితం చాలా సరళంగా ఉంటుంది.

అద్భుతం, పరిస్థితి ఇప్పటికే మెరుగుపడింది, ఒక రికార్డును పొందడానికి, మేము ముందుగా తెలిసిన సర్వర్‌కి వెళ్తాము. కానీ మనకు కీల శ్రేణి ఉంటే, ఈ మొత్తం శ్రేణిలో మనం కీల యొక్క అన్ని విలువలను పరిశీలించాలి మరియు పరిమితిలో, మనకు పరిధిలో ఉన్న కీలన్నింటికి లేదా వాటికి కూడా వెళ్లాలి. ప్రతి సర్వర్. పరిస్థితి మెరుగుపడింది, అయితే అన్ని అభ్యర్థనలకు కాదు. కొన్ని ప్రశ్నలు ప్రభావితమయ్యాయి.

సహజ షార్డింగ్ (F = object.date % num_shards)

కొన్నిసార్లు, అంటే, తరచుగా, ట్రాఫిక్‌లో 95% మరియు లోడ్‌లో 95% కొంత రకమైన సహజమైన షేడింగ్‌ను కలిగి ఉండే అభ్యర్థనలు. ఉదాహరణకు, 95% షరతులతో కూడిన సామాజిక-విశ్లేషణాత్మక ప్రశ్నలు గత 1 రోజు, 3 రోజులు, 7 రోజులు మాత్రమే డేటాను ప్రభావితం చేస్తాయి మరియు మిగిలిన 5% గత కొన్ని సంవత్సరాలకు సంబంధించినవి. కానీ 95% అభ్యర్థనలు సహజంగా తేదీ ద్వారా విభజించబడ్డాయి, సిస్టమ్ వినియోగదారుల ఆసక్తి గత కొన్ని రోజులుగా కేంద్రీకృతమై ఉంది.

ఈ సందర్భంలో, మీరు డేటాను తేదీ ద్వారా విభజించవచ్చు, ఉదాహరణకు, ఒక రోజు ద్వారా, మరియు ఈ రోజు నుండి ఈ షార్డ్‌కు కొంత రోజు లేదా ఒక వస్తువు కోసం నివేదిక కోసం అభ్యర్థనకు ప్రతిస్పందనను అనుసరించండి మరియు వెళ్లండి.

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

మేము ప్రతిదానికీ ఆదర్శవంతమైన పరిష్కారంతో ముందుకు వచ్చినట్లు అనిపిస్తుంది, కానీ రెండు సమస్యలు ఉన్నాయి:

• 95% అభ్యర్థనలు గత వారం మాత్రమే కలిగి ఉన్నప్పుడు, ఈ పరిష్కారం నిర్దిష్ట కేసు కోసం రూపొందించబడింది.
• 95% అభ్యర్థనలు గత వారం తాకినందున, అవన్నీ గత వారం అందించిన ఒక షార్డ్‌పై వస్తాయి. ఈ ముక్క కరిగిపోతుంది, మిగిలినవన్నీ ఈ సమయంలో పనిలేకుండా ఉంటాయి. అదే సమయంలో, మీరు వాటిని విసిరివేయలేరు; ఆర్కైవల్ డేటా కూడా నిల్వ చేయబడాలి.

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

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

2.5 ధర చెల్లించాలి

అధికారికంగా, ఇప్పుడు మనకు "ప్రతిదీ" తెలుసునని తెలుసు. నిజమే, మనకు ఒక పెద్ద తలనొప్పి మరియు రెండు చిన్న తలనొప్పి తెలియదు.

1. సాధారణ నొప్పి: చెడుగా అద్ది

ఇది పాఠ్యపుస్తకం నుండి ఒక ఉదాహరణ, ఇది యుద్ధంలో దాదాపు ఎప్పుడూ జరగదు, కానీ అకస్మాత్తుగా.

• తేదీతో ఉదాహరణగా, తేదీ లేకుండా మాత్రమే!
• అనుకోకుండా అసమాన (గ్రహించదగిన) పంపిణీ.

వారు షార్డింగ్ మెకానిజంను ఎంచుకున్నారు మరియు/లేదా డేటా మార్చబడింది మరియు, వాస్తవానికి, PM అవసరాలను తెలియజేయలేదు (మాకు కోడ్‌లో లోపాలు లేవు, PM ఎల్లప్పుడూ అవసరాలను నివేదించదు) మరియు పంపిణీ భయంకరంగా అసమానంగా మారింది. అంటే, వారు ప్రమాణం తప్పిపోయారు.

పట్టుకోవడానికి, మీరు ముక్కల పరిమాణాన్ని చూడాలి. మన ముక్కలలో ఒకటి వేడెక్కినప్పుడు లేదా ఇతరులకన్నా 100 రెట్లు పెద్దదిగా మారినప్పుడు మేము ఖచ్చితంగా సమస్యను చూస్తాము. మీరు కీ లేదా షార్డింగ్ ఫంక్షన్‌ను భర్తీ చేయడం ద్వారా దాన్ని పరిష్కరించవచ్చు.

ఇది ఒక సాధారణ సమస్య, నిజం చెప్పాలంటే, జీవితంలో వంద మందిలో కనీసం ఒక్కరైనా ఈ సమస్యను ఎదుర్కొంటారని నేను అనుకోను, కానీ అకస్మాత్తుగా ఇది కనీసం ఎవరికైనా సహాయం చేస్తుంది.

2. "ఇన్విన్సిబుల్" నొప్పి: అగ్రిగేషన్, చేరండి

ఒక టేబుల్ నుండి బిలియన్ రికార్డ్‌లను మరొక టేబుల్ నుండి బిలియన్ రికార్డ్‌లకు చేరే ఎంపికలను ఎలా చేయాలి?

• "త్వరగా" ఎలా లెక్కించాలి... aaa మరియు bbb మధ్య రాండ్‌కోల్ ఎక్కడ ఉంది?
• "స్మార్ట్‌గా" ఎలా చేయాలి... users_32shards JOIN posts_1024 shards?

చిన్న సమాధానం: ఏ విధంగానూ, బాధ!

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

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

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

2.6 కాంప్లెక్స్/లాంగ్ పెయిన్: రీషార్డింగ్

సిద్ధంగా ఉండండి: మీరు మీ జీవితంలో మొదటిసారిగా మీ డేటాను షేర్ చేసినట్లయితే, సగటున మీరు దానిని మరో ఐదుసార్లు పంచుకుంటారు.

మీరు ఎన్ని క్లస్టర్‌లను కాన్ఫిగర్ చేసినప్పటికీ, మీరు ఇంకా రీహార్డ్ చేయాలి.

మీరు చాలా తెలివైనవారు మరియు అదృష్టవంతులు అయితే, కనీసం ఒక్కసారైనా ఓవర్‌షార్డ్ చేయండి. కానీ ఒకసారి మీరు ఖచ్చితంగా తెలుసుకుంటారు, ఎందుకంటే వినియోగదారుకు 10 యూనిట్లు సరిపోతాయని మీరు భావించే సమయంలో, ఆ సమయంలో ఎవరైనా 30 కోసం అభ్యర్థనను వ్రాస్తారు మరియు 100 యూనిట్ల తెలియని వనరుల కోసం అభ్యర్థనను కలిగి ఉండాలని యోచిస్తున్నారు. ముక్కలు ఎప్పుడూ సరిపోవు. మొదటి భాగస్వామ్య పథకంతో, ఏ సందర్భంలోనైనా, మీరు తప్పిపోతారు - మీరు ఎల్లప్పుడూ జోడించడానికి సర్వర్‌ల సంఖ్యను పెంచాలి లేదా మరేదైనా చేయాలి - సాధారణంగా, డేటాను తిరిగి ప్యాకేజ్ చేయండి.

మనకు రెండు మంచి పవర్‌లు ఉంటే మంచిది: 16 సర్వర్ షార్డ్‌లు ఉన్నాయి, ఇప్పుడు అది 32. ఇది 17 అయితే మరింత సరదాగా ఉంటుంది, ఇది 23 - రెండు వాసిమల్లీ ప్రధాన సంఖ్యలు. డేటాబేస్లు దీన్ని ఎలా చేస్తాయి, బహుశా వాటిలో కొన్ని రకాల మేజిక్ ఉందా?

సరైన సమాధానం: లేదు, లోపల మాయాజాలం లేదు, వారి లోపల నరకం ఉంది.

తరువాత, "చేతితో" ఏమి చేయవచ్చో మేము పరిశీలిస్తాము, బహుశా మేము "ఆటోమేటిక్ మెషీన్గా" అర్థం చేసుకుంటాము.

నుదిటిపై #1. ప్రతిదీ మార్చండి

అన్ని ఆబ్జెక్ట్‌ల కోసం, మేము NewF(ఆబ్జెక్ట్)ని పరిగణిస్తాము, కొత్త షార్డ్‌కి మారండి.

NewF()=OldF() సరిపోలే అవకాశం తక్కువ.

దాదాపు ప్రతిదీ కవర్ చేద్దాం.

ఓ.

అన్ని 2 బిలియన్ల రికార్డులను పాత ముక్కల నుండి కొత్త వాటికి బదిలీ చేయడానికి అలాంటి నరకం లేదని నేను ఆశిస్తున్నాను. అమాయక విధానం అర్థమయ్యేలా ఉంది: 17 యంత్రాలు ఉన్నాయి, క్లస్టర్‌కు 6 యంత్రాలు జోడించబడ్డాయి, 2 బిలియన్ రికార్డులు క్రమబద్ధీకరించబడ్డాయి, అవి 17 యంత్రాల నుండి 23 యంత్రాలకు మార్చబడ్డాయి. ప్రతి 10 సంవత్సరాలకు ఒకసారి, మీరు బహుశా దీన్ని కూడా చేయవచ్చు. కానీ మొత్తంగా ఇది చెడ్డ చర్య.

నుదిటిపై #2. సగం మార్చండి

తదుపరి అమాయక మెరుగుదల - అటువంటి తెలివితక్కువ పథకాన్ని వదిలివేద్దాం - 17 కార్లను 23కి మార్చకుండా నిషేధిస్తుంది మరియు మేము ఎల్లప్పుడూ 16 కార్లను 32 కార్లుగా మారుస్తాము! అప్పుడు, సిద్ధాంతం ప్రకారం, మేము సరిగ్గా సగం డేటాను మార్చవలసి ఉంటుంది మరియు ఆచరణలో మనం కూడా దీన్ని చేయవచ్చు.

అన్ని ఆబ్జెక్ట్‌ల కోసం, మేము NewF(ఆబ్జెక్ట్)ని పరిగణిస్తాము, కొత్త షార్డ్‌కి మారండి.

ఇది ఖచ్చితంగా 2^N, ఇప్పుడు అది ఖచ్చితంగా 2^(N+1) ముక్కలు.

NewF()=OldF()ని సరిపోలే సంభావ్యత 0.5.

50% డేటాను బదిలీ చేద్దాం.

సరైనది, కానీ రెండు శక్తులకు మాత్రమే పని చేస్తుంది.

సూత్రప్రాయంగా, కార్ల సంఖ్య పరంగా రెండు శక్తికి బైండింగ్ తప్ప, ప్రతిదీ బాగానే ఉంది. ఈ అమాయక విధానం, అసాధారణంగా తగినంత, పని చేయవచ్చు.

ఈ సందర్భంలో రెండు అధికారాల ద్వారా క్లస్టర్ యొక్క అదనపు విభజన కూడా సరైనదని దయచేసి గమనించండి. ఏది ఏమైనప్పటికీ, 16 మెషీన్‌లను 16 క్లస్టర్‌కి జోడించడం ద్వారా, మేము డేటాలో సగాన్ని మార్చడానికి బాధ్యత వహిస్తాము - సరిగ్గా సగం మరియు షిఫ్ట్.

సరే, కానీ మానవజాతి నిజంగా ఇంకేమీ కనిపెట్టలేదా - ప్రశ్న ఒక పరిశోధనాత్మక మనస్సు నుండి పుడుతుంది.

మరింత వినోదం #3. స్థిరమైన హ్యాషింగ్

వాస్తవానికి, స్థిరమైన హ్యాషింగ్ గురించి సర్కిల్‌తో కూడిన చిత్రం ఇక్కడ అవసరం.

మీరు “స్థిరమైన హ్యాషింగ్” అని గూగుల్ చేస్తే, ఒక సర్కిల్ ఖచ్చితంగా బయటకు వస్తుంది, అన్ని ఫలితాలు సర్కిల్‌లతో నిండి ఉంటాయి.

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

ఒక చిన్న ముక్కను జోడించేటప్పుడు: మేము ప్రతిదీ కాకుండా, 2 "పొరుగు" మాత్రమే చూస్తాము, మేము సగటున 1/nకి మారుస్తాము.

షార్డ్‌ను తొలగిస్తున్నప్పుడు: మేము తొలగించబడుతున్న షార్డ్‌ను మాత్రమే చూస్తాము, మేము దానిని మాత్రమే మారుస్తాము. సరైన రకం.

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

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

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

అయినప్పటికీ, మొదటి పద్ధతులతో పోలిస్తే, జీవితం మెరుగుపడింది - ఒక ముక్కను జోడించేటప్పుడు / తీసివేసేటప్పుడు, మేము ఇప్పటికే అన్ని రికార్డులను కాకుండా, ఒక భాగాన్ని మాత్రమే పరిశీలిస్తాము మరియు కొంత భాగాన్ని మాత్రమే మారుస్తాము.

శ్రద్ధ, ప్రశ్న: ఇది మరింత మెరుగుపరచబడుతుందా? మరియు షార్డ్‌లను లోడ్ చేయడం యొక్క ఏకరూపతను కూడా మెరుగుపరచాలా? సాధ్యమే అంటున్నారు!

మరింత వినోదం #4. రెండెజౌస్/HRW

తదుపరి సాధారణ ఆలోచన (మెటీరియల్ విద్యాపరమైనది, కాబట్టి సంక్లిష్టంగా ఏమీ లేదు): shard_id = arg max hash(object_id, shard_id).

దీన్ని రెండెజౌస్ హ్యాషింగ్ అని ఎందుకు పిలుస్తారో నాకు తెలియదు, కానీ దీన్ని హైయెస్ట్ రాండమ్ వెయిట్ అని ఎందుకు అంటారో నాకు తెలుసు. దీన్ని ఇలా దృశ్యమానం చేయడం చాలా సులభం:

ఉదాహరణకు, మనకు 16 ముక్కలు ఉన్నాయి. ఎక్కడో ఉంచాల్సిన ప్రతి వస్తువు (స్ట్రింగ్) కోసం, మేము షార్డ్ నంబర్ నుండి వస్తువును బట్టి 16 హాష్‌లను లెక్కిస్తాము. ఎవరు ఎక్కువ హాష్ విలువను కలిగి ఉన్నారో వారు గెలుస్తారు.

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

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

మరొక సమస్య ఏమిటంటే, ఇది పెద్ద సంఖ్యలో ముక్కలతో గణనపరంగా భారీగా ఉంటుంది.

మరింత వినోదం #5. మరిన్ని పద్ధతులు

ఆసక్తికరంగా, పరిశోధన ఇప్పటికీ నిలబడదు మరియు Google ప్రతి సంవత్సరం కొన్ని కొత్త అంతరిక్ష సాంకేతికతను ప్రచురిస్తుంది:

• జంప్ హాష్ - Google '2014.
• మల్టీ ప్రోబ్—Google '2015.
• మాగ్లేవ్-గూగుల్ '2016.

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

ముగింపులు

గాలియస్ జూలియస్ సీజర్ పేరు మీద షార్డింగ్ అనే ముఖ్యమైన ప్రాథమిక సాంకేతికత ఉంది: "డివైడ్ అండ్ రూల్, రూల్ అండ్ డివైడ్!". డేటా ఒక సర్వర్‌కు సరిపోకపోతే, దానిని 20 సర్వర్‌లుగా విభజించడం అవసరం.

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

దీన్ని చేతితో చేయకపోవడమే మంచిది, “బేస్” (శోధన, DFS, ...) స్వయంగా ముక్కలు చేయగలగడం మంచిది. ఏదైనా సందర్భంలో, ముందుగానే లేదా తరువాత, హైలోడ్ వస్తుంది మరియు ఏదో ఒకవిధంగా డేటాను విభజించవలసి ఉంటుంది. ఆధారం తనంతట తానుగా చేయగలిగినప్పటికీ, మీరు ఎటువంటి సమస్యలను ఎదుర్కోరు అనేది వాస్తవం కాదు. అల్గోరిథమిక్ ఫండమెంటలిజం గురించి గుర్తుంచుకోండి - ప్రతిదీ లోపల ఎలా పనిచేస్తుందో మీరు అర్థం చేసుకోవాలి.

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