ஷார்டிங்: தலைகீழ் பக்கம்

2.1 N முறைகளை எவ்வாறு பிரிப்பது மற்றும் மெதுவாக்குவது?

நீங்கள் இதைப் போன்ற சரியாக N முறை துண்டாக்கலாம் மற்றும் வேகத்தைக் குறைக்கலாம்:

• docs00...docs15 கோரிக்கைகளை வரிசையாக அனுப்பவும் , இணையாக அல்ல.
• எளிய வினவல்களில், விசை மூலம் அல்ல , எங்கே ஏதாவது=234 தேர்வு செய்யவும் .

இந்த வழக்கில், வரிசைப்படுத்தப்பட்ட பகுதி (தொடர்) 1% மற்றும் 5% அல்ல, ஆனால் நவீன தரவுத்தளங்களில் சுமார் 20% ஆகும். நீங்கள் பெருமளவில் திறமையான பைனரி நெறிமுறையைப் பயன்படுத்தி தரவுத்தளத்தை அணுகினால் அல்லது பைதான் ஸ்கிரிப்டில் டைனமிக் லைப்ரரியாக இணைத்தால் 50% வரிசைப்படுத்தப்பட்ட பகுதியைப் பெறலாம்.

ஒரு எளிய கோரிக்கையின் மீதமுள்ள செயலாக்க நேரம், கோரிக்கையை பாகுபடுத்துதல், திட்டத்தைத் தயாரித்தல் போன்றவற்றின் இணையற்ற செயல்பாடுகளால் ஆக்கிரமிக்கப்படும். அதாவது பதிவைப் படிக்காதது குறைகிறது.

PHP நிரலாக்க மொழியில் வழக்கப்படி, தரவை 16 அட்டவணைகளாகப் பிரித்து தொடர்ச்சியாக இயக்கினால், எடுத்துக்காட்டாக, (ஒத்திசைவற்ற செயல்முறைகளைத் தொடங்குவதில் இது மிகவும் நல்லதல்ல), பின்னர் 16 மடங்கு மந்தநிலையைப் பெறுவோம். மற்றும், ஒருவேளை, இன்னும் அதிகமாக, ஏனெனில் நெட்வொர்க் சுற்று பயணங்களும் சேர்க்கப்படும்.

திடீரென்று, ஷார்டிங் செய்யும் போது நிரலாக்க மொழியின் தேர்வு முக்கியமானது.

நிரலாக்க மொழியின் தேர்வு பற்றி நினைவில் கொள்ளுங்கள், ஏனெனில் நீங்கள் தரவுத்தளத்திற்கு (அல்லது தேடல் சேவையகத்திற்கு) வினவல்களை தொடர்ச்சியாக அனுப்பினால், முடுக்கம் எங்கிருந்து வருகிறது? மாறாக, ஒரு மந்தநிலை இருக்கும்.

2.2 அரை தானியங்கி பற்றி

சில இடங்களில், தகவல் தொழில்நுட்பத்தின் அதிநவீனமானது chthonic திகில் தூண்டுகிறது. எடுத்துக்காட்டாக, MySQL அவுட் ஆஃப் தி பாக்ஸில் கண்டிப்பாக சில பதிப்புகளுக்கு ஷார்டிங் செயல்படுத்தப்படவில்லை, இருப்பினும், போரில் பயன்படுத்தப்படும் தரவுத்தளங்களின் அளவுகள் அநாகரீகமான மதிப்புகளுக்கு வளர்கின்றன.

தனிப்பட்ட DBA களின் முகத்தில் மனிதகுலத்தை துன்புறுத்துவது பல ஆண்டுகளாக துன்புறுத்தப்பட்டு, ஒன்றுமில்லாமல் பல மோசமான பகிர்வு தீர்வுகளை எழுதுகிறது. அதன் பிறகு, ப்ராக்ஸிஎஸ்க்யூஎல் (மரியாடிபி/ஸ்பைடர், பிஜி/பிஜி_ஷார்ட்/சிட்டஸ், ...) என்று ஒன்று அதிகமாகவோ அல்லது குறைவாகவோ கண்ணியமான ஷார்டிங் தீர்வு எழுதப்படுகிறது. இந்த மழுப்பலுக்கு இது நன்கு அறியப்பட்ட உதாரணம்.

ஒட்டுமொத்தமாக ProxySQL என்பது, திறந்த மூலத்திற்கான, ரூட்டிங் மற்றும் பலவற்றிற்கான ஒரு முழு அளவிலான நிறுவன-வகுப்பு தீர்வாகும். ஆனால் தீர்க்கப்பட வேண்டிய பணிகளில் ஒன்று, ஒரு தரவுத்தளத்திற்கான பகிர்வு ஆகும், இது மனித வழியில் பிரிக்க முடியாது. "துண்டுகள் = 16" சுவிட்ச் இல்லை என்பதை நீங்கள் காண்கிறீர்கள், நீங்கள் பயன்பாட்டில் உள்ள ஒவ்வொரு கோரிக்கையையும் மீண்டும் எழுத வேண்டும், மேலும் அவற்றில் நிறைய இடங்களில் உள்ளன, அல்லது பயன்பாட்டிற்கும் தரவுத்தளத்திற்கும் இடையில் சில இடைநிலை அடுக்கை வைக்கவும்: "ஹ்ம்ம். ... ஆவணங்களிலிருந்து * தேர்ந்தெடுக்கவா? ஆம், இது 16 சிறிய SELECT * FROM server1.document1, SELECT * from server2.document2 - இப்படிப்பட்ட உள்நுழைவு/கடவுச்சொல்லைக் கொண்ட இந்தச் சேவையகத்திற்கு, மற்றொன்றுக்கு இது உடைக்கப்பட வேண்டும். ஒருவர் பதிலளிக்கவில்லை என்றால், ... ", முதலியன. சரியாக இதை இடைநிலை கறைகளால் செய்ய முடியும். அவை எல்லா தரவுத்தளங்களையும் விட சற்று குறைவாக இருக்கும். PostgreSQL க்கு, நான் புரிந்து கொண்டவரை,

ஒவ்வொரு குறிப்பிட்ட பேட்சையும் உள்ளமைப்பது ஒரு தனி மாபெரும் தலைப்பாகும், அது ஒரு அறிக்கையில் பொருந்தாது, எனவே அடிப்படைக் கருத்துகளை மட்டுமே விவாதிப்போம். Buzz கோட்பாடு பற்றி கொஞ்சம் பேசலாம்.

2.3 முழுமையான சரியான ஆட்டோமேஷன்?

இந்த எழுத்து F() இல் ஷார்டிங் விஷயத்தில் உயர்வை அடைவதற்கான முழு கோட்பாடும் , அடிப்படைக் கொள்கை எப்போதும் தோராயமாக ஒரே மாதிரியாக இருக்கும்: shard_id = F(object).

ஷார்டிங் - இது எதைப் பற்றியது? எங்களிடம் 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 = rand()

சுற்றிலும் சிதறுவது மிகவும் சரியான முறை அல்ல. ஒரு சிக்கல்: எங்களின் 2 பில்லியன் பதிவுகளை ஆயிரம் சர்வர்களில் சீரற்ற முறையில் சிதறடித்தோம், மேலும் அந்த பதிவு எங்கே என்று எங்களுக்குத் தெரியவில்லை. பயனர்_1 ஐ வெளியேற்ற வேண்டும், ஆனால் அது எங்கே என்று எங்களுக்குத் தெரியவில்லை. நாங்கள் ஆயிரம் சேவையகங்களுக்குச் சென்று எல்லாவற்றையும் வரிசைப்படுத்துகிறோம் - எப்படியாவது இது திறமையற்றது.

எஃப் = சம்ஹாஷ்()

பயனர்களை வயது வந்தோருக்கான வழியில் சிதறடிப்போம்: 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. "வெல்லமுடியாத" வலி: திரட்டுதல், சேருதல்

ஒரு அட்டவணையில் இருந்து ஒரு பில்லியன் பதிவுகளை மற்றொரு அட்டவணையில் இருந்து ஒரு பில்லியன் பதிவுகள் என்று தேர்வு செய்வது எப்படி?

• "விரைவாக" கணக்கிடுவது எப்படி... ஆ மற்றும் பிபிபிக்கு இடையில் ராண்ட்கோல் எங்கே?
• "புத்திசாலித்தனமாக" செய்வது எப்படி... user_32shards JOIN posts_1024 shards?

குறுகிய பதில்: வழி இல்லை, கஷ்டப்படுங்கள்!

முதல் டேபிளில் ஆயிரம் சர்வர்களுக்கு ஒரு பில்லியன் ரெக்கார்டுகளை பகிர்ந்தளித்து, அவை வேகமாக வேலை செய்யும் வகையில், இரண்டாவது டேபிளிலும் அதையே செய்திருந்தால், இயற்கையாகவே ஆயிரம் முதல் ஆயிரம் சர்வர்கள் ஜோடியாக ஒருவருக்கொருவர் பேச வேண்டும். ஒரு மில்லியன் இணைப்புகள் சரியாக வேலை செய்யாது. ஷார்டிங்குடன் சரியாகப் பொருந்தாத தரவுத்தளத்திற்கு (தேடல், சேமிப்பு, ஆவணக் கடை அல்லது விநியோகிக்கப்பட்ட கோப்பு முறைமை) கோரிக்கைகளைச் செய்தால், இந்தக் கோரிக்கைகள் பெருமளவில் குறையும்.

ஒரு முக்கியமான விஷயம் என்னவென்றால் , சில கோரிக்கைகள் எப்பொழுதும் தோல்வியடையும் மற்றும் மெதுவாக இருக்கும் . அவற்றின் சதவீதத்தை குறைக்க முயற்சிப்பது முக்கியம். இதன் விளைவாக, ஒரு பில்லியன் மூலம் ஒரு பில்லியன் பதிவுகளுடன் பிரம்மாண்டமான இணைப்புகளைச் செய்ய வேண்டிய அவசியமில்லை. ஒரு பெரிய பகிரப்பட்ட அட்டவணையில் நீங்கள் இணைக்கும் சிறிய அட்டவணையை அனைத்து முனைகளிலும் நகலெடுக்க முடிந்தால், நீங்கள் அதைச் செய்ய வேண்டும். இணைப்புகள் உண்மையில் ஏதோவொரு வகையில் உள்ளூர் என்றால், எடுத்துக்காட்டாக, பயனரையும் அவரது இடுகைகளையும் அருகருகே வைக்க முடியும், அவற்றை ஒரே மாதிரியாகத் துண்டிக்கவும், மேலும் அனைத்து இணைப்புகளையும் ஒரே இயந்திரத்தில் செய்ய முடியும் - நீங்கள் அதைச் செய்ய வேண்டும். .

இது மூன்று நாட்களுக்கு ஒரு தனி விரிவுரை, எனவே கடைசி நரக வலி மற்றும் அதைக் கையாள்வதற்கான வெவ்வேறு வழிமுறைகளுக்குச் செல்வோம்.

2.6 சிக்கலான/நீண்ட வலி: மறுபரிசீலனை

தயாராகுங்கள்: உங்கள் வாழ்க்கையில் முதல் முறையாக உங்கள் தரவைப் பகிர்ந்திருந்தால், சராசரியாக நீங்கள் அதை மேலும் ஐந்து முறை பகிர்வீர்கள்.

நீங்கள் எத்தனை கிளஸ்டர்களை உள்ளமைத்தாலும், நீங்கள் இன்னும் மறுபரிசீலனை செய்ய வேண்டும்.

நீங்கள் மிகவும் புத்திசாலி மற்றும் அதிர்ஷ்டசாலி என்றால், ஒரு முறையாவது ஓவர்ஷார்ட் செய்யுங்கள். ஆனால் நீங்கள் உறுதியாக இருந்தால், பயனருக்கு 10 யூனிட்கள் போதுமானது என்று நீங்கள் நினைக்கும் தருணத்தில், அந்த நேரத்தில் ஒருவர் 30 க்கு ஒரு கோரிக்கையை எழுதுகிறார், மேலும் 100 யூனிட் தெரியாத ஆதாரங்களுக்கான கோரிக்கையை வைக்க திட்டமிட்டுள்ளார். துண்டுகள் ஒருபோதும் போதாது. முதல் பகிர்வுத் திட்டத்தில், எந்தவொரு சந்தர்ப்பத்திலும், நீங்கள் தவறவிடுவீர்கள் - நீங்கள் எப்போதும் சேர்ப்பதற்கான சேவையகங்களின் எண்ணிக்கையை அதிகரிக்க வேண்டும், அல்லது வேறு ஏதாவது செய்ய வேண்டும் - பொதுவாக, எப்படியாவது தரவை மீண்டும் தொகுக்கவும்.

நம்மிடம் இரண்டு நல்ல சக்திகள் இருந்தால் நல்லது: 16 சர்வர் ஷார்ட்கள் இருந்தன, இப்போது அது 32 ஆக உள்ளது. அது 17 ஆக இருந்தால் மிகவும் வேடிக்கையாக இருக்கிறது, அது 23 - இரண்டு வாசிமலி பிரைம் எண்கள். தரவுத்தளங்கள் அதை எவ்வாறு செய்கின்றன, ஒருவேளை அவை உள்ளே ஏதேனும் மந்திரம் இருக்கலாம்?

சரியான பதில்: இல்லை, உள்ளே மந்திரம் இல்லை, அவர்களுக்கு உள்ளே நரகம் உள்ளது.

அடுத்து, "கையால்" என்ன செய்ய முடியும் என்பதைக் கருத்தில் கொள்வோம், ஒருவேளை "ஒரு தானியங்கி இயந்திரமாக" புரிந்துகொள்வோம்.

நெற்றியில் #1. எல்லாவற்றையும் இடமாற்றம் செய்யுங்கள்

எல்லாப் பொருள்களுக்கும், NewF(object), ஒரு புதிய ஷார்டுக்கு மாறுவதைக் கருதுகிறோம்.

NewF()=OldF() பொருத்த வாய்ப்பு குறைவு.

கிட்டத்தட்ட எல்லாவற்றையும் மறைப்போம்.

ஓ

அனைத்து 2 பில்லியன் பதிவுகளையும் பழைய துண்டுகளிலிருந்து புதிய பதிவுகளுக்கு மாற்றுவது போன்ற நரகம் எதுவும் இல்லை என்று நம்புகிறேன். அப்பாவி அணுகுமுறை புரிந்துகொள்ளத்தக்கது: 17 இயந்திரங்கள் இருந்தன, 6 இயந்திரங்கள் கிளஸ்டரில் சேர்க்கப்பட்டன, 2 பில்லியன் பதிவுகள் வரிசைப்படுத்தப்பட்டன, அவை 17 இயந்திரங்களிலிருந்து 23 இயந்திரங்களுக்கு மாற்றப்பட்டன. ஒவ்வொரு 10 வருடங்களுக்கும் ஒருமுறை, நீங்கள் அதைச் செய்யலாம். ஆனால் ஒட்டுமொத்தமாக இது ஒரு மோசமான நடவடிக்கை.

நெற்றியில் #2. பாதி இடமாற்றம்

அடுத்த அப்பாவி முன்னேற்றம் - அத்தகைய முட்டாள்தனமான திட்டத்தை கைவிடுவோம் - 17 கார்களை 23 ஆக மாற்றுவதைத் தடைசெய்வோம், மேலும் நாங்கள் எப்போதும் 16 கார்களை 32 கார்களாக மாற்றுவோம்! பின்னர், கோட்பாட்டின் படி, நாங்கள் தரவின் பாதியை சரியாக மாற்ற வேண்டும், நடைமுறையில் இதையும் செய்யலாம்.

எல்லாப் பொருள்களுக்கும், NewF(object), ஒரு புதிய ஷார்டுக்கு மாறுவதைக் கருதுகிறோம்.

இது கண்டிப்பாக 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 ஹாஷ்களைக் கணக்கிடுகிறோம். அதிக ஹாஷ் மதிப்பு உள்ளவர் வெற்றி பெறுகிறார்.

இது HRW-ஹாஷிங் என்று அழைக்கப்படும், ரெண்டெஸ்வஸ் ஹாஷிங். ஒரு குச்சி போல ஊமை, ஒரு துண்டின் எண்ணிக்கையைக் கணக்கிடுவதற்கான திட்டம், முதலில், வட்டங்களை விட கண்ணுக்கு எளிதானது மற்றும் மறுபுறம் ஒரு சீரான சுமையை அளிக்கிறது.

ஒரே எதிர்மறை என்னவென்றால், ஒரு புதிய துண்டைச் சேர்ப்பது எங்களுக்கு மோசமாகிவிட்டது. புதிய ஷார்ட்டைச் சேர்க்கும்போது, ​​​​எங்களிடம் இன்னும் சில ஹாஷ்கள் மாறும் அபாயம் உள்ளது, மேலும் அவை அனைத்தையும் மதிப்பாய்வு செய்ய வேண்டியிருக்கும். தண்டு அகற்றும் தொழில்நுட்பம் பெரிதாக மாறவில்லை.

மற்றொரு சிக்கல் என்னவென்றால், இது அதிக எண்ணிக்கையிலான துண்டுகளுடன் கணக்கீட்டு ரீதியாக கனமானது.

மேலும் வேடிக்கை #5. மேலும் நுட்பங்கள்

சுவாரஸ்யமாக, ஆராய்ச்சி இன்னும் நிற்கவில்லை மற்றும் கூகிள் ஒவ்வொரு ஆண்டும் சில புதிய விண்வெளி தொழில்நுட்பத்தை வெளியிடுகிறது:

• ஜம்ப் ஹாஷ் - Google '2014.
• மல்டி ப்ரோப்—Google '2015.
• Maglev-Google '2016.

நீங்கள் பாடத்தில் ஆர்வமாக இருந்தால், நீங்கள் பல ஆய்வுக் கட்டுரைகளைப் படிக்கலாம். சிக்கல் தீர்க்கப்படவில்லை என்பதை தெளிவுபடுத்துவதற்காக இந்தத் தரவை முன்வைக்கிறேன், எல்லா தரவுத்தளங்களிலும் செயல்படுத்தக்கூடிய சூப்பர் தீர்வு எதுவும் இல்லை. இப்போது வரை, மக்கள் ஆய்வுக் கட்டுரைகளைப் பாதுகாக்கிறார்கள்.

முடிவுரை

காலியஸ் ஜூலியஸ் சீசர் பெயரிடப்பட்ட ஷார்டிங் என்று அழைக்கப்படும் ஒரு முக்கியமான அடிப்படை நுட்பம் உள்ளது: "பிரிந்து ஆட்சி செய், ஆட்சி செய்து பிரித்து!". தரவு ஒரு சேவையகத்திற்கு பொருந்தவில்லை என்றால், அதை 20 சேவையகங்களாக பிரிக்க வேண்டியது அவசியம்.

இதையெல்லாம் கற்றுக்கொண்டு, துண்டாடாமல் இருப்பதே நல்லது என்ற எண்ணம் வர வேண்டும். ஷார்ட் செய்யாமல் இருப்பது நல்லது என்று நீங்கள் முடிவு செய்தால், இது சரியான உணர்வு. நீங்கள் $100 க்கு சர்வரில் நினைவகத்தை சேர்க்க முடியும் மற்றும் எதையும் துண்டிக்க முடியாது என்றால், நீங்கள் அதை செய்ய வேண்டும். ஷார்டிங் செய்யும் போது, ​​தரவுகளை முன்னும் பின்னுமாக மாற்றும் ஒரு சிக்கலான விநியோக அமைப்பு தோன்றும், எங்கு என்று யாருக்கும் தெரியாத தரவுகளை அடுக்கி வைக்கும். தவிர்க்க முடியுமானால் தவிர்க்கப்பட வேண்டும்.

அதை கையால் செய்யாமல் இருப்பது நல்லது, "அடிப்படை" (தேடல், DFS, ...) தன்னைத் தானே துண்டிக்க முடியும். எப்படியிருந்தாலும், விரைவில் அல்லது பின்னர், ஹைலோட் வரும் மற்றும் எப்படியாவது தரவு பிரிக்கப்பட வேண்டும். அடித்தளம் அதைத் தானே செய்ய முடிந்தாலும், நீங்கள் எந்த பிரச்சனையும் சந்திக்க மாட்டீர்கள் என்பது ஒரு உண்மை அல்ல. அல்காரிதம் அடிப்படைவாதத்தைப் பற்றி நினைவில் கொள்ளுங்கள் - எல்லாம் உள்ளே எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்.

முதல் முறையாக ஷார்டிங்கை அமைக்கும் போது, ​​கவனமாக F() தேர்வு செய்து, கோரிக்கைகள், நெட்வொர்க் போன்றவற்றைப் பற்றி சிந்தியுங்கள். ஆனால் தயாராகுங்கள், ஒருவேளை நீங்கள் 2 முறை தேர்வு செய்ய வேண்டும், குறைந்தபட்சம் ஒரு முறை நீங்கள் எல்லாவற்றையும் மீண்டும் செய்ய வேண்டும்.