ऐसा लगता है कि हम उच्च-भार के विकास के जंगल में इतने गहरे डूबे हुए हैं कि हम बुनियादी समस्याओं के बारे में नहीं सोचते हैं। उदाहरण के लिए, पैनापन। डेटाबेस सेटिंग्स में सशर्त रूप से = n लिखना संभव है तो क्या समझना है और सब कुछ अपने आप ही हो जाएगा। यह कैसे होता है, लेकिन अगर, बल्कि, जब कुछ गलत होता है, तो संसाधन वास्तव में कम होने लगते हैं, मैं समझना चाहता हूं कि इसका कारण क्या है और इसे कैसे ठीक किया जाए।

संक्षेप में, यदि आप कैसंड्रा में अपने वैकल्पिक हैश कार्यान्वयन में योगदान दे रहे थे, तो आपके लिए शायद ही कोई रहस्योद्घाटन हो। लेकिन अगर आपकी सेवाओं पर लोड पहले से ही आ रहा है, और सिस्टम का ज्ञान इसके साथ नहीं है, तो आपका स्वागत है। अपने सामान्य तरीके से महान और भयानक आंद्रेई अकोयोनोव ( शोडान ) बताएगा कि शार्किंग खराब है, शार्किंग भी खराब नहीं है , और यह कैसे अंदर व्यवस्थित होता है। और काफी हद तक दुर्घटना के बारे में, कहानी के कुछ हिस्सों में से एक वास्तव में शार्किंग के बारे में नहीं है, लेकिन शैतान जानता है कि क्या - कैसे वस्तुओं को शार्क के लिए मैप करना है।

मुहरों की फोटो (भले ही वे गलती से पिल्लों के रूप में निकले) पहले से ही इस सवाल का जवाब देने के लिए लगता है कि यह सब क्यों है, लेकिन हम क्रमिक रूप से शुरू करेंगे।

शार्पिंग क्या है?

यदि आप लगातार Google करते हैं, तो यह पता चलता है कि तथाकथित विभाजन और तथाकथित शार्किंग के बीच एक धुंधली सीमा है। हर कोई अपनी इच्छानुसार सब कुछ कहता है। कुछ लोग क्षैतिज विभाजन और तीक्ष्णता के बीच अंतर करते हैं। दूसरों का कहना है कि तीक्ष्णता एक निश्चित प्रकार का क्षैतिज विभाजन है।

मुझे एक भी पारिभाषिक मानक नहीं मिला जो संस्थापक पिता द्वारा अनुमोदित हो और आईएसओ में प्रमाणित हो। एक व्यक्तिगत आंतरिक विश्वास कुछ इस तरह है: औसत रूप से विभाजन "आधार को टुकड़ों में काट रहा है" एक अनियंत्रित तरीके से।

लंबवत विभाजन उदाहरण के लिए, 60 स्तंभों में कुछ बिलियन प्रविष्टियों के साथ एक विशाल तालिका है। ऐसी एक विशाल तालिका रखने के बजाय, हम 2 अरब रिकॉर्ड के साथ 60 कम कोई विशाल तालिका नहीं रखते हैं - और यह एक अंशकालिक आधार नहीं है, लेकिन ऊर्ध्वाधर विभाजन (शब्दावली के उदाहरण के रूप में) है।
क्षैतिज विभाजन - हम लाइन को लाइन से काटते हैं, शायद सर्वर के अंदर।

यहाँ अजीब क्षण क्षैतिज विभाजन और शार्किंग के बीच सूक्ष्म अंतर है। आप मुझे टुकड़ों में काट सकते हैं, लेकिन मैं आपको निश्चितता के साथ नहीं बताऊंगा कि इसमें क्या शामिल है। एक भावना है कि शार्किंग और क्षैतिज विभाजन एक ही चीज के बारे में हैं।

सामान्य रूप से साझाकरण तब होता है जब डेटाबेस या दस्तावेज़ों, वस्तुओं के संग्रह के संदर्भ में एक बड़ी तालिका, यदि आपके पास डेटाबेस नहीं है, लेकिन दस्तावेज़ स्टोर है, तो वस्तुओं के लिए विशेष रूप से काटा जाता है। यही है, 2 बिलियन ऑब्जेक्ट्स से टुकड़ों का चयन किया जाता है, चाहे कोई भी आकार हो। प्रत्येक वस्तु के अंदर स्वयं द्वारा वस्तुओं को टुकड़ों में नहीं काटा जाता है, हम अलग-अलग स्तंभों में विघटित नहीं होते हैं, अर्थात्, हम अलग-अलग जगहों पर बंडल बनाते हैं।

पूर्णता के लिए प्रस्तुति के लिए लिंक ।

सूक्ष्म पारिभाषिक अंतर पहले से ही चले आ रहे हैं। उदाहरण के लिए, अपेक्षाकृत बोलना, पोस्टग्रेज डेवलपर्स कह सकते हैं कि क्षैतिज विभाजन तब होता है जब सभी तालिकाएं जिसमें मुख्य तालिका एक ही योजना में झूठ को विभाजित किया जाता है, और जब विभिन्न मशीनों पर यह तेज होता है।

एक सामान्य अर्थ में, एक विशिष्ट डेटाबेस और एक विशिष्ट डेटा प्रबंधन प्रणाली की शब्दावली से बंधे बिना, एक भावना है कि शार्डिंग सिर्फ लाइन-दर-दस्तावेज़ को स्लाइस कर रहा है - और यही है:

साझाकरण (~ =, \ in ...) क्षैतिज विभाजन == विशिष्ट है।

मैं आमतौर पर जोर देता हूं। इस अर्थ में कि हम केवल 20 बिलियन में 2 बिलियन दस्तावेजों को काटने के लिए नहीं करते हैं, जिनमें से प्रत्येक अधिक प्रबंधनीय होगा, लेकिन इसे कई कोर, कई डिस्क या कई अलग-अलग भौतिक या वर्चुअल सर्वर में वितरित करने के लिए ।

यह समझा जाता है कि हम ऐसा इसलिए कर रहे हैं ताकि हर शार्ट - हर डेटा शतक - को कई बार दोहराया जाए। लेकिन वास्तव में, नहीं।

INSERT INTO docs00 SELECT * FROM documents WHERE (id%16)=0 ... INSERT INTO docs15 SELECT * FROM documents WHERE (id%16)=15

वास्तव में, यदि आप डेटा के ऐसे स्लाइसिंग बनाते हैं, और MySQL पर एक विशाल एसक्यूएल टेबल से, आप अपने बहादुर लैपटॉप पर 16 छोटे टेबल उत्पन्न करेंगे, बिना सिंगल लैपटॉप से परे, एक भी स्कीमा नहीं, एक भी डेटाबेस नहीं, आदि। आदि - सब कुछ, आपके पास पहले से ही शार्क है।

पिल्लों के साथ चित्रण को याद करते हुए, यह निम्नलिखित की ओर जाता है:

बैंडविड्थ बढ़ रही है।
लेटेंसी नहीं बदलती है, यानी प्रत्येक, इसलिए, इस मामले में कार्यकर्ता या उपभोक्ता को बोलने के लिए, अपना खुद का हो जाता है। यह ज्ञात नहीं है कि तस्वीर में पिल्लों को क्या मिलता है, लेकिन अनुरोधों को लगभग उसी समय परोसा जाता है, जैसे कि पिल्ला अकेला था।
या दोनों कि, और एक और, और अभी भी उच्च उपलब्धता (प्रतिकृति)।

बैंडविड्थ क्यों? कभी-कभी हमारे पास ऐसे वॉल्यूम के डेटा हो सकते हैं जो फिट नहीं होते हैं - यह स्पष्ट नहीं है कि कहां, लेकिन वे फिट नहीं हैं - 1 {कोर द्वारा | ड्राइव | सर्वर | ...}। बस पर्याप्त संसाधन नहीं हैं और यह है इस बड़े डेटासेट के साथ काम करने के लिए, आपको इसे काटने की आवश्यकता है।

क्यों विलंबता? एक कोर पर, 2 अरब पंक्तियों की एक तालिका को स्कैन करना 20 गुठली पर 20 तालिकाओं को स्कैन करने की तुलना में 20 गुना धीमा है, यह समानांतर में कर रहा है। डेटा को एक संसाधन पर बहुत धीरे-धीरे संसाधित किया जा रहा है।

उच्च उपलब्धता क्यों? या हम एक ही समय में एक और दूसरे को करने के लिए डेटा में कटौती करते हैं, और एक ही समय में प्रत्येक शार्क की कई प्रतियां - प्रतिकृति उच्च उपलब्धता प्रदान करती हैं।

"अपने हाथों से कैसे करें" इसका एक सरल उदाहरण

32 दस्तावेजों के लिए परीक्षण तालिका test.documents का उपयोग करके सशर्त तीक्ष्णता को काटा जा सकता है, और इस तालिका से लगभग 2 दस्तावेज़ test.docs00, 01, 02, ..., 15 प्रत्येक के लिए 16 परीक्षण तालिकाओं का निर्माण करके।

 INSERT INTO docs00 SELECT * FROM documents WHERE (id%16)=0 ... INSERT INTO docs15 SELECT * FROM documents WHERE (id%16)=15

क्यों के बारे में? क्योंकि एक प्राथमिकता हमें नहीं पता है कि आईडी कैसे वितरित की जाती है, यदि 1 से 32 समावेशी है, तो वास्तव में 2 दस्तावेज होंगे, अन्यथा - नहीं।

हम यह किस लिए कर रहे हैं। 16 तालिकाओं को करने के बाद, हम अपनी आवश्यकता के 16 को "पकड़" सकते हैं। इसके बावजूद कि हमने क्या आराम किया, हम इन संसाधनों को समानांतर कर सकते हैं। उदाहरण के लिए, यदि पर्याप्त डिस्क स्थान नहीं है, तो इन तालिकाओं को अलग-अलग डिस्क में विघटित करने के लिए समझ में आएगा।

यह सब, दुर्भाग्य से, स्वतंत्र नहीं है। मुझे संदेह है कि विहित एसक्यूएल मानक के मामले में (मैंने लंबे समय तक एसक्यूएल मानक को फिर से नहीं पढ़ा है, शायद यह लंबे समय तक अपडेट नहीं किया गया है), किसी भी एसक्यूएल सर्वर के लिए कहने के लिए कोई आधिकारिक मानकीकृत सिंटैक्स नहीं है: प्रिय एसक्यूएल सर्वर, मुझे 32 शार्द बनायें और उन्हें 4 डिस्क पर रखें। " लेकिन व्यक्तिगत कार्यान्वयन में, सिद्धांत रूप में समान करने के लिए अक्सर एक विशिष्ट वाक्यविन्यास होता है। PostgreSQL में विभाजन के लिए तंत्र हैं, MySQL MariaDB के पास है, Oracle ने यह सब बहुत पहले कर दिया है।

फिर भी, अगर हम डेटाबेस समर्थन के बिना और मानक के ढांचे के भीतर हाथ से करते हैं, तो हम सशर्त रूप से डेटा तक पहुंच की जटिलता का भुगतान करते हैं । जहाँ दस्तावेज़ों से एक सरल चयन * था जहाँ आईडी = 123, अब 16 x का चयन करें * डॉक्सएक्सएक्स से। और ठीक है, अगर हमने कुंजी द्वारा रिकॉर्ड प्राप्त करने की कोशिश की। यदि हम रिकॉर्ड की एक प्रारंभिक श्रेणी प्राप्त करने का प्रयास करते हैं, तो अधिक महत्वपूर्ण बात यह है। अब (यदि, मैं जोर देता हूं, जैसे कि मूर्ख हैं, और मानक के भीतर रहते हैं), तो इन 16 चयन * FROM के परिणामों को आवेदन में संयोजित करना होगा।

क्या प्रदर्शन उम्मीद को बदल देता है?

सहज रूप से रैखिक।
सैद्धांतिक रूप से - उदासीन, क्योंकि Amdahl कानून ।
व्यवहार में - शायद लगभग रैखिक रूप से, शायद नहीं।

वास्तव में, सही उत्तर अज्ञात है। शेरिंग तकनीक के चतुर अनुप्रयोग द्वारा, आप अपने आवेदन के संचालन में एक महत्वपूर्ण सुपर-रैखिक गिरावट प्राप्त कर सकते हैं, और यहां तक कि डीबीए भी लाल-गर्म पोकर के साथ चलेंगे।

आइए देखें कि यह कैसे हासिल किया जा सकता है। यह स्पष्ट है कि बस सेटिंग को PostgreSQL shards = 16 पर सेट करना है, और फिर इसे स्वयं ही हटा दिया - यह दिलचस्प नहीं है। आइए इस बारे में सोचें कि हम यह कैसे हासिल कर सकते हैं कि हम शार्किंग से 32 गुना तक धीमा हो जाएंगे , जो इस दृष्टिकोण से दिलचस्प है कि यह कैसे नहीं करना है।

तेजी लाने या धीमा करने के हमारे प्रयास हमेशा क्लासिक्स के खिलाफ आराम करेंगे - अच्छा पुराना अमदहल कानून, जो कहता है कि किसी भी अनुरोध का कोई सटीक समानांतर नहीं है, हमेशा कुछ सुसंगत हिस्सा होता है।

अमदहल कानून

हमेशा एक क्रमबद्ध हिस्सा होता है।

हमेशा अनुरोध के निष्पादन का एक हिस्सा होता है जो समानांतर होता है, और हमेशा एक हिस्सा होता है जो समानांतर नहीं होता है। यहां तक कि अगर यह आपको लगता है कि एक पूरी तरह से समानांतर क्वेरी, कम से कम परिणाम की एक पंक्ति को इकट्ठा करना जो आप ग्राहक को भेजने जा रहे हैं, प्रत्येक शार्क से प्राप्त पंक्तियों से, हमेशा होता है, और यह हमेशा सुसंगत होता है।

हमेशा किसी न किसी तरह का अनुक्रमिक हिस्सा होता है। यह सामान्य पृष्ठभूमि के खिलाफ छोटा, बिल्कुल अदृश्य हो सकता है, यह विशाल हो सकता है और तदनुसार, समानांतर रूप से समानांतर रूप से प्रभावित करता है, लेकिन यह हमेशा होता है।

इसके अलावा, इसका प्रभाव बदल रहा है और महत्वपूर्ण रूप से बढ़ सकता है, उदाहरण के लिए, यदि हम अपनी तालिका में कटौती करते हैं - चलो दरें बढ़ाते हैं - 64 रिकॉर्ड से 4 अभिलेखों के 16 टेबल तक, यह हिस्सा बदल जाएगा। बेशक, इतनी बड़ी मात्रा में डेटा को देखते हुए, हम एक मोबाइल फोन और 86 मेगाहर्ट्ज प्रोसेसर पर काम करते हैं, हमारे पास पर्याप्त फाइलें नहीं हैं जिन्हें एक ही समय में खुला रखा जा सके। जाहिर है, इस तरह के इनपुट के साथ, हम एक बार में एक फ़ाइल खोलते हैं।

यह कुल = सीरियल + समानांतर था । जहां, उदाहरण के लिए, समानांतर डीबी के अंदर सभी काम हैं, और सीरियल क्लाइंट को परिणाम भेज रहा है।
यह Total2 = Serial + Parallel / N + Xserial बन गया । उदाहरण के लिए, जब सामान्य आदेश BY, Xserial> 0।

इस सरल उदाहरण के साथ, मैं यह दिखाने की कोशिश करता हूं कि कुछ Xserial प्रकट होता है। इस तथ्य के अलावा कि हमेशा एक अनुक्रमित हिस्सा होता है, और यह तथ्य कि हम समानांतर में डेटा के साथ काम करने की कोशिश कर रहे हैं, एक अतिरिक्त हिस्सा इस डेटा स्लाइसिंग को सुनिश्चित करने के लिए प्रकट होता है। मोटे तौर पर, हमें आवश्यकता हो सकती है:

आंतरिक डेटाबेस शब्दकोश में इन 16 तालिकाओं को खोजें;
खुली फाइलें;
स्मृति आवंटित करें;
याददाश्त खाली करना;
परिणाम दाग;
कोर के बीच सिंक्रनाइज़ करें;

किसी भी सिंक प्रभाव हमेशा दिखाई देते हैं। वे नगण्य हो सकते हैं और कुल समय के एक अरबवें हिस्से पर कब्जा कर सकते हैं, लेकिन वे हमेशा गैरजरूरी होते हैं और हमेशा मौजूद रहते हैं। उनकी मदद से, हम शार्पिंग के बाद नाटकीय रूप से उत्पादकता खो सकते हैं।

यह Amdahl के कानून के बारे में एक मानक तस्वीर है। यह बहुत पठनीय नहीं है, लेकिन यह महत्वपूर्ण है कि लाइनें, जो आदर्श रूप से सीधी होनी चाहिए और रैखिक रूप से बढ़नी चाहिए, asymptote को समाप्त करें। लेकिन चूंकि इंटरनेट से ग्राफ अपठनीय है, मैंने अपनी राय में, संख्याओं के साथ अधिक दृश्य तालिकाओं को बनाया है।

मान लें कि हमारे पास अनुरोध प्रसंस्करण का कुछ क्रमबद्ध हिस्सा है, जिसमें केवल 5% लगता है: धारावाहिक = 0.05 = 1/20।

सहज रूप से, ऐसा लगता है कि क्रमबद्ध भाग के साथ, जो अनुरोध प्रसंस्करण का केवल 1/20 लेता है, यदि हम अनुरोध के प्रसंस्करण को 20 कोर तक समानांतर करते हैं, तो यह लगभग 20 हो जाएगा, सबसे खराब स्थिति में, 18 गुना तेज।

वास्तव में, गणित एक दिल की बात है :

wall = 0.05 + 0.95/num_cores, speedup = 1 / (0.05 + 0.95/num_cores)

यह पता चला है कि यदि आप सावधानीपूर्वक गणना करते हैं, तो 5% के क्रमबद्ध भाग के साथ त्वरण 10 गुना (10.3) होगा, और सैद्धांतिक आदर्श की तुलना में यह 51% है।

8 कोर	= 5.9	= =४%
10 कोर	= 6.9	= 69%
20 कोर	= 10.3	= ५१%
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	= ६१%

पूरी तरह से थर्मोन्यूक्लियर क्वेरी के लिए, जो स्वाभाविक रूप से घंटों तक चलती है, और प्रारंभिक कार्य और परिणाम को इकट्ठा करने में बहुत कम समय लगता है (धारावाहिक = 0.001), हम पहले से ही अच्छी दक्षता देखेंगे:

8 कोर	= 7.94	= ९९%
16 कोर	= 15.76	= ९९%
32 कोर	= 31.04	= 97%
64 कोर	= 60.20	= 94%

कृपया ध्यान दें कि हम कभी भी 100% नहीं देखेंगे । विशेष रूप से अच्छे मामलों में, आप देख सकते हैं, उदाहरण के लिए, 99.999%, लेकिन बिल्कुल 100% नहीं।

एन बार में फेरबदल और ब्रेक कैसे करें?

आप बिल्कुल N समय में फेरबदल और तोड़ सकते हैं:

Docs00 भेजें ... docs15 क्रमिक रूप से अनुरोध करता है , समानांतर रूप से नहीं।
सरल प्रश्नों में, कुंजी से चयन न करें, जहां कुछ = 234।

इस मामले में, अनुक्रमित भाग (धारावाहिक) 1% नहीं और 5% नहीं, बल्कि आधुनिक डेटाबेस में लगभग 20% है। यदि आप डेटाबेस को बेतहाशा कुशल बाइनरी प्रोटोकॉल का उपयोग करते हुए या इसे पायथन लिपि के लिए एक गतिशील पुस्तकालय के रूप में लिंक करते हैं, तो आप धारावाहिक भाग का 50% पा सकते हैं।

एक साधारण अनुरोध के लिए प्रसंस्करण समय के बाकी हिस्से को अनुरोध को पार्स करने, योजना तैयार करने आदि के गैर-समानांतर संचालन द्वारा कब्जा कर लिया जाएगा। यही है, यह रिकॉर्ड को नहीं पढ़ने के लिए धीमा कर देता है।

यदि हम डेटा को 16 तालिकाओं में तोड़ते हैं और इसे क्रमिक रूप से चलाते हैं, जैसा कि PHP प्रोग्रामिंग भाषा में प्रथागत है, उदाहरण के लिए, (यह अतुल्यकालिक प्रक्रियाओं को बहुत अच्छी तरह से चलाने का तरीका नहीं जानता है), तो हमें 16 बार मंदी आती है। और, शायद, और भी अधिक, क्योंकि नेटवर्क राउंड-ट्रिप को भी जोड़ा जाएगा।

अचानक जब पैनापन, एक प्रोग्रामिंग भाषा का विकल्प महत्वपूर्ण है।

हम एक प्रोग्रामिंग भाषा की पसंद के बारे में याद करते हैं, क्योंकि यदि आप क्रमिक रूप से डेटाबेस (या खोज सर्वर) को प्रश्न भेजते हैं, तो त्वरण कहाँ से आता है? बल्कि, एक मंदी दिखाई देगी।

जीवन से बाइक

यदि आप C ++ चुनते हैं, तो POSIX थ्रेड्स को लिखें , न कि बूस्ट I / O। मैंने खुद ओरेकल और MySQL के अनुभवी डेवलपर्स से एक उत्कृष्ट पुस्तकालय देखा, जिन्होंने बूस्ट पर MySQL सर्वर के साथ संचार लिखा था। जाहिरा तौर पर, उन्हें काम पर शुद्ध सी में लिखने के लिए मजबूर किया गया था, लेकिन फिर वे चारों ओर मोड़ने में कामयाब रहे, बूस्ट को अतुल्यकालिक I / O, आदि के साथ ले गए। एक समस्या - यह अतुल्यकालिक I / O, जो सैद्धांतिक रूप से समानांतर में 10 अनुरोधों को संचालित करना चाहिए, किसी कारण से एक अदृश्य तुल्यकालन बिंदु के अंदर था। समानांतर में 10 अनुरोध शुरू करने पर, उन्हें एक से 20 गुना धीमी गति से निष्पादित किया गया, क्योंकि 10 बार अनुरोध खुद को और एक बार सिंक्रनाइज़ेशन बिंदु पर।

निष्कर्ष: ऐसी भाषाओं में लिखें जो समानांतर चलने और विभिन्न अनुरोधों को अच्छी तरह से लागू करने के लिए प्रतीक्षा करती हैं। मुझे नहीं पता, ईमानदार होने के लिए, गो के अलावा सलाह देने के लिए वास्तव में क्या है। केवल इसलिए नहीं कि मैं वास्तव में गो से प्यार करता हूं, बल्कि इसलिए कि मैं कुछ भी अधिक उपयुक्त नहीं जानता।

अनुपयुक्त भाषाओं में न लिखें, जिसमें आप डेटाबेस में 20 समानांतर प्रश्नों को चलाने में सक्षम नहीं हैं। या हर अवसर पर, यह सब अपने हाथों से न करें - समझें कि यह कैसे काम करता है, लेकिन इसे मैन्युअल रूप से न करें।

ए / बी टेस्ट बाइक

कभी-कभी आप धीमा कर सकते हैं क्योंकि आपको इस तथ्य के लिए उपयोग किया जाता है कि सब कुछ काम करता है, और आपने ध्यान नहीं दिया कि क्रमबद्ध भाग, सबसे पहले, दूसरे, एक बड़ा है।

तुरंत ~ 60 खोज सूचकांक शार्क, श्रेणियां
ये एक विषय क्षेत्र के तहत सही और सही शार्ड हैं।
1000 तक दस्तावेज थे, और 50,000 दस्तावेज थे।

यह एक उत्पादन बाइक है, जब खोज क्वेरी को थोड़ा बदल दिया गया था और उन्होंने 60 से अधिक दस्तावेज़ों का चयन करना शुरू कर दिया था। सब कुछ जल्दी और सिद्धांत पर काम किया: "यह काम करता है - इसे स्पर्श न करें", वे सभी इसे भूल गए, जो वास्तव में 60 शार्क के अंदर है। हमने प्रत्येक शार्क के लिए नमूने की सीमा एक हजार से बढ़ाकर 50 हजार कर दी है। अचानक, यह धीमा होना शुरू हुआ और समानांतरवाद बंद हो गया। स्वयं अनुरोध, जिसे शार्क के अनुसार निष्पादित किया गया था, ने काफी अच्छी तरह से उड़ान भरी, और मंच को धीमा कर दिया गया, जब 60 शार्क से 50 हजार दस्तावेज एकत्र किए गए थे। एक कोर पर इन 3 मिलियन अंतिम दस्तावेजों को एक साथ विलय कर दिया गया, 3 मिलियन के शीर्ष को ग्राहक को दिया गया। वही धारावाहिक का हिस्सा धीमा हो गया, वही अमलदाल का क्रूर नियम काम कर गया।

इसलिए हो सकता है कि आप अपने हाथों से नहीं बल्कि सिर्फ इंसानियत के साथ पैनापन करें
डेटाबेस को बताएं: "यह करो!"

डिस्क्लेमर: मुझे वास्तव में नहीं पता कि मैं कुछ सही कैसे कर सकता हूं। मैं गलत मंज़िल से हूँ !!!

मैं अपने पूरे सचेत जीवन के दौरान "एल्गोरिथम कट्टरवाद" नामक धर्म का प्रचार कर रहा हूं। यह संक्षेप में बहुत ही सरल रूप में तैयार किया गया है:

आप वास्तव में अपने हाथों से कुछ भी नहीं करना चाहते हैं, लेकिन यह जानना बेहद उपयोगी है कि यह अंदर कैसे व्यवस्थित है। ताकि उस समय जब डेटाबेस में कुछ गलत हो जाए, तो आप कम से कम यह समझें कि वहां क्या गलत हुआ, कैसे इसे अंदर व्यवस्थित किया जाता है और मोटे तौर पर इसे कैसे ठीक किया जा सकता है।

आइए विकल्प देखें:

"हाथ । " इससे पहले, हमने डेटा को 16 वर्चुअल टेबल में मैन्युअल रूप से खंडित किया, और हमारे हाथों से सभी प्रश्नों को फिर से लिखा - यह करने के लिए बेहद असुविधाजनक है। यदि हाथों को फेरने का अवसर नहीं है - तो हाथ न फेरें! लेकिन कभी-कभी यह संभव नहीं होता है, उदाहरण के लिए, आपके पास MySQL 3.23 है, और फिर आपको करना होगा।
"स्वचालित"। ऐसा होता है कि आप स्वचालित रूप से या लगभग स्वचालित रूप से फेरबदल कर सकते हैं, जब डेटाबेस स्वयं डेटा वितरित कर सकता है, तो आपको बस किसी विशिष्ट सेटिंग को मोटे तौर पर लिखने की आवश्यकता है। बहुत सारे आधार हैं, और उनकी बहुत सारी सेटिंग्स हैं। मुझे यकीन है कि प्रत्येक डेटाबेस में जिसमें शार्क = 16 (जो भी वाक्यविन्यास है) लिखना संभव है, इंजन द्वारा इस मामले में बहुत सारी अन्य सेटिंग्स को चिपकाया जाता है।
"अर्ध-स्वचालित" - एक पूरी तरह से लौकिक, मेरी राय में, और क्रूर मोड। यही है, आधार खुद को सक्षम नहीं लगता है, लेकिन बाहरी अतिरिक्त पैच हैं।

मशीन के बारे में कुछ बताना मुश्किल है, सिवाय इसके कि उसे संबंधित डेटाबेस (MongoDB, Elastic, Cassandra, ... सामान्य तौर पर, तथाकथित NoSQL) पर प्रलेखन के लिए भेजा जाए। यदि आप भाग्यशाली हैं, तो आप केवल "मुझे 16 शार्प करें" स्विच खींच देंगे और सब कुछ काम करेगा। उस समय, जब यह काम नहीं करता है, तो शेष लेख आवश्यक हो सकता है।

सेमीआटोमैटिक डिवाइस के बारे में

कुछ स्थानों पर, परिष्कृत सूचना प्रौद्योगिकियां चोथे आतंक को प्रेरित करती हैं। उदाहरण के लिए, बॉक्स से बाहर MySQL के पास निश्चित संस्करणों के लिए तेज करने का कोई कार्यान्वयन नहीं था, फिर भी, लड़ाई में संचालित ठिकानों का आकार अश्लील मूल्यों तक बढ़ता है।

व्यक्तिगत DBA के चेहरे पर पीड़ित मानवता वर्षों से सताया जा रहा है और बिना किसी कारण के लिए बनाए गए कई खराब शेरिंग समाधान लिखती है। उसके बाद, एक या अधिक कम शार्पिंग सॉल्यूशन को ProxySQL (MariaDB / Spider, PG / pg_shard / Citus, ...) लिखा जाता है। यह इसी मंत्र का एक जाना-माना उदाहरण है।

ProxySQL पूरे के रूप में, निश्चित रूप से, खुले स्रोत के लिए एक पूर्ण उद्यम-वर्ग समाधान है, रूटिंग और अधिक के लिए। लेकिन हल किए जाने वाले कार्यों में से एक डेटाबेस के लिए पैनापन है, जो अपने आप में नहीं जानता कि मानवीय रूप से कैसे शार्प किया जाए। आप देखते हैं, कोई "शार्क = 16" स्विच नहीं है, या तो आपको आवेदन में प्रत्येक अनुरोध को फिर से लिखना होगा, और उनमें से बहुत सारे हैं, या एप्लिकेशन और डेटाबेस के बीच एक मध्यवर्ती परत डालते हैं जो दिखता है: "हम्म ... चयन करें" दस्तावेज़ों से? हां, इसे 16 छोटे SELECT * FROM server1.document1, SELECT * FROM server2.document2 - में इस यूजरनेम / पासवर्ड के साथ इस सर्वर पर दूसरे के साथ फाड़ा जाना चाहिए। अगर किसी ने जवाब नहीं दिया, तो… ”आदि।

वास्तव में यह मध्यवर्ती पैच द्वारा किया जा सकता है। वे सभी डेटाबेस से थोड़ा कम हैं। PostgreSQL के लिए, जैसा कि मैं इसे समझता हूं, उसी समय कुछ अंतर्निहित समाधान हैं (PostgresForeign Data Wrappers, मेरी राय में, PostgreSQL में ही बनाया गया है), बाहरी पैच हैं।

प्रत्येक विशिष्ट पैच को कॉन्फ़िगर करना एक अलग विशाल विषय है जो एक रिपोर्ट में फिट नहीं होगा, इसलिए हम केवल मूल अवधारणाओं पर चर्चा करेंगे।

आइए, बज़ थ्योरी के बारे में थोड़ी बात करें।

बिल्कुल सही स्वचालन?

इस पत्र F () में shard_id = F(object). के मामले में चर्चा का पूरा सिद्धांत, मूल सिद्धांत हमेशा एक ही क्रूड है: shard_id = F(object).

आम तौर पर साझा करना किस बारे में है? हमारे पास 2 बिलियन रिकॉर्ड्स (या 64) हैं। हम उन्हें कई टुकड़ों में विभाजित करना चाहते हैं। एक अप्रत्याशित सवाल उठता है - कैसे? किस सिद्धांत से मुझे अपने 2 बिलियन रिकॉर्ड (या 64) 16 सर्वर में उपलब्ध होने चाहिए?

हम में अव्यक्त गणितज्ञ आपको यह बताना चाहिए कि अंत में हमेशा एक निश्चित जादू का कार्य होता है, जो प्रत्येक दस्तावेज़ (ऑब्जेक्ट, लाइन, आदि) के लिए निर्धारित करेगा कि इसे किस टुकड़े में रखा जाए।

यदि हम गणित में गहराई से जाते हैं, तो यह फ़ंक्शन हमेशा न केवल ऑब्जेक्ट (लाइन ही) पर निर्भर करता है, बल्कि बाहरी सेटिंग्स जैसे कि कुल संख्या पर भी होता है। फ़ंक्शन, जिसे प्रत्येक ऑब्जेक्ट के लिए कहना चाहिए कि इसे कहां रखा जाए, सिस्टम पर सर्वर से अधिक मूल्य वापस नहीं कर सकते। और कार्य कुछ अलग हैं:

shard_func = F1 (वस्तु);
shard_id = F2 (shard_func, ...);
shard_id = F2 ( F1 (ऑब्जेक्ट), current_num_shards, ...)।

लेकिन आगे हम व्यक्तिगत कार्यों के इन जंगलों में खुदाई नहीं करेंगे, हम सिर्फ इस बारे में बात करते हैं कि जादू के कार्य F () क्या हैं।

F () क्या हैं?

वे कई अलग-अलग और कई अलग-अलग कार्यान्वयन तंत्र के साथ आ सकते हैं। नमूना सारांश:

F = रैंड ()% 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 | ...]

एक दिलचस्प तथ्य - आप स्वाभाविक रूप से सभी डेटा को यादृच्छिक रूप से बिखेर सकते हैं - हम एक मनमाना सर्वर पर, एक मनमाना कर्नेल पर, एक मनमाना तालिका में अगला रिकॉर्ड फेंकते हैं। इसमें बहुत खुशी नहीं होगी, लेकिन यह काम करेगा।

प्रतिलिपि प्रस्तुत करने योग्य या यहां तक कि सुसंगत हैश कार्यों के लिए स्कैमिंग के कुछ और बुद्धिमान तरीके हैं, या कुछ विशेषता के लिए स्कैमिंग। आइए प्रत्येक विधि से गुजरें।

एफ = रैंड ()

चारों ओर बिखराव एक बहुत सही तरीका नहीं है। एक समस्या: हमने अपने 2 बिलियन रिकॉर्ड प्रति हजार सर्वर पर यादृच्छिक रूप से बिखरे हुए हैं, और हमें पता नहीं है कि रिकॉर्ड कहां है। हमें user_1 को खींचने की आवश्यकता है, लेकिन हम नहीं जानते कि यह कहां है। हम एक हजार सर्वरों पर जाते हैं और हर चीज के माध्यम से छांटते हैं - किसी तरह यह अक्षम है।

F = somehash ()

आइए उपयोगकर्ताओं को एक वयस्क तरीके से तितर बितर करें: user_id से पुन: प्रस्तुत हैश फ़ंक्शन को पढ़ें, विभाजन की शेष संख्या को सर्वर की संख्या से लें और वांछित सर्वर तक तुरंत पहुंचें।

हम ऐसा क्यों कर रहे हैं? और फिर, कि हमारे पास उच्च भार है और हमें एक सर्वर में कुछ भी नहीं मिलता है। यदि अंतर्मन, जीवन इतना सरल होता।

खैर, स्थिति पहले से बेहतर हो गई है, एक रिकॉर्ड पाने के लिए, हम एक प्रसिद्ध सर्वर पर जाते हैं। लेकिन अगर हमारे पास चाबियों की एक सीमा है, तो इस सभी श्रेणी में हमें सभी प्रमुख मूल्यों के माध्यम से क्रमबद्ध करने की आवश्यकता है और सीमा में या तो कई शार्क के रूप में जाते हैं, क्योंकि हमारे पास सीमा में या सामान्य रूप से प्रत्येक सर्वर में चाबियाँ हैं। बेशक, स्थिति में सुधार हुआ है, लेकिन सभी अनुरोधों के लिए नहीं। कुछ अनुरोध प्रभावित हुए हैं।

प्राकृतिक पैनापन (F = object.date% num_shards)

कभी-कभी, अक्सर, ट्रैफ़िक का 95% और लोड का 95% ऐसे अनुरोध होते हैं, जिनमें किसी न किसी तरह की प्राकृतिक पैठ होती है। , 95% - 1 , 3 , 7 , 5% . 95% , , , .

, , , - .

— , . , , , , . 5 % .

, :

, 95% .
95% , , . , . , .

, — , - .

, , , , . « - ».

«». , .

1. :

, , .

, !
() .

, / , , , PM ( , PM ), . .

, . , , 100 . .

, , , , - .

2. «» : , join

, ?

«» … WHERE randcol BETWEEN aaa AND bbb?
«» … users_32shards JOIN posts_1024 shards?

: , !

, , , . . (, , document store ), , .

— - . . , . , , , . - , , , , — .

, .

3. / :

: , .

, .

, , , . , , , 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. Consistent hashing

, consistent hashing

«consistent hashing», , .

: () , . , , , ( , ), .

: , 2 «», 1/n.
: , . .

, . , , , : , .

. , . , .., . , - , , .

, , , Cassandra . , , , , , .

, — / , , .

, : ? ? — , !

#4. Rendezvous/HRW

( , ): shard_id = arg max hash(object_id, shard_id).

Rendezvous hashing, , , Highest Random Weight. :

, , 16 . (), - , 16 , . -, .

HRW-hashing, Rendezvous hashing. , -, , .

, . , - - . .

, .

#5.

, Google - :

Jump Hash — Google '2014.
Multi Probe —Google '2015.
Maglev — Google '2016.

, . , , , -, . .

#6.

— . ? , 2 , object_id 2 , .

, ? ?

. , - , , . , , , , .

:

1 .
/ / / : min/max_id => shard_id.
8 4 (4 !) — 20 .
- , 20 — .
20 — .

2 - 16 — 100 - . : , , — 1 . , , .

, , , - , .

निष्कर्ष

: « , !». , 20 .

, , . , — . 100$ , . -, . — .

, , «» (, DFS, ...) . , , highload - . , , - . — , .

F() , , , .. , , 2 .

, , . HighLoad++ , , —Sphinx—highload , .

Highload User Group. , .

, , HighLoad++ . , , . , , . highload-, .

, , , . , , , .

24 - «», « ». , . , .

, , 8 9 - HighLoad++ early bird .

शेयरिंग सिद्धांत