1.1 షేడింగ్ అంటే ఏమిటి?
మీరు పట్టుదలతో గూగుల్ చేస్తే, విభజన అని పిలవబడే మరియు షార్డింగ్ అని పిలవబడే వాటి మధ్య అస్పష్టమైన సరిహద్దు ఉందని తేలింది. అందరూ ఎవరికి ఏది కావాలంటే అది పిలుస్తుంది. కొందరు వ్యక్తులు క్షితిజసమాంతర విభజన మరియు షార్డింగ్ మధ్య తేడాను చూపుతారు. మరికొందరు షార్డింగ్ అనేది ఒక నిర్దిష్ట రకమైన క్షితిజ సమాంతర విభజన అని చెప్పారు.
వ్యవస్థాపక పితామహులచే ఆమోదించబడిన మరియు ISO ద్వారా ధృవీకరించబడిన ఒక పరిభాష ప్రమాణాన్ని నేను కనుగొనలేదు. వ్యక్తిగత అంతర్గత విశ్వాసం ఇలా ఉంటుంది: సగటున విభజన అనేది ఏకపక్షంగా తీసుకున్న విధంగా "బేస్ను ముక్కలుగా కత్తిరించడం".
- నిలువు విభజన - కాలమ్ ద్వారా. ఉదాహరణకు, 60 నిలువు వరుసలలో రెండు బిలియన్ల రికార్డులతో ఒక పెద్ద పట్టిక ఉంది. అటువంటి ఒక పెద్ద పట్టికను ఉంచడానికి బదులుగా, మేము 60 కనీసం 2 బిలియన్ల రికార్డుల భారీ పట్టికలను ఉంచుతాము - మరియు ఇది కాలమ్ బేస్ కాదు, నిలువు విభజన (పరిభాష యొక్క ఉదాహరణగా).
- క్షితిజసమాంతర విభజన - మేము లైన్ ద్వారా లైన్ కట్, బహుశా సర్వర్ లోపల.
ఇక్కడ ఇబ్బందికరమైన క్షణం క్షితిజ సమాంతర విభజన మరియు షార్డింగ్ మధ్య సూక్ష్మ వ్యత్యాసం. నేను ముక్కలుగా కట్ చేయవచ్చు, కానీ అది ఏమిటో నేను ఖచ్చితంగా చెప్పలేను. షార్డింగ్ మరియు క్షితిజ సమాంతర విభజన ఒకే విషయం గురించి ఒక భావన ఉంది.
షార్డింగ్ అనేది సాధారణంగా, డేటాబేస్ల పరంగా పెద్ద పట్టిక లేదా పత్రాల అనుకూల సేకరణ, వస్తువులు, మీకు డేటాబేస్ లేకపోతే, కానీ డాక్యుమెంట్ స్టోర్, వస్తువుల ద్వారా ఖచ్చితంగా కత్తిరించబడినప్పుడు. అంటే, 2 బిలియన్ వస్తువుల నుండి, ముక్కలు ఏ పరిమాణంలో ఉన్నా ఎంపిక చేయబడతాయి. ప్రతి వస్తువు లోపల ఉన్న వస్తువులు ముక్కలుగా కత్తిరించబడవు, మేము వాటిని వేర్వేరు నిలువు వరుసలుగా వేయము, అవి వేర్వేరు ప్రదేశాలలో బ్యాచ్లలో వేస్తాము.
సూక్ష్మ పరిభాషలో తేడాలు ఉన్నాయి. ఉదాహరణకు, సాపేక్షంగా చెప్పాలంటే, ప్రధాన పట్టిక విభజించబడిన అన్ని పట్టికలు ఒకే స్కీమాలో ఉన్నప్పుడు సమాంతర విభజన అని పోస్ట్గ్రెస్ డెవలపర్లు చెప్పగలరు మరియు వేర్వేరు మెషీన్లలో ఉన్నప్పుడు, ఇది ఇప్పటికే షార్డింగ్ అవుతుంది.
సాధారణ అర్థంలో, నిర్దిష్ట డేటాబేస్ మరియు నిర్దిష్ట డేటా మేనేజ్మెంట్ సిస్టమ్ యొక్క పరిభాషతో ముడిపడి ఉండకుండా, షార్డింగ్ అనేది పత్రం ద్వారా లైన్ / పత్రం ద్వారా లైన్ స్లైసింగ్ మరియు మొదలైనవి అనే భావన ఉంది - అంతే.
నేను విలక్షణంగా నొక్కి చెబుతున్నాను. 2 బిలియన్ డాక్యుమెంట్లను 20 టేబుల్లుగా కట్ చేయడానికి మాత్రమే కాకుండా, ప్రతి ఒక్కటి మరింత నిర్వహించదగినదిగా ఉంటుంది, కానీ అనేక కోర్లు, అనేక డిస్క్లు లేదా అనేక విభిన్న భౌతిక లేదా వర్చువల్ సర్వర్లలో పంపిణీ చేయడానికి మేము ఇవన్నీ చేస్తున్నాము.
1.2 అవిభాజ్యతను విభజించండి
ప్రతి ముక్క - ప్రతి డేటా - అనేక సార్లు ప్రతిరూపం అయ్యేలా మేము దీన్ని చేస్తాము. కానీ నిజంగా, లేదు.
INSERT INTO docs00
SELECT * FROM documents WHERE (id%16)=0
...
INSERT INTO docs15
SELECT * FROM documents WHERE (id%16)=15
వాస్తవానికి, మీరు అటువంటి డేటాను స్లైసింగ్ చేస్తే మరియు మీ వాలియంట్ ల్యాప్టాప్లోని MySQLలోని ఒక పెద్ద SQL టేబుల్ నుండి, మీరు 16 చిన్న టేబుల్లను ఉత్పత్తి చేస్తారు, ఒక్క ల్యాప్టాప్ దాటి వెళ్లకుండా, ఒక్క స్కీమా కాదు, ఒక్క డేటాబేస్ కూడా కాదు. . మరియు అందువలన న. - అంతే, మీకు ఇప్పటికే షార్డింగ్ ఉంది.
ఇది క్రింది ఫలితాన్ని ఇస్తుంది:
- బ్యాండ్విడ్త్ పెరుగుతుంది.
- జాప్యం మారదు, అంటే, ప్రతి ఒక్కరు మాట్లాడటానికి, ఈ సందర్భంలో కార్మికుడు లేదా వినియోగదారుడు తన స్వంతం చేసుకుంటాడు. వేర్వేరు అభ్యర్థనలు ఒకే సమయంలో అందించబడతాయి.
- లేదా రెండూ, మరియు మరొకటి, మరియు అధిక లభ్యత (ప్రతిరూపణ).
బ్యాండ్విడ్త్ ఎందుకు? మేము కొన్నిసార్లు సరిపోని డేటా వాల్యూమ్లను కలిగి ఉండవచ్చు - ఎక్కడ స్పష్టంగా లేదు, కానీ అవి సరిపోవు - 1 {కెర్నల్ | డిస్క్ | సర్వర్ | ...}. తగినంత వనరులు లేవు, అంతే. ఈ పెద్ద డేటాసెట్తో పని చేయడానికి, మీరు దీన్ని కట్ చేయాలి.
ఎందుకు జాప్యం? ఒక కోర్లో, 2 బిలియన్ వరుసల పట్టికను స్కాన్ చేయడం 20 కోర్లలో 20 టేబుల్లను స్కాన్ చేయడం కంటే 20 రెట్లు నెమ్మదిగా ఉంటుంది, దీన్ని సమాంతరంగా చేస్తుంది. ఒకే వనరుపై డేటా చాలా నెమ్మదిగా ప్రాసెస్ చేయబడుతుంది.
ఎందుకు అధిక లభ్యత? లేదా మేము ఒకే సమయంలో రెండింటినీ చేయడానికి డేటాను కత్తిరించాము మరియు అదే సమయంలో ప్రతి ముక్క యొక్క అనేక కాపీలు - ప్రతిరూపణ అధిక లభ్యతను నిర్ధారిస్తుంది.
1.3 ఒక సాధారణ ఉదాహరణ "చేతితో ఎలా చేయాలి"
32 డాక్యుమెంట్ల కోసం టెస్ట్ టేబుల్ టెస్ట్.డాక్యుమెంట్లను ఉపయోగించి షరతులతో కూడిన షార్డింగ్ను కత్తిరించవచ్చు మరియు ఈ టేబుల్ నుండి 16 టెస్ట్ టేబుల్లను రూపొందించవచ్చు, ఒక్కో టెస్ట్.డాక్స్00, 01, 02, ..., 15.
INSERT INTO docs00
SELECT * FROM documents WHERE (id%16)=0
...
INSERT INTO docs15
SELECT * FROM documents WHERE (id%16)=15
ఎందుకు గురించి? ఎందుకంటే 1 నుండి 32 వరకు కలుపుకుంటే, id ఎలా పంపిణీ చేయబడుతుందో మాకు తెలియదు కాబట్టి, ఒక్కొక్కటి ఖచ్చితంగా 2 పత్రాలు ఉంటాయి, లేకుంటే కాదు.
మేము ఇక్కడ ఎందుకు చేస్తాము. మేము 16 పట్టికలను తయారు చేసిన తర్వాత, మనకు అవసరమైన వాటిలో 16 "పట్టుకోవచ్చు". మనం కొట్టిన దానితో సంబంధం లేకుండా, మేము ఈ వనరులను సమాంతరంగా చేయవచ్చు. ఉదాహరణకు, తగినంత డిస్క్ స్థలం లేనట్లయితే, ఈ పట్టికలను ప్రత్యేక డిస్క్లలో కుళ్ళిపోవడానికి అర్ధమే.
ఇవన్నీ, దురదృష్టవశాత్తు, ఉచితం కాదు. కానానికల్ SQL ప్రమాణం విషయంలో (నేను చాలా కాలంగా SQL ప్రమాణాన్ని మళ్లీ చదవలేదు, బహుశా ఇది చాలా కాలంగా నవీకరించబడకపోవచ్చు), ఏదైనా SQL సర్వర్కి చెప్పడానికి అధికారిక ప్రామాణిక వాక్యనిర్మాణం లేదని నేను అనుమానిస్తున్నాను : "ప్రియమైన SQL సర్వర్, నన్ను 32 ముక్కలుగా చేసి, వాటిని 4 డిస్క్లుగా విభజించండి. కానీ వ్యక్తిగత అమలులలో, ప్రాథమికంగా అదే పని చేయడానికి తరచుగా నిర్దిష్ట వాక్యనిర్మాణం ఉంటుంది. PostgreSQL విభజన కోసం మెకానిజమ్లను కలిగి ఉంది, MySQL లో MariaDB ఉంది, Oracle బహుశా చాలా కాలం క్రితం ఇవన్నీ చేసింది.
అయినప్పటికీ, డేటాబేస్ మద్దతు లేకుండా మరియు స్టాండర్డ్ ఫ్రేమ్వర్క్లో మేము దీన్ని చేతితో చేస్తే, డేటా యాక్సెస్ సంక్లిష్టతతో మేము షరతులతో చెల్లిస్తాము . పత్రాల నుండి సాధారణ ఎంపిక * ఎక్కడ id=123, ఇప్పుడు 16 x ఎంపిక * డాక్స్XX నుండి. మరియు మేము కీ ద్వారా రికార్డు పొందడానికి ప్రయత్నించినట్లయితే అది మంచిది. మేము రికార్డుల ప్రారంభ శ్రేణిని పొందడానికి ప్రయత్నిస్తున్నట్లయితే మరింత ఆసక్తికరంగా ఉంటుంది. ఇప్పుడు (మేము, నేను నొక్కిచెప్పినట్లయితే, మూర్ఖులమని, మరియు ప్రమాణం యొక్క ఫ్రేమ్వర్క్లో ఉండిపోతే), ఈ 16 SELECT * FROM ఫలితాలను అప్లికేషన్లో కలపాలి.
మీరు ఏ పనితీరు మార్పును ఆశించవచ్చు?
- అకారణంగా - సరళ.
- సిద్ధాంతపరంగా - సబ్లీనియర్, ఎందుకంటే అమ్డాల్ చట్టం.
- ఆచరణాత్మకంగా, దాదాపు సరళంగా ఉండవచ్చు, కాకపోవచ్చు.
నిజానికి, సరైన సమాధానం తెలియదు. షార్డింగ్ టెక్నిక్ యొక్క తెలివైన అప్లికేషన్తో, మీరు మీ అప్లికేషన్ యొక్క పనితీరులో గణనీయమైన సూపర్-లీనియర్ డిగ్రేడేషన్ను సాధించవచ్చు మరియు DBA కూడా రెడ్-హాట్ పోకర్తో రన్ అవుతుంది.
దీన్ని ఎలా సాధించవచ్చో చూద్దాం. కేవలం సెట్టింగ్ను PostgreSQL shards=16కి సెట్ చేసి, ఆపై అది స్వతహాగా టేకాఫ్ చేయడం ఆసక్తికరంగా లేదని స్పష్టమవుతుంది. 32కి 16 రెట్లు తగ్గకుండా మనం ఎలా తగ్గించగలమో ఆలోచిద్దాం - దీన్ని ఎలా చేయకూడదనే కోణం నుండి ఇది ఆసక్తికరంగా ఉంటుంది.
వేగవంతం చేయడానికి లేదా వేగాన్ని తగ్గించడానికి మా ప్రయత్నాలు ఎల్లప్పుడూ క్లాసిక్లలోకి వస్తాయి - మంచి పాత అమ్డాల్ చట్టం, ఏదైనా అభ్యర్థనకు ఖచ్చితమైన సమాంతరీకరణ లేదని, ఎల్లప్పుడూ కొంత స్థిరమైన భాగం ఉంటుంది.
1.4 అమ్దాల్ చట్టం
ఎల్లప్పుడూ సీరియల్ భాగం ఉంటుంది.
క్వెరీ ఎగ్జిక్యూషన్లో ఎల్లప్పుడూ సమాంతరంగా ఉండే భాగం ఉంటుంది మరియు సమాంతరంగా లేని భాగం ఎల్లప్పుడూ ఉంటుంది. ఒక సంపూర్ణ సమాంతర ప్రశ్న అని మీకు అనిపించినా, కనీసం మీరు ప్రతి షార్డ్ నుండి అందుకున్న అడ్డు వరుసల నుండి క్లయింట్కు పంపబోయే ఫలిత వరుస యొక్క సేకరణ ఎల్లప్పుడూ ఉంటుంది మరియు ఇది ఎల్లప్పుడూ సీక్వెన్షియల్గా ఉంటుంది.
ఎల్లప్పుడూ కొంత స్థిరమైన భాగం ఉంటుంది. ఇది చిన్నది కావచ్చు, సాధారణ నేపథ్యానికి వ్యతిరేకంగా పూర్తిగా కనిపించదు, ఇది బ్రహ్మాండమైనది మరియు తదనుగుణంగా, సమాంతరీకరణను బలంగా ప్రభావితం చేస్తుంది, కానీ ఇది ఎల్లప్పుడూ ఉనికిలో ఉంటుంది.
అదనంగా, దాని ప్రభావం మారుతోంది మరియు గణనీయంగా పెరుగుతుంది, ఉదాహరణకు, మేము మా పట్టికను కత్తిరించినట్లయితే - వాటాలను పెంచుకుందాం - 64 రికార్డుల నుండి 4 రికార్డుల 16 పట్టికలుగా, ఈ భాగం మారుతుంది. వాస్తవానికి, ఇంత పెద్ద మొత్తంలో డేటాను బట్టి చూస్తే, మేము మొబైల్ ఫోన్ మరియు 2 MHz 86 ప్రాసెసర్లో పని చేస్తున్నాము మరియు అదే సమయంలో తెరిచి ఉంచగల తగినంత ఫైల్లు మా వద్ద లేవు. స్పష్టంగా, అటువంటి ఇన్పుట్లతో, మేము ఒక సమయంలో ఒక ఫైల్ను తెరుస్తాము.
- ఇది మొత్తం = సీరియల్ + సమాంతరం . ఎక్కడ, ఉదాహరణకు, DB లోపల పని అంతా సమాంతరంగా ఉంటుంది మరియు సీరియల్ ఫలితాన్ని క్లయింట్కు పంపుతుంది.
- మొత్తం 2 = సీరియల్ + సమాంతరం/N + Xserial అయింది . ఉదాహరణకు, మొత్తం ఆర్డర్ ద్వారా Xserial>0.
ఈ సాధారణ ఉదాహరణతో, నేను కొన్ని Xserial కనిపించేలా చూపించడానికి ప్రయత్నిస్తున్నాను. ఎల్లప్పుడూ సీరియలైజ్ చేయబడిన భాగం మరియు మేము డేటాతో సమాంతరంగా పని చేయడానికి ప్రయత్నిస్తున్నాము అనే వాస్తవంతో పాటు, ఈ డేటా స్లైసింగ్ను అందించడానికి అదనపు భాగం ఉంది. స్థూలంగా చెప్పాలంటే, మనకు అవసరం కావచ్చు:
- డేటాబేస్ యొక్క అంతర్గత నిఘంటువులో ఈ 16 పట్టికలను కనుగొనండి;
- ఫైళ్లను తెరవండి;
- మెమరీని కేటాయించండి;
- మెమరీని కేటాయించవద్దు;
- ఫలితాలను విలీనం చేయండి;
- కోర్ల మధ్య సమకాలీకరించండి.
కొన్ని సమకాలీకరణ లేని ప్రభావాలు ఇప్పటికీ కనిపిస్తాయి. అవి చాలా తక్కువగా ఉంటాయి మరియు మొత్తం సమయంలో బిలియన్ వంతును ఆక్రమించవచ్చు, కానీ అవి ఎల్లప్పుడూ సున్నా కానివి మరియు ఎల్లప్పుడూ ఉంటాయి. వారి సహాయంతో, మేము షార్డింగ్ తర్వాత పనితీరును నాటకీయంగా కోల్పోతాము.
![](https://cdn.codegym.cc/images/article/271eab10-2784-46cd-bc06-65a0aa0211c7/1024.jpeg)
ఇది అమ్డాల్ చట్టం గురించి ప్రామాణిక చిత్రం. ఇక్కడ ముఖ్యమైన విషయం ఏమిటంటే, పంక్తులు, ఆదర్శంగా నేరుగా మరియు సరళంగా పెరగాలి, ఇది ఒక లక్షణంగా ఉంటుంది. కానీ ఇంటర్నెట్ నుండి గ్రాఫ్ చదవలేనిది కనుక, నేను నా అభిప్రాయం ప్రకారం, సంఖ్యలతో మరిన్ని దృశ్య పట్టికలను తయారు చేసాను.
అభ్యర్థన ప్రాసెసింగ్లో 5% మాత్రమే తీసుకునే కొంత సీరియల్ భాగం మన వద్ద ఉందని చెప్పండి: సీరియల్ = 0.05 = 1/20 .
అకారణంగా, అభ్యర్థన ప్రాసెసింగ్లో 1/20 మాత్రమే తీసుకునే సీరియలైజ్డ్ పార్ట్తో, మేము 20 కోర్ల కోసం అభ్యర్థన ప్రాసెసింగ్ను సమాంతరంగా చేస్తే, అది దాదాపు 20 అవుతుంది, చెత్త సందర్భంలో 18 రెట్లు వేగంగా ఉంటుంది.
నిజానికి, గణితం హృదయం లేని విషయం :
గోడ = 0.05 + 0.95/num_cores, స్పీడప్ = 1 / (0.05 + 0.95/num_cores)
మీరు 5% సీరియలైజ్డ్ భాగంతో జాగ్రత్తగా లెక్కించినట్లయితే, స్పీడప్ 10 రెట్లు (10.3) ఉంటుంది, ఇది సైద్ధాంతిక ఆదర్శంతో పోలిస్తే 51%.
8 కోర్లు | = 5.9 | = 74% |
10 కోర్లు | = 6.9 | = 69% |
20 కోర్లు | = 10.3 | = 51% |
40 కోర్లు | = 13.6 | = 34% |
128 కోర్లు | = 17.4 | = 14% |
ఒకరు పని చేసే పని కోసం 20 కోర్లను (20 డిస్క్లు, మీకు నచ్చితే) ఉపయోగించిన తర్వాత, మేము ఎప్పటికీ సిద్ధాంతపరంగా 20 రెట్ల కంటే ఎక్కువ త్వరణాన్ని పొందలేము, కానీ ఆచరణలో - చాలా తక్కువ. అంతేకాకుండా, సమాంతరాల సంఖ్య పెరుగుదలతో, అసమర్థత బాగా పెరుగుతుంది.
సీరియలైజ్ చేసిన పనిలో 1% మాత్రమే మిగిలి, మరియు 99% సమాంతరంగా ఉన్నప్పుడు, స్పీడప్ విలువలు కొంత మెరుగుపడతాయి:
8 కోర్లు | = 7.5 | = 93% |
16 కోర్లు | = 13.9 | = 87% |
32 కోర్లు | = 24.4 | = 76% |
64 కోర్లు | = 39.3 | = 61% |
ఖచ్చితమైన థర్మోన్యూక్లియర్ ప్రశ్న కోసం, సహజంగా పూర్తి చేయడానికి గంటలు పడుతుంది, మరియు సన్నాహక పని మరియు ఫలితం యొక్క అసెంబ్లీ చాలా తక్కువ సమయం పడుతుంది (సీరియల్ = 0.001), మేము ఇప్పటికే మంచి సామర్థ్యాన్ని చూస్తాము:
8 కోర్లు | = 7.94 | = 99% |
16 కోర్లు | = 15.76 | = 99% |
32 కోర్లు | = 31.04 | = 97% |
64 కోర్లు | = 60.20 | = 94% |
మేము 100% చూడలేమని దయచేసి గమనించండి . ముఖ్యంగా మంచి సందర్భాలలో, మీరు ఉదాహరణకు, 99.999% చూడవచ్చు, కానీ సరిగ్గా 100% కాదు.
GO TO FULL VERSION