2.1 N वेळा कमी आणि कमी कसे करावे?

तुम्ही याप्रमाणे N वेळा कमी आणि धीमा करू शकता:

  • docs00...docs15 विनंत्या क्रमाने पाठवा , समांतर नाही.
  • सोप्या प्रश्नांमध्ये, की द्वारे नाही निवड करा , WHERE something=234.

या प्रकरणात, अनुक्रमित भाग (सीरियल) आधुनिक डेटाबेसमध्ये 1% आणि 5% नाही तर सुमारे 20% घेते. आपण अत्यंत कार्यक्षम बायनरी प्रोटोकॉल वापरून डेटाबेसमध्ये प्रवेश केल्यास किंवा डायनॅमिक लायब्ररी म्हणून पायथन स्क्रिप्टमध्ये जोडल्यास आपल्याला अनुक्रमित भागाचा 50% भाग देखील मिळू शकतो.

एका साध्या विनंतीच्या प्रक्रियेचा उर्वरित वेळ विनंतीचे विश्लेषण करणे, योजना तयार करणे इत्यादींच्या समांतर न करता येणार्‍या ऑपरेशन्सद्वारे व्यापला जाईल. म्हणजेच रेकॉर्ड न वाचल्याने गती कमी होते.

जर आम्ही डेटाचे 16 टेबल्समध्ये विभाजन केले आणि अनुक्रमे चालवले, जसे की PHP प्रोग्रामिंग भाषेमध्ये प्रथा आहे, उदाहरणार्थ, (असिंक्रोनस प्रक्रिया सुरू करणे फार चांगले नाही), तर आम्हाला 16-पट मंदी मिळेल. आणि, कदाचित, आणखी, कारण नेटवर्क राउंड-ट्रिप्स देखील जोडल्या जातील.

अचानक, शार्डिंग करताना प्रोग्रामिंग भाषेची निवड महत्वाची आहे.

प्रोग्रामिंग भाषेच्या निवडीबद्दल लक्षात ठेवा, कारण जर तुम्ही डेटाबेस (किंवा शोध सर्व्हर) वर अनुक्रमे प्रश्न पाठवले तर प्रवेग कोठून येईल? उलट मंदी असेल.

2.2 अर्ध-स्वयंचलित बद्दल

काही ठिकाणी, माहिती तंत्रज्ञानाची अत्याधुनिकता chthonic भयपटाला प्रेरणा देते. उदाहरणार्थ, MySQL आउट ऑफ द बॉक्समध्ये निश्चितपणे काही आवृत्त्यांमध्ये शार्डिंगची अंमलबजावणी नव्हती, तथापि, युद्धात वापरल्या जाणार्‍या डेटाबेसचे आकार अशोभनीय मूल्यांपर्यंत वाढतात.

वैयक्तिक DBAs च्या चेहऱ्यावर दुःखी मानवतेला वर्षानुवर्षे त्रास दिला जात आहे आणि काहीही नसलेल्या अनेक वाईट शार्डिंग सोल्यूशन्स लिहितात. त्यानंतर, 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(ऑब्जेक्ट).

Sharding - हे सर्व कशाबद्दल आहे? आमच्याकडे 2 अब्ज रेकॉर्ड आहेत (किंवा 64). आम्हाला त्यांचे अनेक तुकडे करायचे आहेत. एक अनपेक्षित प्रश्न उद्भवतो - कसे? माझ्यासाठी उपलब्ध असलेल्या 16 सर्व्हरवर मी माझे 2 अब्ज रेकॉर्ड (किंवा 64) कोणत्या तत्त्वानुसार विखुरले पाहिजे?

आपल्यातील सुप्त गणितज्ञांनी असे सुचवले पाहिजे की शेवटी असे काही जादूचे कार्य असते जे प्रत्येक दस्तऐवजासाठी (वस्तू, रेषा इ.) कोणत्या तुकड्यामध्ये ठेवायचे हे ठरवते.

गणितामध्ये खोलवर जाऊन, हे कार्य नेहमी केवळ ऑब्जेक्टवर (स्वतःच्या पंक्तीवर) अवलंबून नाही, तर एकूण शार्ड्सच्या संख्येसारख्या बाह्य सेटिंग्जवर देखील अवलंबून असते. एक फंक्शन जे प्रत्येक ऑब्जेक्टसाठी ते कुठे ठेवायचे हे सांगणे आवश्यक आहे, सिस्टममध्ये सर्व्हरपेक्षा जास्त मूल्य देऊ शकत नाही. आणि कार्ये थोडी वेगळी आहेत:

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

परंतु पुढे आपण वैयक्तिक फंक्शन्सच्या या जंगलात खोदणार नाही, आपण फक्त F () काय जादूची कार्ये आहेत याबद्दल बोलू.

2.4 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 |… ]

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

पुनरुत्पादक किंवा अगदी सातत्यपूर्ण हॅश फंक्शनद्वारे शार्ड करण्यासाठी किंवा काही गुणधर्मांद्वारे शार्ड करण्याच्या काही अधिक बुद्धिमान पद्धती आहेत. चला प्रत्येक पद्धतीचा विचार करूया.

F = रँड()

आजूबाजूला विखुरणे ही फारशी योग्य पद्धत नाही. एक समस्या: आम्ही आमचे 2 अब्ज रेकॉर्ड एक हजार सर्व्हरवर यादृच्छिकपणे विखुरले आणि रेकॉर्ड कुठे आहे हे आम्हाला माहित नाही. आम्हाला user_1 बाहेर काढण्याची गरज आहे, पण ते कुठे आहे हे आम्हाला माहीत नाही. आम्ही एक हजार सर्व्हरवर जातो आणि सर्वकाही क्रमवारी लावतो - हे कसे तरी अकार्यक्षम आहे.

F = somehash()

चला वापरकर्त्यांना प्रौढ पद्धतीने विखुरू: user_id वरून पुनरुत्पादित हॅश फंक्शनची गणना करा, सर्व्हरच्या संख्येनुसार उर्वरित भाग घ्या आणि इच्छित सर्व्हरशी त्वरित संपर्क साधा.

आपण हे का करत आहोत? आणि मग, आमच्याकडे हायलोड आहे आणि इतर काहीही एका सर्व्हरमध्ये बसत नाही. जर ते जुळले तर जीवन इतके सोपे होईल.

छान, परिस्थिती आधीच सुधारली आहे, एक रेकॉर्ड मिळविण्यासाठी, आम्ही आगाऊ ज्ञात सर्व्हरवर जातो. परंतु जर आपल्याकडे कळांची श्रेणी असेल, तर या संपूर्ण श्रेणीमध्ये आपल्याला कीजच्या सर्व मूल्यांमधून जाणे आवश्यक आहे आणि मर्यादेत, एकतर आपल्या श्रेणीतील कीज आहेत तितक्या शार्ड्सपर्यंत जाणे आवश्यक आहे किंवा अगदी प्रत्येक सर्व्हर. परिस्थिती नक्कीच सुधारली आहे, परंतु सर्व विनंत्यांसाठी नाही. काही प्रश्नांवर परिणाम झाला आहे.

नैसर्गिक शार्डिंग (F = object.date % num_shards)

काहीवेळा, म्हणजे बर्‍याचदा, 95% रहदारी आणि 95% भार या विनंत्या असतात ज्यात काही प्रकारचे नैसर्गिक शार्डिंग असते. उदाहरणार्थ, 95% सशर्त सामाजिक-विश्लेषणात्मक क्वेरी केवळ शेवटच्या 1 दिवस, 3 दिवस, 7 दिवसांच्या डेटावर परिणाम करतात आणि उर्वरित 5% मागील काही वर्षांचा संदर्भ देतात. परंतु 95% विनंत्या अशा प्रकारे नैसर्गिकरित्या तारखेनुसार कमी केल्या जातात, सिस्टम वापरकर्त्यांचे स्वारस्य गेल्या काही दिवसांवर केंद्रित आहे.

या प्रकरणात, आपण डेटा तारखेनुसार विभाजित करू शकता, उदाहरणार्थ, एका दिवसाद्वारे, आणि काही दिवसासाठी किंवा या दिवसापासून या शार्डपर्यंत एखाद्या वस्तूच्या अहवालाच्या विनंतीस प्रतिसादाचे अनुसरण करू शकता.

जीवन सुधारत आहे - आम्हाला आता केवळ एखाद्या विशिष्ट वस्तूचे स्थान माहित नाही तर श्रेणीबद्दल देखील माहिती आहे. जर आम्हाला तारखांच्या श्रेणीसाठी नाही तर इतर स्तंभांच्या श्रेणीसाठी विचारले गेले तर, नक्कीच, आम्हाला सर्व शार्ड्समधून जावे लागेल. परंतु खेळाच्या नियमांनुसार, आमच्याकडे अशा विनंत्यांपैकी फक्त 5% आहेत.

असे दिसते की आम्ही प्रत्येक गोष्टीसाठी एक आदर्श उपाय शोधून काढला आहे, परंतु दोन समस्या आहेत:

  • हे समाधान एका विशिष्ट प्रकरणासाठी तयार केले जाते, जेव्हा 95% विनंत्या फक्त गेल्या आठवड्यात असतात.
  • 95% विनंत्या शेवटच्या आठवड्यात स्पर्श करत असल्याने, त्या सर्व या शेवटच्या आठवड्यात सेवा देणार्‍या एका शार्डवर पडतील. हा शार्ड वितळेल, तर इतर सर्व या वेळी निष्क्रिय असतील. त्याच वेळी, आपण त्यांना फेकून देऊ शकत नाही; संग्रहित डेटा देखील संग्रहित करणे आवश्यक आहे.

ही एक वाईट शार्डिंग योजना आहे असे म्हणायचे नाही - आम्ही गरम डेटा कापला, तरीही, सर्वात गरम शार्डसह काहीतरी करणे आवश्यक आहे.

अँटिक्स, जंप आणि पोल्टिसेसद्वारे समस्येचे निराकरण केले जाते, म्हणजे, बर्निंग वर्तमान दिवसाच्या प्रतिकृतींच्या संख्येत वाढ, त्यानंतर हा दिवस भूतकाळ बनतो आणि संग्रहात जातो तेव्हा प्रतिकृतींच्या संख्येत हळूहळू घट. "तुम्हाला फक्त चुकीच्या पद्धतीने मॅजिक हॅश फंक्शनसह क्लस्टरवर डेटा पसरवायचा आहे" नावाचा कोणताही आदर्श उपाय नाही.

2.5 किंमत द्यावी लागेल

औपचारिकपणे, आम्हाला आता माहित आहे की आम्हाला "सर्व काही" माहित आहे. हे खरे आहे की, आपल्याला एक मोठी डोकेदुखी आणि दोन लहान डोकेदुखी माहित नाही.

1. साधी वेदना: वाईटरित्या smeared

हे पाठ्यपुस्तकातील एक उदाहरण आहे, जे जवळजवळ कधीही युद्धात होत नाही, परंतु अचानक.

  • तारखेसह उदाहरण म्हणून, केवळ तारखेशिवाय!
  • नकळत असमान (समजण्यायोग्य) वितरण.

त्यांनी शार्डिंग यंत्रणा निवडली, आणि/किंवा डेटा बदलला, आणि अर्थातच, PM ने आवश्यकता सांगितल्या नाहीत (आमच्याकडे कोडमध्ये त्रुटी नाहीत, PM नेहमी आवश्यकता नोंदवत नाही), आणि वितरण भयंकर असमान झाले. म्हणजेच ते निकष चुकले.

पकडण्यासाठी, आपल्याला शार्ड्सचा आकार पाहण्याची आवश्यकता आहे. जेव्हा आमचा एक शार्ड जास्त तापतो किंवा इतरांपेक्षा 100 पट मोठा होतो तेव्हा आम्हाला या क्षणी समस्या नक्कीच दिसेल. तुम्ही फक्त की किंवा शार्डिंग फंक्शन बदलून त्याचे निराकरण करू शकता.

ही एक साधी समस्या आहे, खरे सांगायचे तर, मला असे वाटत नाही की शंभर पैकी किमान एक व्यक्ती या आयुष्यात धावेल, परंतु अचानक ते कमीतकमी एखाद्यास मदत करेल.

2. "अजिंक्य" वेदना: एकत्रीकरण, सामील होणे

एका टेबलवरून अब्ज रेकॉर्ड्समध्ये सामील होणार्‍या निवडी कशा करायच्या?

  • "त्वरीत" गणना कशी करायची... एएए आणि बीबीबीमध्ये रँडकोल कुठे आहे?
  • "चतुराईने" कसे करायचे... user_32shads JOIN posts_1024 shards?

लहान उत्तर: नाही, दुःख!

जर तुम्ही पहिल्या सारणीतील एक हजार सर्व्हरना एक अब्ज रेकॉर्ड वितरित केले जेणेकरून ते जलद कार्य करू शकतील आणि दुसऱ्या टेबलमध्ये तेच केले तर स्वाभाविकपणे हजार ते हजार सर्व्हरने एकमेकांशी जोड्यांमध्ये बोलले पाहिजे. दशलक्ष कनेक्शन चांगले काम करणार नाहीत. आम्ही डेटाबेसला (शोध, स्टोरेज, दस्तऐवज स्टोअर किंवा वितरित फाइल सिस्टम) विनंत्या केल्या ज्या शार्डिंगमध्ये व्यवस्थित बसत नाहीत, तर या विनंत्या अत्यंत कमी होतील.

एक महत्त्वाचा मुद्दा असा आहे की काही विनंत्या नेहमी अयशस्वी केल्या जातील आणि मंद होतील . त्यांची टक्केवारी कमी करण्याचा प्रयत्न करणे महत्त्वाचे आहे. परिणामी, एक अब्ज बाय एक अब्ज रेकॉर्डसह अवाढव्य सामील होण्याची गरज नाही. एका लहान टेबलची प्रतिकृती बनवणे शक्य असल्यास, ज्याच्या सापेक्ष तुम्ही एका विशाल सामायिक टेबलमध्ये सामील होत आहात, सर्व नोड्सवर, तुम्ही ते करावे. जर जॉइन्स खरोखर काही मार्गाने स्थानिक असतील, उदाहरणार्थ, वापरकर्ता आणि त्याच्या पोस्ट्स शेजारी ठेवता येतात, त्याच प्रकारे त्यांना शार्ड करणे आणि सर्व जोडणे एकाच मशीनमध्ये करणे शक्य आहे - तुम्हाला ते करणे आवश्यक आहे .

हा तीन दिवसांचा व्याख्यानांचा एक वेगळा कोर्स आहे, तर चला शेवटच्या नरक वेदना आणि त्यास सामोरे जाण्यासाठी भिन्न अल्गोरिदमकडे वळूया.

२.६. जटिल/दीर्घ वेदना: रीशेर्डिंग

तयार व्हा: जर तुम्ही तुमच्या आयुष्यात पहिल्यांदाच तुमचा डेटा शेअर केला असेल, तर सरासरी तुम्ही आणखी पाच वेळा तो शेअर कराल.

तुम्ही कितीही क्लस्टर कॉन्फिगर केले तरीही, तुम्हाला रीशेर्ड करणे आवश्यक आहे.

जर तुम्ही खूप हुशार आणि भाग्यवान असाल तर एकदा तरी ओव्हरशार्ड करा. परंतु एकदा तुम्हाला खात्री पटली, कारण ज्या क्षणी तुम्हाला वाटतं की वापरकर्त्यासाठी 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).

याला Rendezvous hashing का म्हणतात हे मला माहीत नाही, पण मला माहित आहे की त्याला Highest Random Weight का म्हणतात. हे असे दृश्यमान करणे खूप सोपे आहे:

आमच्याकडे, उदाहरणार्थ, 16 शार्ड्स आहेत. प्रत्येक ऑब्जेक्टसाठी (स्ट्रिंग) ज्याला कुठेतरी ठेवण्याची आवश्यकता आहे, आम्ही शार्ड क्रमांकावरील ऑब्जेक्टवर अवलंबून 16 हॅशची गणना करतो. ज्याच्याकडे सर्वाधिक हॅश मूल्य आहे तो जिंकतो.

हे तथाकथित HRW-हॅशिंग आहे, उर्फ ​​​​रेन्डेव्हस हॅशिंग. काठी म्हणून मूक, शार्डची संख्या मोजण्याची योजना, प्रथम, डोळ्यावर वर्तुळांपेक्षा सोपे आहे आणि दुसरीकडे एकसमान भार देते.

फक्त नकारात्मक म्हणजे नवीन शार्ड जोडणे आमच्यासाठी वाईट झाले आहे. एक धोका आहे की नवीन शार्ड जोडताना, आमच्याकडे अजूनही काही हॅश आहेत जे बदलतील आणि प्रत्येक गोष्टीचे पुनरावलोकन करणे आवश्यक असू शकते. शार्ड काढण्याचे तंत्रज्ञान फारसे बदललेले नाही.

दुसरी समस्या अशी आहे की ते मोठ्या संख्येने शार्ड्ससह संगणकीयदृष्ट्या जड आहे.

अधिक मजेदार # 5. अधिक तंत्रे

विशेष म्हणजे, संशोधन स्थिर नाही आणि Google दरवर्षी काही नवीन अंतराळ तंत्रज्ञान प्रकाशित करते:

  • जंप हॅश - Google '2014.
  • मल्टी प्रोब—Google '2015.
  • Maglev-Google '2016.

जर तुम्हाला या विषयात रस असेल तर तुम्ही अनेक प्रबंध वाचू शकता. समस्येचे निराकरण झाले नाही हे स्पष्ट करण्यासाठी मी हा डेटा सादर करतो, असे कोणतेही सुपर-सोल्यूशन नाही जे सर्व डेटाबेसमध्ये लागू केले जाऊ शकते. आतापर्यंत, लोक प्रबंधांचे रक्षण करतात.

निष्कर्ष

गॅलियस ज्युलियस सीझरच्या नावावर शार्डिंग नावाचे एक महत्त्वाचे मूलभूत तंत्र आहे: “विभागा आणि राज्य करा, राज्य करा आणि विभाजन करा!”. डेटा एका सर्व्हरमध्ये बसत नसल्यास, तो 20 सर्व्हरमध्ये विभाजित करणे आवश्यक आहे.

हे सर्व जाणून घेतल्यावर, एखाद्याला असे समजले पाहिजे की ते न करणे चांगले आहे. जर तुम्ही ठरवले असेल की ते शार्ड न करणे चांगले होईल, ही योग्य भावना आहे. जर तुम्ही सर्व्हरवर $100 मध्ये मेमरी जोडू शकत असाल आणि काहीही न टाकता, तर तुम्ही ते केले पाहिजे. शार्डिंग करताना, एक जटिल वितरित प्रणाली दिसेल ज्यामध्ये डेटा पुढे-मागे हस्तांतरित होईल, डेटा कोठे स्टॅक केला जाईल हे कोणालाही माहिती नाही. जर ते टाळता येत असेल तर ते टाळले पाहिजे.

हे हाताने न करणे चांगले आहे, "बेस" (शोध, डीएफएस, ...) स्वतःच तुकडे करणे चांगले आहे. कोणत्याही परिस्थितीत, लवकरच किंवा नंतर, हायलोड येईल आणि कसा तरी डेटा विभाजित करावा लागेल. हे तथ्य नाही की जरी बेस ते स्वतः करू शकत असले तरी, तुम्हाला कोणतीही समस्या येणार नाही. अल्गोरिदमिक कट्टरतावाद लक्षात ठेवा - आपल्याला सर्वकाही आत कसे कार्य करते हे समजून घेणे आवश्यक आहे.

प्रथमच शार्डिंग सेट करताना, F() काळजीपूर्वक निवडा, विनंत्या, नेटवर्क इत्यादींचा विचार करा. पण तयार व्हा, तुम्हाला कदाचित 2 वेळा निवडावे लागेल आणि किमान एकदा तुम्हाला सर्वकाही पुन्हा करावे लागेल.