NewSQL = NoSQL+ACID

അടുത്ത കാലം വരെ, SQL സെർവറിൽ തത്സമയം പ്രോസസ്സ് ചെയ്ത ഏകദേശം 50 TB ഡാറ്റ Odnoklassniki സംഭരിച്ചു. അത്തരമൊരു വോള്യത്തിന്, ഒരു SQL DBMS ഉപയോഗിച്ച് വേഗതയേറിയതും വിശ്വസനീയവുമായ ഡാറ്റാ സെന്റർ പരാജയം-സഹിഷ്ണുതയുള്ള ആക്സസ് പോലും നൽകുന്നത് മിക്കവാറും അസാധ്യമാണ്. സാധാരണഗതിയിൽ, അത്തരം സന്ദർഭങ്ങളിൽ, NoSQL സ്റ്റോറേജുകളിലൊന്ന് ഉപയോഗിക്കുന്നു, എന്നാൽ എല്ലാം NoSQL-ലേക്ക് കൈമാറാൻ കഴിയില്ല: ചില സ്ഥാപനങ്ങൾക്ക് ACID ഇടപാട് ഗ്യാരണ്ടി ആവശ്യമാണ്.

ഇത് ഞങ്ങളെ NewSQL സംഭരണത്തിന്റെ ഉപയോഗത്തിലേക്ക് നയിച്ചു, അതായത്, NoSQL സിസ്റ്റങ്ങളുടെ തെറ്റ് സഹിഷ്ണുത, സ്കേലബിളിറ്റി, പ്രകടനം എന്നിവ നൽകുന്ന ഒരു DBMS, എന്നാൽ അതേ സമയം ACID നിലനിർത്തുന്നത് ക്ലാസിക്കൽ സിസ്റ്റങ്ങൾക്ക് പരിചിതമായ ഗ്യാരണ്ടി നൽകുന്നു. ഈ പുതിയ ക്ലാസിൽ കുറച്ച് പ്രവർത്തിക്കുന്ന വ്യാവസായിക സംവിധാനങ്ങളുണ്ട്, അതിനാൽ ഞങ്ങൾ അത്തരമൊരു സംവിധാനം സ്വയം നടപ്പിലാക്കുകയും വാണിജ്യപരമായ പ്രവർത്തനത്തിലേക്ക് നയിക്കുകയും ചെയ്തു.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, എന്താണ് സംഭവിച്ചത് - കട്ടിന് കീഴിൽ വായിക്കുക.

ഇന്ന്, ഒഡ്‌നോക്ലാസ്‌നിക്കിയുടെ പ്രതിമാസ പ്രേക്ഷകർ 70 ദശലക്ഷത്തിലധികം അതുല്യ സന്ദർശകരാണ്. ഞങ്ങൾ ഞങ്ങൾ ആദ്യ അഞ്ചിൽ ആണ് ലോകത്തിലെ ഏറ്റവും വലിയ സോഷ്യൽ നെറ്റ്‌വർക്കുകൾ, കൂടാതെ ഉപയോക്താക്കൾ ഏറ്റവും കൂടുതൽ സമയം ചെലവഴിക്കുന്ന ഇരുപത് സൈറ്റുകളിൽ. OK ഇൻഫ്രാസ്ട്രക്ചർ വളരെ ഉയർന്ന ലോഡുകൾ കൈകാര്യം ചെയ്യുന്നു: ഒരു ദശലക്ഷത്തിലധികം HTTP അഭ്യർത്ഥനകൾ/സെക്കൻഡ് ഓരോ മുന്നിലും. 8000 ലധികം കഷണങ്ങളുള്ള ഒരു സെർവർ ഫ്ലീറ്റിന്റെ ഭാഗങ്ങൾ പരസ്പരം അടുത്ത് സ്ഥിതിചെയ്യുന്നു - നാല് മോസ്കോ ഡാറ്റാ സെന്ററുകളിൽ, അവയ്ക്കിടയിൽ 1 എംഎസിൽ താഴെയുള്ള നെറ്റ്‌വർക്ക് ലേറ്റൻസി അനുവദിക്കുന്നു.

പതിപ്പ് 2010 മുതൽ ഞങ്ങൾ 0.6 മുതൽ കസാന്ദ്ര ഉപയോഗിക്കുന്നു. ഇന്ന് നിരവധി ഡസൻ ക്ലസ്റ്ററുകൾ പ്രവർത്തിക്കുന്നുണ്ട്. ഏറ്റവും വേഗതയേറിയ ക്ലസ്റ്റർ സെക്കൻഡിൽ 4 ദശലക്ഷത്തിലധികം ഓപ്പറേഷനുകൾ പ്രോസസ്സ് ചെയ്യുന്നു, ഏറ്റവും വലിയ 260 TB സംഭരിക്കുന്നു.

എന്നിരുന്നാലും, ഇവയെല്ലാം സംഭരണത്തിനായി ഉപയോഗിക്കുന്ന സാധാരണ NoSQL ക്ലസ്റ്ററുകളാണ് ദുർബലമായി ഏകോപിപ്പിച്ചു ഡാറ്റ. Odnoklassniki സ്ഥാപിതമായതുമുതൽ ഉപയോഗിച്ചിരുന്ന മൈക്രോസോഫ്റ്റ് SQL സെർവർ എന്ന പ്രധാന സ്ഥിരതയുള്ള സംഭരണം മാറ്റിസ്ഥാപിക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. സ്റ്റോറേജിൽ 300-ലധികം SQL സെർവർ സ്റ്റാൻഡേർഡ് എഡിഷൻ മെഷീനുകൾ അടങ്ങിയിരിക്കുന്നു, അതിൽ 50 TB ഡാറ്റ - ബിസിനസ് സ്ഥാപനങ്ങൾ അടങ്ങിയിരിക്കുന്നു. ഈ ഡാറ്റ ACID ഇടപാടുകളുടെ ഭാഗമായി പരിഷ്‌ക്കരിച്ചിരിക്കുന്നു, അത് ആവശ്യമാണ് ഉയർന്ന സ്ഥിരത.

SQL സെർവർ നോഡുകളിലുടനീളം ഡാറ്റ വിതരണം ചെയ്യുന്നതിന്, ഞങ്ങൾ ലംബമായും തിരശ്ചീനമായും ഉപയോഗിച്ചു വിഭജനം (ഷാർഡിംഗ്). ചരിത്രപരമായി, ഞങ്ങൾ ഒരു ലളിതമായ ഡാറ്റ ഷെർഡിംഗ് സ്കീം ഉപയോഗിച്ചു: ഓരോ എന്റിറ്റിയും ഒരു ടോക്കണുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു - എന്റിറ്റി ഐഡിയുടെ ഒരു ഫംഗ്ഷൻ. ഒരേ ടോക്കണുള്ള എന്റിറ്റികൾ ഒരേ SQL സെർവറിൽ സ്ഥാപിച്ചു. പ്രധാന-ചൈൽഡ് റെക്കോർഡുകളുടെ ടോക്കണുകൾ എല്ലായ്പ്പോഴും പൊരുത്തപ്പെടുന്ന തരത്തിൽ മാസ്റ്റർ-ഡീറ്റെയ്ൽ ബന്ധം നടപ്പിലാക്കി, ഒരേ സെർവറിൽ അത് സ്ഥിതിചെയ്യുന്നു. ഒരു സോഷ്യൽ നെറ്റ്‌വർക്കിൽ, മിക്കവാറും എല്ലാ റെക്കോർഡുകളും ഉപയോക്താവിന് വേണ്ടി സൃഷ്ടിക്കപ്പെടുന്നു - അതായത് ഒരു ഫംഗ്ഷണൽ സബ്സിസ്റ്റത്തിലെ എല്ലാ ഉപയോക്തൃ ഡാറ്റയും ഒരു സെർവറിൽ സംഭരിക്കുന്നു എന്നാണ്. അതായത്, ഒരു ബിസിനസ് ഇടപാടിൽ എല്ലായ്പ്പോഴും ഒരു SQL സെർവറിൽ നിന്നുള്ള പട്ടികകൾ ഉൾപ്പെടുന്നു, ഇത് ഉപയോഗിക്കേണ്ട ആവശ്യമില്ലാതെ തന്നെ പ്രാദേശിക ACID ഇടപാടുകൾ ഉപയോഗിച്ച് ഡാറ്റ സ്ഥിരത ഉറപ്പാക്കുന്നത് സാധ്യമാക്കി. മന്ദഗതിയിലുള്ളതും വിശ്വസനീയമല്ലാത്തതുമാണ് വിതരണം ചെയ്ത ACID ഇടപാടുകൾ.

ഷാർഡിംഗിനും SQL വേഗത്തിലാക്കുന്നതിനും നന്ദി:

• ഞങ്ങൾ വിദേശ കീ നിയന്ത്രണങ്ങൾ ഉപയോഗിക്കുന്നില്ല, കാരണം ഷാർഡ് ചെയ്യുമ്പോൾ എന്റിറ്റി ഐഡി മറ്റൊരു സെർവറിൽ സ്ഥിതിചെയ്യാം.
• DBMS സിപിയുവിലെ അധിക ലോഡ് കാരണം ഞങ്ങൾ സംഭരിച്ച നടപടിക്രമങ്ങളും ട്രിഗറുകളും ഉപയോഗിക്കുന്നില്ല.
• മേൽപ്പറഞ്ഞവയെല്ലാം കാരണം ഞങ്ങൾ JOIN-കൾ ഉപയോഗിക്കുന്നില്ല, കൂടാതെ ഡിസ്കിൽ നിന്ന് ക്രമരഹിതമായ ധാരാളം റീഡുകളും.
• ഒരു ഇടപാടിന് പുറത്ത്, ഡെഡ്‌ലോക്കുകൾ കുറയ്ക്കുന്നതിന് ഞങ്ങൾ റീഡ് അൺകമ്മിറ്റഡ് ഐസൊലേഷൻ ലെവൽ ഉപയോഗിക്കുന്നു.
• ഞങ്ങൾ ചെറിയ ഇടപാടുകൾ മാത്രമേ നടത്തൂ (ശരാശരി 100 എംഎസിൽ താഴെ).
• ധാരാളം ഡെഡ്‌ലോക്കുകൾ ഉള്ളതിനാൽ ഞങ്ങൾ മൾട്ടി-വരി അപ്‌ഡേറ്റും ഇല്ലാതാക്കലും ഉപയോഗിക്കുന്നില്ല - ഞങ്ങൾ ഒരു സമയം ഒരു റെക്കോർഡ് മാത്രം അപ്‌ഡേറ്റ് ചെയ്യുന്നു.
• ഞങ്ങൾ എല്ലായ്‌പ്പോഴും ഇൻഡെക്‌സുകളിൽ മാത്രമാണ് അന്വേഷണങ്ങൾ നടത്തുന്നത് - ഞങ്ങൾക്കായി ഒരു പൂർണ്ണ ടേബിൾ സ്കാൻ പ്ലാൻ ഉള്ള ഒരു ചോദ്യം ഡാറ്റാബേസ് ഓവർലോഡ് ചെയ്യുകയും അത് പരാജയപ്പെടുത്തുകയും ചെയ്യുന്നു.

SQL സെർവറുകളിൽ നിന്ന് പരമാവധി പ്രകടനം പുറത്തെടുക്കാൻ ഈ ഘട്ടങ്ങൾ ഞങ്ങളെ അനുവദിച്ചു. എന്നിരുന്നാലും, പ്രശ്നങ്ങൾ കൂടുതൽ കൂടുതൽ വർദ്ധിച്ചു. നമുക്ക് അവരെ നോക്കാം.

SQL-ലെ പ്രശ്നങ്ങൾ

• ഞങ്ങൾ സ്വയം എഴുതിയ ഷാർഡിംഗ് ഉപയോഗിച്ചതിനാൽ, പുതിയ ഷാർഡുകൾ ചേർക്കുന്നത് അഡ്മിനിസ്ട്രേറ്റർമാർ സ്വമേധയാ ചെയ്തു. ഈ സമയമത്രയും, സ്കെയിലബിൾ ഡാറ്റാ പകർപ്പുകൾ അഭ്യർത്ഥനകൾക്ക് സേവനം നൽകുന്നതായിരുന്നില്ല.
• പട്ടികയിലെ റെക്കോർഡുകളുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച്, ഇൻസെർഷന്റെയും പരിഷ്‌ക്കരണത്തിന്റെയും വേഗത കുറയുന്നു; നിലവിലുള്ള ഒരു പട്ടികയിലേക്ക് സൂചികകൾ ചേർക്കുമ്പോൾ, വേഗത ഒരു ഘടകം കൊണ്ട് കുറയുന്നു; സൂചികകളുടെ നിർമ്മാണവും പുനർനിർമ്മാണവും പ്രവർത്തനരഹിതമായ സമയത്താണ് സംഭവിക്കുന്നത്.
• ഉൽപ്പാദനത്തിൽ SQL സെർവറിനായി ചെറിയ അളവിൽ വിൻഡോസ് ഉള്ളത് ഇൻഫ്രാസ്ട്രക്ചർ മാനേജ്മെന്റ് ബുദ്ധിമുട്ടാക്കുന്നു

എന്നാൽ പ്രധാന പ്രശ്നം

തെറ്റ് സഹിഷ്ണുത

ക്ലാസിക് SQL സെർവറിന് മോശം തെറ്റ് സഹിഷ്ണുതയുണ്ട്. നിങ്ങൾക്ക് ഒരു ഡാറ്റാബേസ് സെർവർ മാത്രമേയുള്ളൂ, അത് മൂന്ന് വർഷത്തിലൊരിക്കൽ പരാജയപ്പെടുമെന്ന് നമുക്ക് പറയാം. ഈ സമയത്ത് സൈറ്റ് 20 മിനിറ്റ് നേരത്തേക്ക് പ്രവർത്തനരഹിതമാണ്, അത് സ്വീകാര്യമാണ്. നിങ്ങൾക്ക് 64 സെർവറുകൾ ഉണ്ടെങ്കിൽ, ഓരോ മൂന്നാഴ്ചയിലൊരിക്കൽ സൈറ്റ് പ്രവർത്തനരഹിതമാകും. നിങ്ങൾക്ക് 200 സെർവറുകൾ ഉണ്ടെങ്കിൽ, സൈറ്റ് എല്ലാ ആഴ്ചയും പ്രവർത്തിക്കില്ല. ഇത് പ്രശ്നമാണ്.

ഒരു SQL സെർവറിന്റെ തെറ്റ് സഹിഷ്ണുത മെച്ചപ്പെടുത്താൻ എന്താണ് ചെയ്യേണ്ടത്? നിർമ്മിക്കാൻ വിക്കിപീഡിയ ഞങ്ങളെ ക്ഷണിക്കുന്നു വളരെ ലഭ്യമായ ക്ലസ്റ്റർ: ഏതെങ്കിലും ഘടകങ്ങളുടെ പരാജയത്തിന്റെ കാര്യത്തിൽ ഒരു ബാക്കപ്പ് ഉണ്ട്.

ഇതിന് വിലയേറിയ ഉപകരണങ്ങളുടെ ഒരു കൂട്ടം ആവശ്യമാണ്: നിരവധി ഡ്യൂപ്ലിക്കേഷനുകൾ, ഒപ്റ്റിക്കൽ ഫൈബർ, പങ്കിട്ട സംഭരണം, ഒരു കരുതൽ ഉൾപ്പെടുത്തൽ എന്നിവ വിശ്വസനീയമായി പ്രവർത്തിക്കുന്നില്ല: ഏകദേശം 10% സ്വിച്ചിംഗുകൾ പ്രധാന നോഡിന് പിന്നിൽ ഒരു ട്രെയിൻ പോലെയുള്ള ബാക്കപ്പ് നോഡിന്റെ പരാജയത്തോടെ അവസാനിക്കുന്നു.

എന്നാൽ വളരെ ലഭ്യമായ അത്തരം ഒരു ക്ലസ്റ്ററിന്റെ പ്രധാന പോരായ്മ അത് സ്ഥിതി ചെയ്യുന്ന ഡാറ്റാ സെന്റർ പരാജയപ്പെടുകയാണെങ്കിൽ പൂജ്യം ലഭ്യതയാണ്. Odnoklassniki ന് നാല് ഡാറ്റാ സെന്ററുകളുണ്ട്, അവയിലൊന്നിൽ പൂർണ്ണ പരാജയം സംഭവിച്ചാൽ ഞങ്ങൾ പ്രവർത്തനം ഉറപ്പാക്കേണ്ടതുണ്ട്.

ഇതിനായി നമുക്ക് ഉപയോഗിക്കാം മൾട്ടി-മാസ്റ്റർ SQL സെർവറിൽ നിർമ്മിച്ച പകർപ്പ്. സോഫ്‌റ്റ്‌വെയറിന്റെ വില കാരണം ഈ പരിഹാരം വളരെ ചെലവേറിയതാണ്, കൂടാതെ റെപ്ലിക്കേഷനിലെ അറിയപ്പെടുന്ന പ്രശ്‌നങ്ങളാൽ ബുദ്ധിമുട്ടുന്നു - സിൻക്രണസ് റെപ്ലിക്കേഷനുമായുള്ള പ്രവചനാതീതമായ ഇടപാട് കാലതാമസവും അസിൻക്രണസ് റെപ്ലിക്കേഷനിൽ പകർപ്പുകൾ പ്രയോഗിക്കുന്നതിലെ കാലതാമസവും (അതിന്റെ ഫലമായി, പരിഷ്‌ക്കരണങ്ങൾ നഷ്ടപ്പെട്ടു). സൂചിപ്പിച്ചത് മാനുവൽ വൈരുദ്ധ്യ പരിഹാരം ഈ ഓപ്ഷൻ ഞങ്ങൾക്ക് പൂർണ്ണമായും അപ്രായോഗികമാക്കുന്നു.

ഈ പ്രശ്നങ്ങൾക്കെല്ലാം സമൂലമായ പരിഹാരം ആവശ്യമാണ്, ഞങ്ങൾ അവ വിശദമായി വിശകലനം ചെയ്യാൻ തുടങ്ങി. SQL സെർവർ പ്രധാനമായും എന്താണ് ചെയ്യുന്നതെന്ന് ഇവിടെ നമ്മൾ പരിചയപ്പെടേണ്ടതുണ്ട് - ഇടപാടുകൾ.

ലളിതമായ ഇടപാട്

ഒരു പ്രയോഗിച്ച SQL പ്രോഗ്രാമറുടെ വീക്ഷണകോണിൽ നിന്ന് ഏറ്റവും ലളിതമായ ഇടപാട് പരിഗണിക്കാം: ഒരു ആൽബത്തിലേക്ക് ഒരു ഫോട്ടോ ചേർക്കൽ. ആൽബങ്ങളും ഫോട്ടോഗ്രാഫുകളും വ്യത്യസ്ത പ്ലേറ്റുകളിൽ സൂക്ഷിച്ചിരിക്കുന്നു. ആൽബത്തിന് ഒരു പൊതു ഫോട്ടോ കൗണ്ടർ ഉണ്ട്. അത്തരമൊരു ഇടപാട് ഇനിപ്പറയുന്ന ഘട്ടങ്ങളായി തിരിച്ചിരിക്കുന്നു:

1. കീ ഉപയോഗിച്ച് ഞങ്ങൾ ആൽബം ലോക്ക് ചെയ്യുന്നു.
2. ഫോട്ടോ ടേബിളിൽ ഒരു എൻട്രി സൃഷ്ടിക്കുക.
3. ഫോട്ടോയ്ക്ക് ഒരു പൊതു സ്റ്റാറ്റസ് ഉണ്ടെങ്കിൽ, ആൽബത്തിലേക്ക് ഒരു പൊതു ഫോട്ടോ കൗണ്ടർ ചേർക്കുക, റെക്കോർഡ് അപ്ഡേറ്റ് ചെയ്ത് ഇടപാട് നടത്തുക.

അല്ലെങ്കിൽ സ്യൂഡോകോഡിൽ:

TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);

if (photo.status == PUBLIC ) {
    album.incPublicPhotosCount();
}
album.update();

TX.commit();

ഒരു ബിസിനസ് ഇടപാടിന്റെ ഏറ്റവും സാധാരണമായ സാഹചര്യം ഡാറ്റാബേസിൽ നിന്ന് ആപ്ലിക്കേഷൻ സെർവറിന്റെ മെമ്മറിയിലേക്ക് ഡാറ്റ വായിക്കുകയും എന്തെങ്കിലും മാറ്റുകയും പുതിയ മൂല്യങ്ങൾ ഡാറ്റാബേസിലേക്ക് തിരികെ സംരക്ഷിക്കുകയും ചെയ്യുക എന്നതാണ്. സാധാരണയായി അത്തരം ഒരു ഇടപാടിൽ ഞങ്ങൾ നിരവധി എന്റിറ്റികൾ, നിരവധി പട്ടികകൾ അപ്ഡേറ്റ് ചെയ്യുന്നു.

ഒരു ഇടപാട് നടത്തുമ്പോൾ, മറ്റൊരു സിസ്റ്റത്തിൽ നിന്നുള്ള അതേ ഡാറ്റയുടെ ഒരേസമയം മാറ്റം സംഭവിക്കാം. ഉദാഹരണത്തിന്, ഉപയോക്താവ് എങ്ങനെയെങ്കിലും സംശയാസ്പദമാണെന്ന് ആന്റിസ്പാം തീരുമാനിച്ചേക്കാം, അതിനാൽ ഉപയോക്താവിന്റെ എല്ലാ ഫോട്ടോകളും മേലിൽ പൊതുവായതായിരിക്കരുത്, അവ മോഡറേഷനായി അയയ്‌ക്കേണ്ടതുണ്ട്, അതായത് photo.status മറ്റേതെങ്കിലും മൂല്യത്തിലേക്ക് മാറ്റുകയും അനുബന്ധ കൗണ്ടറുകൾ ഓഫ് ചെയ്യുകയും ചെയ്യുന്നു. വ്യക്തമായും, ഈ പ്രവർത്തനം പ്രയോഗത്തിന്റെ ആറ്റോമിസിറ്റിയുടെ ഗ്യാരണ്ടിയും മത്സരിക്കുന്ന പരിഷ്കാരങ്ങളുടെ ഒറ്റപ്പെടലും ഇല്ലാതെ സംഭവിക്കുകയാണെങ്കിൽ എസിഐഡി, അപ്പോൾ ഫലം ആവശ്യമുള്ളതായിരിക്കില്ല - ഒന്നുകിൽ ഫോട്ടോ കൗണ്ടർ തെറ്റായ മൂല്യം കാണിക്കും, അല്ലെങ്കിൽ എല്ലാ ഫോട്ടോകളും മോഡറേഷനായി അയയ്‌ക്കില്ല.

ഒഡ്‌നോക്ലാസ്‌നിക്കിയുടെ മുഴുവൻ അസ്തിത്വത്തിലുടനീളം സമാനമായ നിരവധി കോഡുകൾ, ഒരു ഇടപാടിനുള്ളിൽ വിവിധ ബിസിനസ്സ് സ്ഥാപനങ്ങൾ കൈകാര്യം ചെയ്യുന്നു. NoSQL-ലേക്കുള്ള മൈഗ്രേഷനുകളുടെ അനുഭവത്തെ അടിസ്ഥാനമാക്കി ആത്യന്തികമായ സ്ഥിരത ഡാറ്റ സ്ഥിരത നിലനിർത്തുന്നതിനുള്ള കോഡ് വികസിപ്പിക്കുന്നതിൽ നിന്നാണ് ഏറ്റവും വലിയ വെല്ലുവിളി (സമയ നിക്ഷേപം) വരുന്നതെന്ന് ഞങ്ങൾക്കറിയാം. അതിനാൽ, ആപ്ലിക്കേഷൻ ലോജിക്കിനായുള്ള യഥാർത്ഥ ACID ഇടപാടുകൾക്കുള്ള വ്യവസ്ഥയാണ് പുതിയ സംഭരണത്തിനുള്ള പ്രധാന ആവശ്യകത ഞങ്ങൾ പരിഗണിച്ചത്.

മറ്റ്, പ്രാധാന്യം കുറവല്ല, ആവശ്യകതകൾ ഇവയായിരുന്നു:

• ഡാറ്റാ സെന്റർ പരാജയപ്പെടുകയാണെങ്കിൽ, പുതിയ സ്റ്റോറേജിൽ വായിക്കുന്നതും എഴുതുന്നതും ലഭ്യമായിരിക്കണം.
• നിലവിലെ വികസന വേഗത നിലനിർത്തുന്നു. അതായത്, ഒരു പുതിയ ശേഖരത്തിൽ പ്രവർത്തിക്കുമ്പോൾ, കോഡിന്റെ അളവ് ഏകദേശം തുല്യമായിരിക്കണം; ശേഖരത്തിലേക്ക് ഒന്നും ചേർക്കേണ്ട ആവശ്യമില്ല, പൊരുത്തക്കേടുകൾ പരിഹരിക്കുന്നതിനും ദ്വിതീയ സൂചികകൾ നിലനിർത്തുന്നതിനും അൽഗോരിതം വികസിപ്പിക്കുക തുടങ്ങിയവ.
• ഡാറ്റ വായിക്കുമ്പോഴും ഇടപാടുകൾ പ്രോസസ്സ് ചെയ്യുമ്പോഴും പുതിയ സ്റ്റോറേജിന്റെ വേഗത വളരെ ഉയർന്നതായിരിക്കണം, ഇത് ഫലപ്രദമായി അർത്ഥമാക്കുന്നത് അക്കാദമികമായി കർശനവും സാർവത്രികവും എന്നാൽ മന്ദഗതിയിലുള്ളതുമായ പരിഹാരങ്ങൾ, ഉദാഹരണത്തിന്, ബാധകമല്ല എന്നാണ്. രണ്ട് ഘട്ടങ്ങൾ.
• സ്വയമേവയുള്ള ഓൺ-ദി-ഫ്ലൈ സ്കെയിലിംഗ്.
• എക്സോട്ടിക് ഹാർഡ്‌വെയർ വാങ്ങേണ്ട ആവശ്യമില്ലാതെ, സാധാരണ വിലകുറഞ്ഞ സെർവറുകൾ ഉപയോഗിക്കുന്നു.
• കമ്പനി ഡെവലപ്പർമാരുടെ സംഭരണ ​​വികസനത്തിന്റെ സാധ്യത. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, കുത്തക അല്ലെങ്കിൽ ഓപ്പൺ സോഴ്‌സ് സൊല്യൂഷനുകൾക്ക് മുൻഗണന നൽകി, ജാവയിൽ.

തീരുമാനങ്ങൾ, തീരുമാനങ്ങൾ

സാധ്യമായ പരിഹാരങ്ങൾ വിശകലനം ചെയ്യുന്നതിലൂടെ, സാധ്യമായ രണ്ട് വാസ്തുവിദ്യാ തിരഞ്ഞെടുപ്പുകളിലേക്ക് ഞങ്ങൾ എത്തി:

ആദ്യത്തേത്, ഏതെങ്കിലും SQL സെർവർ എടുത്ത് ആവശ്യമായ തെറ്റ് സഹിഷ്ണുത, സ്കെയിലിംഗ് സംവിധാനം, പരാജയ ക്ലസ്റ്റർ, വൈരുദ്ധ്യ പരിഹാരം, വിതരണം ചെയ്തതും വിശ്വസനീയവും വേഗതയേറിയതുമായ ACID ഇടപാടുകൾ എന്നിവ നടപ്പിലാക്കുക എന്നതാണ്. ഞങ്ങൾ ഈ ഓപ്ഷൻ വളരെ നിസ്സാരമല്ലാത്തതും അധ്വാനം ആവശ്യമുള്ളതുമായി റേറ്റുചെയ്തു.

രണ്ടാമത്തെ ഐച്ഛികം, നടപ്പിലാക്കിയ സ്കെയിലിംഗ്, ഒരു പരാജയ ക്ലസ്റ്റർ, വൈരുദ്ധ്യ പരിഹാരം എന്നിവയുള്ള ഒരു റെഡിമെയ്ഡ് NoSQL സ്റ്റോറേജ് എടുക്കുക, കൂടാതെ ഇടപാടുകളും SQL-ഉം സ്വയം നടപ്പിലാക്കുക. ഒറ്റനോട്ടത്തിൽ, ACID ഇടപാടുകൾ പരാമർശിക്കാതെ SQL നടപ്പിലാക്കുക എന്ന ജോലി പോലും വർഷങ്ങളെടുക്കുന്ന ഒരു ജോലിയാണെന്ന് തോന്നുന്നു. എന്നാൽ ഞങ്ങൾ പ്രായോഗികമായി ഉപയോഗിക്കുന്ന SQL ഫീച്ചർ സെറ്റ് ANSI SQL-ൽ നിന്ന് വളരെ അകലെയാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി കസാന്ദ്ര CQL ANSI SQL-ൽ നിന്ന് വളരെ അകലെ. CQL-നെ കൂടുതൽ സൂക്ഷ്മമായി പരിശോധിച്ചപ്പോൾ, അത് ഞങ്ങൾക്ക് ആവശ്യമുള്ളതിന് വളരെ അടുത്താണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി.

കസാന്ദ്രയും CQL

അതിനാൽ, കസാന്ദ്രയെക്കുറിച്ച് എന്താണ് രസകരമായത്, അതിന് എന്ത് കഴിവുകളുണ്ട്?

ഒന്നാമതായി, ഇവിടെ നിങ്ങൾക്ക് വിവിധ ഡാറ്റാ തരങ്ങളെ പിന്തുണയ്ക്കുന്ന പട്ടികകൾ സൃഷ്ടിക്കാൻ കഴിയും; നിങ്ങൾക്ക് പ്രാഥമിക കീയിൽ SELECT അല്ലെങ്കിൽ അപ്ഡേറ്റ് ചെയ്യാം.

CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;

റെപ്ലിക്ക ഡാറ്റ സ്ഥിരത ഉറപ്പാക്കാൻ, കസാന്ദ്ര ഉപയോഗിക്കുന്നു കോറം സമീപനം. ഏറ്റവും ലളിതമായ സാഹചര്യത്തിൽ, ഒരേ വരിയുടെ മൂന്ന് പകർപ്പുകൾ ക്ലസ്റ്ററിന്റെ വ്യത്യസ്ത നോഡുകളിൽ സ്ഥാപിക്കുമ്പോൾ, ഈ റൈറ്റ് ഓപ്പറേഷന്റെ വിജയം സ്ഥിരീകരിച്ചാൽ, ഭൂരിപക്ഷം നോഡുകളും (അതായത്, മൂന്നിൽ രണ്ട്) എഴുതുന്നത് വിജയകരമാണെന്ന് കണക്കാക്കുന്നു. . വായിക്കുമ്പോൾ, ഭൂരിഭാഗം നോഡുകളും പോൾ ചെയ്യുകയും സ്ഥിരീകരിക്കുകയും ചെയ്താൽ വരി ഡാറ്റ സ്ഥിരതയുള്ളതായി കണക്കാക്കുന്നു. അങ്ങനെ, മൂന്ന് പകർപ്പുകൾ ഉപയോഗിച്ച്, ഒരു നോഡ് പരാജയപ്പെടുകയാണെങ്കിൽ പൂർണ്ണവും തൽക്ഷണ ഡാറ്റാ സ്ഥിരത ഉറപ്പുനൽകുന്നു. ഈ സമീപനം കൂടുതൽ വിശ്വസനീയമായ ഒരു സ്കീം നടപ്പിലാക്കാൻ ഞങ്ങളെ അനുവദിച്ചു: മൂന്ന് പകർപ്പുകളിലേക്കും എല്ലായ്പ്പോഴും അഭ്യർത്ഥനകൾ അയയ്‌ക്കുക, ഏറ്റവും വേഗതയേറിയ രണ്ടിൽ നിന്നുള്ള പ്രതികരണത്തിനായി കാത്തിരിക്കുക. മൂന്നാമത്തെ പകർപ്പിന്റെ വൈകിയുള്ള പ്രതികരണം ഈ സാഹചര്യത്തിൽ നിരസിക്കപ്പെട്ടു. പ്രതികരിക്കാൻ വൈകിയ ഒരു നോഡിന് ഗുരുതരമായ പ്രശ്നങ്ങൾ ഉണ്ടാകാം - ബ്രേക്കുകൾ, JVM-ലെ മാലിന്യ ശേഖരണം, ലിനക്സ് കേർണലിൽ നേരിട്ടുള്ള മെമ്മറി വീണ്ടെടുക്കൽ, ഹാർഡ്‌വെയർ പരാജയം, നെറ്റ്‌വർക്കിൽ നിന്നുള്ള വിച്ഛേദിക്കൽ. എന്നിരുന്നാലും, ഇത് ക്ലയന്റിന്റെ പ്രവർത്തനങ്ങളെയോ ഡാറ്റയെയോ ഒരു തരത്തിലും ബാധിക്കില്ല.

ഞങ്ങൾ മൂന്ന് നോഡുകളുമായി ബന്ധപ്പെടുകയും രണ്ടിൽ നിന്ന് പ്രതികരണം ലഭിക്കുകയും ചെയ്യുന്ന സമീപനത്തെ വിളിക്കുന്നു ഊഹക്കച്ചവടം: അധിക പകർപ്പുകൾക്കായുള്ള അഭ്യർത്ഥന അത് "കൊഴിഞ്ഞുവീഴുന്നതിന്" മുമ്പുതന്നെ അയച്ചു.

കസാന്ദ്രയുടെ മറ്റൊരു നേട്ടം ബാച്ച്‌ലോഗ് ആണ്, നിങ്ങൾ വരുത്തുന്ന ഒരു കൂട്ടം മാറ്റങ്ങൾ ഒന്നുകിൽ പൂർണ്ണമായി പ്രയോഗിച്ചോ അല്ലെങ്കിൽ ബാധകമല്ലെന്നോ ഉറപ്പാക്കുന്ന ഒരു സംവിധാനമാണ്. ACID-ലെ ബോക്‌സിന് പുറത്തുള്ള ആറ്റോമിസിറ്റിയിൽ A പരിഹരിക്കാൻ ഇത് ഞങ്ങളെ അനുവദിക്കുന്നു.

കസാന്ദ്രയിലെ ഇടപാടുകൾക്ക് ഏറ്റവും അടുത്തുള്ളത് "" എന്ന് വിളിക്കപ്പെടുന്നവയാണ്.ഭാരം കുറഞ്ഞ ഇടപാടുകൾ". എന്നാൽ അവ "യഥാർത്ഥ" ACID ഇടപാടുകളിൽ നിന്ന് വളരെ അകലെയാണ്: വാസ്തവത്തിൽ, ഇത് ചെയ്യാനുള്ള അവസരമാണ് CAS ഹെവിവെയ്റ്റ് പാക്സോസ് പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് സമവായം ഉപയോഗിച്ച് ഒരു റെക്കോർഡിൽ നിന്നുള്ള ഡാറ്റയിൽ മാത്രം. അതിനാൽ, അത്തരം ഇടപാടുകളുടെ വേഗത കുറവാണ്.

കസാന്ദ്രയിൽ ഞങ്ങൾക്ക് എന്താണ് നഷ്ടമായത്

അതിനാൽ, ഞങ്ങൾക്ക് കസാന്ദ്രയിൽ യഥാർത്ഥ ACID ഇടപാടുകൾ നടപ്പിലാക്കേണ്ടി വന്നു. ഇത് ഉപയോഗിച്ച് നമുക്ക് ക്ലാസിക് DBMS-ന്റെ മറ്റ് രണ്ട് സൗകര്യപ്രദമായ സവിശേഷതകൾ എളുപ്പത്തിൽ നടപ്പിലാക്കാൻ കഴിയും: സ്ഥിരതയുള്ള ഫാസ്റ്റ് സൂചികകൾ, ഇത് പ്രാഥമിക കീ വഴി മാത്രമല്ല ഡാറ്റ തിരഞ്ഞെടുക്കലുകൾ നടത്താൻ ഞങ്ങളെ അനുവദിക്കും, കൂടാതെ മോണോടോണിക് ഓട്ടോ-ഇൻക്രിമെന്റിംഗ് ഐഡികളുടെ ഒരു സാധാരണ ജനറേറ്ററും.

കോൺ

അങ്ങനെ ഒരു പുതിയ DBMS പിറന്നു കോൺ, മൂന്ന് തരം സെർവർ നോഡുകൾ ഉൾക്കൊള്ളുന്നു:

• സംഭരണം - (ഏതാണ്ട്) പ്രാദേശിക ഡിസ്കുകളിൽ ഡാറ്റ സംഭരിക്കുന്നതിനുള്ള ഉത്തരവാദിത്തമുള്ള സ്റ്റാൻഡേർഡ് കസാന്ദ്ര സെർവറുകൾ. ഡാറ്റയുടെ ലോഡും വോളിയവും വർദ്ധിക്കുന്നതിനനുസരിച്ച്, അവയുടെ അളവ് പതിനായിരങ്ങളിലേക്കും നൂറിലേക്കും എളുപ്പത്തിൽ സ്കെയിൽ ചെയ്യാം.
• ഇടപാട് കോർഡിനേറ്റർമാർ - ഇടപാടുകളുടെ നിർവ്വഹണം ഉറപ്പാക്കുക.
• ബിസിനസ്സ് പ്രവർത്തനങ്ങൾ നടപ്പിലാക്കുകയും ഇടപാടുകൾ ആരംഭിക്കുകയും ചെയ്യുന്ന ആപ്ലിക്കേഷൻ സെർവറുകളാണ് ക്ലയന്റുകൾ. അത്തരം ആയിരക്കണക്കിന് ഉപഭോക്താക്കൾ ഉണ്ടാകാം.

എല്ലാ തരത്തിലുമുള്ള സെർവറുകൾ ഒരു പൊതു ക്ലസ്റ്ററിന്റെ ഭാഗമാണ്, പരസ്പരം ആശയവിനിമയം നടത്താൻ ആന്തരിക കസാന്ദ്ര സന്ദേശ പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുക. ഗോസിപ്പ് ക്ലസ്റ്റർ വിവരങ്ങൾ കൈമാറുന്നതിന്. ഹാർട്ട്‌ബീറ്റ് ഉപയോഗിച്ച്, സെർവറുകൾ പരസ്പര പരാജയങ്ങളെക്കുറിച്ച് പഠിക്കുന്നു, ഒരൊറ്റ ഡാറ്റാ സ്കീമ നിലനിർത്തുന്നു - പട്ടികകൾ, അവയുടെ ഘടന, തനിപ്പകർപ്പ്; പാർട്ടീഷനിംഗ് സ്കീം, ക്ലസ്റ്റർ ടോപ്പോളജി മുതലായവ.

ക്ലയന്റുകൾ

സാധാരണ ഡ്രൈവറുകൾക്ക് പകരം, ഫാറ്റ് ക്ലയന്റ് മോഡ് ഉപയോഗിക്കുന്നു. അത്തരമൊരു നോഡ് ഡാറ്റ സംഭരിക്കുന്നില്ല, പക്ഷേ ഒരു അഭ്യർത്ഥന നിർവ്വഹണ കോർഡിനേറ്ററായി പ്രവർത്തിക്കാൻ കഴിയും, അതായത്, ക്ലയന്റ് തന്നെ അതിന്റെ അഭ്യർത്ഥനകളുടെ കോർഡിനേറ്ററായി പ്രവർത്തിക്കുന്നു: ഇത് സ്റ്റോറേജ് റെപ്ലിക്കുകൾ അന്വേഷിക്കുകയും വൈരുദ്ധ്യങ്ങൾ പരിഹരിക്കുകയും ചെയ്യുന്നു. ഇത് സ്റ്റാൻഡേർഡ് ഡ്രൈവറിനേക്കാൾ കൂടുതൽ വിശ്വസനീയവും വേഗതയേറിയതും മാത്രമല്ല, റിമോട്ട് കോർഡിനേറ്ററുമായി ആശയവിനിമയം ആവശ്യമാണ്, മാത്രമല്ല അഭ്യർത്ഥനകളുടെ സംപ്രേക്ഷണം നിയന്ത്രിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. ക്ലയന്റിൽ തുറന്ന ഒരു ഇടപാടിന് പുറത്ത്, റിപ്പോസിറ്ററികളിലേക്ക് അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു. ക്ലയന്റ് ഒരു ഇടപാട് തുറന്നിട്ടുണ്ടെങ്കിൽ, ഇടപാടിനുള്ളിലെ എല്ലാ അഭ്യർത്ഥനകളും ഇടപാട് കോർഡിനേറ്ററിന് അയയ്ക്കും.

സി*വൺ ട്രാൻസാക്ഷൻ കോർഡിനേറ്റർ

കോർഡിനേറ്റർ എന്നത് ഞങ്ങൾ ആദ്യം മുതൽ C* One-നായി നടപ്പിലാക്കിയ ഒന്നാണ്. ഇടപാടുകൾ, ലോക്കുകൾ, ഇടപാടുകൾ പ്രയോഗിക്കുന്ന ക്രമം എന്നിവ കൈകാര്യം ചെയ്യുന്നതിന് ഇത് ഉത്തരവാദിയാണ്.

ഓരോ സർവീസ് ഇടപാടിനും, കോർഡിനേറ്റർ ഒരു ടൈംസ്റ്റാമ്പ് സൃഷ്ടിക്കുന്നു: തുടർന്നുള്ള ഓരോ ഇടപാടും മുമ്പത്തെ ഇടപാടിനേക്കാൾ വലുതാണ്. കസാന്ദ്രയുടെ വൈരുദ്ധ്യ പരിഹാര സംവിധാനം ടൈംസ്റ്റാമ്പുകളെ അടിസ്ഥാനമാക്കിയുള്ളതിനാൽ (രണ്ട് വൈരുദ്ധ്യമുള്ള റെക്കോർഡുകളിൽ, ഏറ്റവും പുതിയ ടൈംസ്റ്റാമ്പ് ഉള്ളത് നിലവിലുള്ളതായി കണക്കാക്കപ്പെടുന്നു), തുടർന്നുള്ള ഇടപാടിന് അനുകൂലമായി വൈരുദ്ധ്യം എല്ലായ്പ്പോഴും പരിഹരിക്കപ്പെടും. അങ്ങനെ ഞങ്ങൾ നടപ്പിലാക്കി ലാംപോർട്ട് വാച്ച് - ഒരു വിതരണം ചെയ്ത സിസ്റ്റത്തിലെ വൈരുദ്ധ്യങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള വിലകുറഞ്ഞ മാർഗ്ഗം.

ലോക്കുകൾ

ഒറ്റപ്പെടൽ ഉറപ്പാക്കാൻ, ഏറ്റവും ലളിതമായ രീതി ഉപയോഗിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു - റെക്കോർഡിന്റെ പ്രാഥമിക കീയെ അടിസ്ഥാനമാക്കിയുള്ള അശുഭാപ്തി ലോക്കുകൾ. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ഒരു ഇടപാടിൽ, ഒരു റെക്കോർഡ് ആദ്യം ലോക്ക് ചെയ്യണം, അതിനുശേഷം മാത്രം വായിക്കുകയും പരിഷ്ക്കരിക്കുകയും സംരക്ഷിക്കുകയും വേണം. വിജയകരമായ പ്രതിബദ്ധതയ്ക്ക് ശേഷം മാത്രമേ ഒരു റെക്കോർഡ് അൺലോക്ക് ചെയ്യാൻ കഴിയൂ, അതുവഴി മത്സരിക്കുന്ന ഇടപാടുകൾക്ക് അത് ഉപയോഗിക്കാൻ കഴിയും.

വിതരണം ചെയ്യാത്ത അന്തരീക്ഷത്തിൽ അത്തരം ലോക്കിംഗ് നടപ്പിലാക്കുന്നത് ലളിതമാണ്. ഒരു വിതരണ സംവിധാനത്തിൽ, രണ്ട് പ്രധാന ഓപ്ഷനുകൾ ഉണ്ട്: ഒന്നുകിൽ ക്ലസ്റ്ററിൽ വിതരണം ചെയ്ത ലോക്കിംഗ് നടപ്പിലാക്കുക, അല്ലെങ്കിൽ ഇടപാടുകൾ വിതരണം ചെയ്യുക, അങ്ങനെ ഒരേ റെക്കോർഡ് ഉൾപ്പെടുന്ന ഇടപാടുകൾ എല്ലായ്പ്പോഴും ഒരേ കോർഡിനേറ്ററാണ് സേവനം ചെയ്യുന്നത്.

ഞങ്ങളുടെ കാര്യത്തിൽ, SQL-ലെ പ്രാദേശിക ഇടപാടുകളുടെ ഗ്രൂപ്പുകൾക്കിടയിൽ ഡാറ്റ ഇതിനകം വിതരണം ചെയ്തിരിക്കുന്നതിനാൽ, പ്രാദേശിക ഇടപാട് ഗ്രൂപ്പുകളെ കോർഡിനേറ്റർമാർക്ക് നിയോഗിക്കാൻ തീരുമാനിച്ചു: ഒരു കോർഡിനേറ്റർ എല്ലാ ഇടപാടുകളും 0 മുതൽ 9 വരെയുള്ള ടോക്കണുകൾ ഉപയോഗിച്ച് നടത്തുന്നു, രണ്ടാമത്തേത് - 10 മുതൽ 19 വരെയുള്ള ടോക്കണുകൾ, ഇത്യാദി. തൽഫലമായി, ഓരോ കോർഡിനേറ്റർ സംഭവങ്ങളും ഇടപാട് ഗ്രൂപ്പിന്റെ മാസ്റ്ററായി മാറുന്നു.

അപ്പോൾ കോർഡിനേറ്ററുടെ മെമ്മറിയിൽ ഒരു ബാനൽ ഹാഷ്മാപ്പ് രൂപത്തിൽ ലോക്കുകൾ നടപ്പിലാക്കാൻ കഴിയും.

കോർഡിനേറ്റർ പരാജയങ്ങൾ

ഒരു കോ-ഓർഡിനേറ്റർ ഒരു കൂട്ടം ഇടപാടുകൾക്ക് മാത്രമായി സേവനം ചെയ്യുന്നതിനാൽ, അതിന്റെ പരാജയത്തിന്റെ വസ്തുത വേഗത്തിൽ നിർണ്ണയിക്കേണ്ടത് വളരെ പ്രധാനമാണ്, അങ്ങനെ ഇടപാട് നടത്താനുള്ള രണ്ടാമത്തെ ശ്രമം കാലഹരണപ്പെടും. ഇത് വേഗതയേറിയതും വിശ്വസനീയവുമാക്കാൻ, ഞങ്ങൾ പൂർണ്ണമായി ബന്ധിപ്പിച്ച കോറം ഹിയർബീറ്റ് പ്രോട്ടോക്കോൾ ഉപയോഗിച്ചു:

ഓരോ ഡാറ്റാ സെന്ററും കുറഞ്ഞത് രണ്ട് കോർഡിനേറ്റർ നോഡുകൾ ഹോസ്റ്റുചെയ്യുന്നു. കാലാകാലങ്ങളിൽ, ഓരോ കോർഡിനേറ്ററും മറ്റ് കോർഡിനേറ്റർമാർക്ക് ഹൃദയമിടിപ്പ് സന്ദേശം അയയ്‌ക്കുകയും അതിന്റെ പ്രവർത്തനത്തെക്കുറിച്ചും കഴിഞ്ഞ തവണ ക്ലസ്റ്ററിലെ ഏത് കോ-ഓർഡിനേറ്റർമാരിൽ നിന്ന് ലഭിച്ച ഹൃദയമിടിപ്പ് സന്ദേശങ്ങളെക്കുറിച്ചും അവരെ അറിയിക്കുന്നു.

ഹൃദയമിടിപ്പിന്റെ സന്ദേശങ്ങളുടെ ഭാഗമായി മറ്റുള്ളവരിൽ നിന്ന് സമാനമായ വിവരങ്ങൾ സ്വീകരിക്കുന്നതിലൂടെ, ഓരോ കോ-ഓർഡിനേറ്ററും ഏതൊക്കെ ക്ലസ്റ്റർ നോഡുകൾ പ്രവർത്തിക്കുന്നുണ്ടെന്നും അല്ലാത്തത് എന്താണെന്നും കോറം തത്ത്വമനുസരിച്ച് നയിക്കപ്പെടുന്നു: നോഡ് എക്‌സിന് ക്ലസ്റ്ററിലെ ഭൂരിഭാഗം നോഡുകളിൽ നിന്നും സാധാരണയെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിച്ചിട്ടുണ്ടെങ്കിൽ നോഡ് Y-ൽ നിന്നുള്ള സന്ദേശങ്ങളുടെ രസീത്, തുടർന്ന് , Y പ്രവർത്തിക്കുന്നു. തിരിച്ചും, നോഡ് Y-ൽ നിന്ന് മിക്കവരും നഷ്‌ടമായ സന്ദേശങ്ങൾ റിപ്പോർട്ട് ചെയ്‌ത ഉടൻ, Y നിരസിച്ചു. കോറം നോഡ് എക്‌സിൽ നിന്ന് സന്ദേശങ്ങൾ സ്വീകരിക്കുന്നില്ലെന്ന് അറിയിച്ചാൽ, നോഡ് എക്‌സ് സ്വയം പരാജയപ്പെട്ടതായി കണക്കാക്കും എന്നത് കൗതുകകരമാണ്.

ഹൃദയമിടിപ്പ് സന്ദേശങ്ങൾ ഉയർന്ന ഫ്രീക്വൻസിയിൽ, സെക്കൻഡിൽ ഏകദേശം 20 തവണ, 50 എം.എസ്. ജാവയിൽ, ഗാർബേജ് കളക്ടർ മൂലമുണ്ടാകുന്ന താൽക്കാലിക വിരാമങ്ങളുടെ താരതമ്യ ദൈർഘ്യം കാരണം 50 എംഎസിനുള്ളിൽ ആപ്ലിക്കേഷൻ പ്രതികരണം ഉറപ്പുനൽകുന്നത് ബുദ്ധിമുട്ടാണ്. G1 ഗാർബേജ് കളക്ടർ ഉപയോഗിച്ച് ഞങ്ങൾക്ക് ഈ പ്രതികരണ സമയം നേടാൻ കഴിഞ്ഞു, ഇത് GC താൽക്കാലികമായി നിർത്തുന്ന സമയത്തേക്ക് ഒരു ടാർഗെറ്റ് വ്യക്തമാക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു. എന്നിരുന്നാലും, ചിലപ്പോൾ, വളരെ അപൂർവ്വമായി, കളക്ടർ താൽക്കാലികമായി നിർത്തുന്നു 50 ms കവിയുന്നു, ഇത് തെറ്റായ തകരാർ കണ്ടെത്തുന്നതിന് ഇടയാക്കും. ഇത് സംഭവിക്കുന്നത് തടയാൻ, ഒരു റിമോട്ട് നോഡിൽ നിന്നുള്ള ആദ്യത്തെ ഹൃദയമിടിപ്പ് സന്ദേശം അപ്രത്യക്ഷമാകുമ്പോൾ കോർഡിനേറ്റർ അതിന്റെ പരാജയം റിപ്പോർട്ട് ചെയ്യില്ല, തുടർച്ചയായി പലതും അപ്രത്യക്ഷമായാൽ മാത്രം. 200-ൽ കോർഡിനേറ്റർ നോഡിന്റെ പരാജയം കണ്ടെത്താൻ ഞങ്ങൾക്ക് കഴിഞ്ഞത് ഇങ്ങനെയാണ്. മിസ്.

എന്നാൽ ഏത് നോഡാണ് പ്രവർത്തനം നിർത്തിയതെന്ന് പെട്ടെന്ന് മനസ്സിലാക്കാൻ ഇത് പര്യാപ്തമല്ല. ഇക്കാര്യത്തിൽ നമ്മൾ എന്തെങ്കിലും ചെയ്യണം.

സംവരണം

ഒരു മാസ്റ്റർ പരാജയം സംഭവിച്ചാൽ, അതിലൊന്ന് ഉപയോഗിച്ച് ഒരു പുതിയ തിരഞ്ഞെടുപ്പ് ആരംഭിക്കുന്നത് ക്ലാസിക് സ്കീമിൽ ഉൾപ്പെടുന്നു ഫാഷനബിൾ സാർവത്രിക അൽഗോരിതങ്ങൾ. എന്നിരുന്നാലും, അത്തരം അൽഗോരിതങ്ങൾക്ക് സമയ സംയോജനത്തിലും തിരഞ്ഞെടുപ്പ് പ്രക്രിയയുടെ ദൈർഘ്യത്തിലും അറിയപ്പെടുന്ന പ്രശ്‌നങ്ങളുണ്ട്. പൂർണ്ണമായി ബന്ധിപ്പിച്ചിട്ടുള്ള നെറ്റ്‌വർക്കിൽ ഒരു കോർഡിനേറ്റർ മാറ്റിസ്ഥാപിക്കൽ സ്കീം ഉപയോഗിച്ച് അത്തരം അധിക കാലതാമസം ഒഴിവാക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു:

ഗ്രൂപ്പ് 50-ൽ ഒരു ഇടപാട് നടത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് പറയാം. റീപ്ലേസ്‌മെന്റ് സ്കീം മുൻകൂട്ടി നിശ്ചയിക്കാം, അതായത്, പ്രധാന കോ-ഓർഡിനേറ്റർ പരാജയപ്പെടുമ്പോൾ ഗ്രൂപ്പ് 50-ലെ ഇടപാടുകൾ ഏതൊക്കെ നോഡുകൾ നടപ്പിലാക്കും. ഒരു ഡാറ്റാ സെന്റർ പരാജയപ്പെടുമ്പോൾ സിസ്റ്റം പ്രവർത്തനക്ഷമത നിലനിർത്തുക എന്നതാണ് ഞങ്ങളുടെ ലക്ഷ്യം. ആദ്യത്തെ റിസർവ് മറ്റൊരു ഡാറ്റാ സെന്ററിൽ നിന്നുള്ള ഒരു നോഡായിരിക്കുമെന്നും രണ്ടാമത്തെ റിസർവ് മൂന്നാമത്തേതിൽ നിന്നുള്ള ഒരു നോഡായിരിക്കുമെന്നും നമുക്ക് നിർണ്ണയിക്കാം. ഈ സ്കീം ഒരിക്കൽ തിരഞ്ഞെടുത്തു, ക്ലസ്റ്ററിന്റെ ടോപ്പോളജി മാറുന്നതുവരെ, അതായത്, പുതിയ നോഡുകൾ അതിൽ പ്രവേശിക്കുന്നതുവരെ (ഇത് വളരെ അപൂർവമായി മാത്രമേ സംഭവിക്കൂ) മാറില്ല. പഴയത് പരാജയപ്പെടുകയാണെങ്കിൽ ഒരു പുതിയ സജീവ മാസ്റ്ററെ തിരഞ്ഞെടുക്കുന്നതിനുള്ള നടപടിക്രമം എല്ലായ്പ്പോഴും ഇനിപ്പറയുന്നതായിരിക്കും: ആദ്യത്തെ റിസർവ് സജീവ മാസ്റ്ററായി മാറും, അത് പ്രവർത്തനം നിർത്തിയാൽ, രണ്ടാമത്തെ റിസർവ് സജീവ മാസ്റ്ററായി മാറും.

ഈ സ്കീം സാർവത്രിക അൽഗോരിതത്തേക്കാൾ കൂടുതൽ വിശ്വസനീയമാണ്, കാരണം ഒരു പുതിയ മാസ്റ്റർ സജീവമാക്കുന്നതിന് പഴയതിന്റെ പരാജയം നിർണ്ണയിക്കാൻ ഇത് മതിയാകും.

എന്നാൽ ഇപ്പോൾ ഏത് മാസ്റ്റർ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ക്ലയന്റുകൾ എങ്ങനെ മനസ്സിലാക്കും? 50 ms-ൽ ആയിരക്കണക്കിന് ക്ലയന്റുകൾക്ക് വിവരങ്ങൾ അയയ്ക്കുന്നത് അസാധ്യമാണ്. ഒരു ഇടപാട് തുറക്കാൻ ഒരു ക്ലയന്റ് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുമ്പോൾ ഒരു സാഹചര്യം സാധ്യമാണ്, ഈ മാസ്റ്റർ ഇനി പ്രവർത്തിക്കുന്നില്ല എന്ന് ഇതുവരെ അറിയാതെ, അഭ്യർത്ഥന കാലഹരണപ്പെടും. ഇത് സംഭവിക്കുന്നത് തടയാൻ, ഗ്രൂപ്പ് മാസ്റ്ററിനും അദ്ദേഹത്തിന്റെ രണ്ട് കരുതൽ ധനത്തിനും ഒരേസമയം ഇടപാട് തുറക്കാൻ ക്ലയന്റുകൾ ഊഹക്കച്ചവടത്തിൽ ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്നു, എന്നാൽ ഇപ്പോൾ സജീവ മാസ്റ്ററായ ഒരാൾ മാത്രമേ ഈ അഭ്യർത്ഥനയോട് പ്രതികരിക്കൂ. ഇടപാടിനുള്ളിൽ തുടർന്നുള്ള എല്ലാ ആശയവിനിമയങ്ങളും സജീവ മാസ്റ്ററുമായി മാത്രമേ ക്ലയന്റ് നടത്തുകയുള്ളൂ.

തങ്ങളുടേതല്ലാത്ത ഇടപാടുകൾക്കായുള്ള അഭ്യർത്ഥനകൾ ബാക്കപ്പ് മാസ്റ്ററുകൾക്ക് ലഭിക്കുന്നു, അവ ജനിക്കാത്ത ഇടപാടുകളുടെ ക്യൂവിൽ, അവ കുറച്ച് സമയത്തേക്ക് സൂക്ഷിക്കുന്നു. സജീവ മാസ്റ്റർ മരിക്കുകയാണെങ്കിൽ, പുതിയ മാസ്റ്റർ അതിന്റെ ക്യൂവിൽ നിന്ന് ഇടപാടുകൾ തുറക്കാനുള്ള അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുകയും ക്ലയന്റിനോട് പ്രതികരിക്കുകയും ചെയ്യുന്നു. ക്ലയന്റ് ഇതിനകം പഴയ മാസ്റ്ററുമായി ഒരു ഇടപാട് തുറന്നിട്ടുണ്ടെങ്കിൽ, രണ്ടാമത്തെ പ്രതികരണം അവഗണിക്കപ്പെടും (കൂടാതെ, അത്തരമൊരു ഇടപാട് പൂർത്തിയാകില്ല, ക്ലയന്റ് ആവർത്തിക്കുകയും ചെയ്യും).

ഇടപാട് എങ്ങനെ പ്രവർത്തിക്കുന്നു

അത്തരം ഒരു പ്രാഥമിക കീ ഉപയോഗിച്ച് അത്തരമൊരു സ്ഥാപനത്തിനായി ഒരു ഇടപാട് തുറക്കാൻ ഒരു ക്ലയന്റ് കോ-ഓർഡിനേറ്റർക്ക് ഒരു അഭ്യർത്ഥന അയച്ചുവെന്ന് പറയാം. കോർഡിനേറ്റർ ഈ എന്റിറ്റി ലോക്ക് ചെയ്യുകയും മെമ്മറിയിൽ ലോക്ക് ടേബിളിൽ സ്ഥാപിക്കുകയും ചെയ്യുന്നു. ആവശ്യമെങ്കിൽ, കോർഡിനേറ്റർ ഈ എന്റിറ്റി സ്റ്റോറേജിൽ നിന്ന് വായിക്കുകയും തത്ഫലമായുണ്ടാകുന്ന ഡാറ്റ കോർഡിനേറ്ററുടെ മെമ്മറിയിൽ ഒരു ഇടപാട് അവസ്ഥയിൽ സംഭരിക്കുകയും ചെയ്യുന്നു.

ഒരു ഇടപാടിലെ ഡാറ്റ മാറ്റാൻ ഒരു ക്ലയന്റ് ആഗ്രഹിക്കുമ്പോൾ, അത് എന്റിറ്റിയിൽ മാറ്റം വരുത്താൻ കോർഡിനേറ്റർക്ക് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്നു, കൂടാതെ കോർഡിനേറ്റർ പുതിയ ഡാറ്റ ഇടപാട് സ്റ്റാറ്റസ് ടേബിളിൽ മെമ്മറിയിൽ സ്ഥാപിക്കുന്നു. ഇത് റെക്കോർഡിംഗ് പൂർത്തിയാക്കുന്നു - സ്‌റ്റോറേജിലേക്ക് ഒരു റെക്കോർഡിംഗും ഉണ്ടാക്കിയിട്ടില്ല.

ഒരു സജീവ ഇടപാടിന്റെ ഭാഗമായി ഒരു ക്ലയന്റ് സ്വന്തം മാറിയ ഡാറ്റ അഭ്യർത്ഥിക്കുമ്പോൾ, കോർഡിനേറ്റർ ഇനിപ്പറയുന്ന രീതിയിൽ പ്രവർത്തിക്കുന്നു:

• ഐഡി ഇതിനകം ഇടപാടിലാണെങ്കിൽ, ഡാറ്റ മെമ്മറിയിൽ നിന്ന് എടുത്തതാണ്;
• മെമ്മറിയിൽ ഐഡി ഇല്ലെങ്കിൽ, നഷ്ടപ്പെട്ട ഡാറ്റ സ്റ്റോറേജ് നോഡുകളിൽ നിന്ന് റീഡുചെയ്യുന്നു, ഇതിനകം മെമ്മറിയിലുള്ളവയുമായി സംയോജിപ്പിച്ച് ഫലം ക്ലയന്റിന് നൽകും.

അതിനാൽ, ക്ലയന്റിന് സ്വന്തം മാറ്റങ്ങൾ വായിക്കാൻ കഴിയും, എന്നാൽ മറ്റ് ക്ലയന്റുകൾ ഈ മാറ്റങ്ങൾ കാണുന്നില്ല, കാരണം അവ കോർഡിനേറ്ററുടെ മെമ്മറിയിൽ മാത്രം സംഭരിച്ചിരിക്കുന്നു; അവ ഇതുവരെ കസാന്ദ്ര നോഡുകളിൽ ഇല്ല.

ക്ലയന്റ് കമ്മിറ്റ് അയയ്‌ക്കുമ്പോൾ, സേവനത്തിന്റെ മെമ്മറിയിൽ ഉണ്ടായിരുന്ന അവസ്ഥ, ലോഗ് ചെയ്‌ത ബാച്ചിൽ കോ-ഓർഡിനേറ്റർ സംരക്ഷിക്കുകയും, ലോഗ് ചെയ്‌ത ബാച്ചായി കസാന്ദ്ര സ്‌റ്റോറേജിലേക്ക് അയയ്‌ക്കുകയും ചെയ്യുന്നു. ഈ പാക്കേജ് ആറ്റോമികമായി (പൂർണ്ണമായി) പ്രയോഗിച്ചിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ സ്റ്റോറുകൾ ആവശ്യമായതെല്ലാം ചെയ്യുന്നു, കൂടാതെ കോർഡിനേറ്ററിന് ഒരു പ്രതികരണം തിരികെ നൽകുന്നു, അവൻ ലോക്കുകൾ റിലീസ് ചെയ്യുകയും ഇടപാടിന്റെ വിജയം ക്ലയന്റിന് സ്ഥിരീകരിക്കുകയും ചെയ്യുന്നു.

റോൾബാക്ക് ചെയ്യുന്നതിന്, ഇടപാട് നിലയിലുള്ള മെമ്മറി മാത്രം കോർഡിനേറ്റർ സ്വതന്ത്രമാക്കേണ്ടതുണ്ട്.

മേൽപ്പറഞ്ഞ മെച്ചപ്പെടുത്തലുകളുടെ ഫലമായി, ഞങ്ങൾ ACID തത്വങ്ങൾ നടപ്പിലാക്കി:

• ആറ്റോമിസിറ്റി. സിസ്റ്റത്തിൽ ഒരു ഇടപാടും ഭാഗികമായി രേഖപ്പെടുത്തില്ല എന്നതിന്റെ ഗ്യാരണ്ടിയാണിത്; ഒന്നുകിൽ അതിന്റെ എല്ലാ ഉപപ്രവർത്തനങ്ങളും പൂർത്തിയാകും, അല്ലെങ്കിൽ ഒന്നും പൂർത്തിയാകില്ല. കസാന്ദ്രയിലെ ലോഗ്ഡ് ബാച്ചിലൂടെ ഞങ്ങൾ ഈ തത്വം പാലിക്കുന്നു.
• സ്ഥിരത. ഓരോ വിജയകരമായ ഇടപാടും, നിർവചനം അനുസരിച്ച്, സാധുവായ ഫലങ്ങൾ മാത്രമേ രേഖപ്പെടുത്തൂ. ഒരു ഇടപാട് തുറന്ന് പ്രവർത്തനങ്ങളുടെ ഒരു ഭാഗം പൂർത്തിയാക്കിയ ശേഷം, ഫലം അസാധുവാണെന്ന് കണ്ടെത്തിയാൽ, ഒരു റോൾബാക്ക് നടത്തുന്നു.
• ഐസൊലേഷൻ. ഒരു ഇടപാട് നടത്തുമ്പോൾ, ഒരേസമയം നടക്കുന്ന ഇടപാടുകൾ അതിന്റെ ഫലത്തെ ബാധിക്കരുത്. കോ-ഓർഡിനേറ്ററിലെ അശുഭാപ്തി ലോക്കുകൾ ഉപയോഗിച്ച് മത്സര ഇടപാടുകൾ ഒറ്റപ്പെടുത്തുന്നു. ഒരു ഇടപാടിന് പുറത്തുള്ള വായനകൾക്ക്, ഐസൊലേഷൻ തത്വം റീഡ് കമ്മിറ്റഡ് തലത്തിൽ നിരീക്ഷിക്കപ്പെടുന്നു.
• ശീലം. താഴ്ന്ന നിലയിലുള്ള പ്രശ്നങ്ങൾ പരിഗണിക്കാതെ തന്നെ-സിസ്റ്റം ബ്ലാക്ഔട്ട്, ഹാർഡ്‌വെയർ പരാജയം- വിജയകരമായി പൂർത്തിയാക്കിയ ഇടപാടിലൂടെ വരുത്തിയ മാറ്റങ്ങൾ പ്രവർത്തനങ്ങൾ പുനരാരംഭിക്കുമ്പോൾ സംരക്ഷിക്കപ്പെടേണ്ടതാണ്.

സൂചികകൾ പ്രകാരം വായന

നമുക്ക് ഒരു ലളിതമായ പട്ടിക എടുക്കാം:

CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)

ഇതിന് ഒരു ഐഡി (പ്രാഥമിക കീ), ഉടമ, പരിഷ്ക്കരണ തീയതി എന്നിവയുണ്ട്. നിങ്ങൾ വളരെ ലളിതമായ ഒരു അഭ്യർത്ഥന നടത്തേണ്ടതുണ്ട് - "അവസാന ദിവസത്തേക്കുള്ള" മാറ്റ തീയതി ഉപയോഗിച്ച് ഉടമയുടെ ഡാറ്റ തിരഞ്ഞെടുക്കുക.

SELECT *
WHERE owner=?
AND modified>?

അത്തരമൊരു ചോദ്യം വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യുന്നതിന്, ഒരു ക്ലാസിക് SQL DBMS-ൽ നിങ്ങൾ നിരകൾ (ഉടമ, പരിഷ്കരിച്ചത്) പ്രകാരം ഒരു സൂചിക നിർമ്മിക്കേണ്ടതുണ്ട്. ഞങ്ങൾക്ക് ഇത് വളരെ എളുപ്പത്തിൽ ചെയ്യാൻ കഴിയും, കാരണം ഞങ്ങൾക്ക് ഇപ്പോൾ ACID ഗ്യാരണ്ടിയുണ്ട്!

സി*വണ്ണിലെ സൂചികകൾ

ഫോട്ടോഗ്രാഫുകളുള്ള ഒരു ഉറവിട പട്ടികയുണ്ട്, അതിൽ റെക്കോർഡ് ഐഡി പ്രാഥമിക കീയാണ്.

ഒരു സൂചികയ്ക്കായി, സി*വൺ ഒരു പുതിയ പട്ടിക സൃഷ്ടിക്കുന്നു, അത് ഒറിജിനലിന്റെ പകർപ്പാണ്. കീ സൂചിക എക്‌സ്‌പ്രഷൻ പോലെ തന്നെയാണ്, കൂടാതെ ഉറവിട പട്ടികയിൽ നിന്നുള്ള റെക്കോർഡിന്റെ പ്രാഥമിക കീയും ഇതിൽ ഉൾപ്പെടുന്നു:

ഇപ്പോൾ "അവസാന ദിവസത്തെ ഉടമ" എന്നതിനായുള്ള അന്വേഷണം മറ്റൊരു പട്ടികയിൽ നിന്ന് തിരഞ്ഞെടുത്തതായി മാറ്റിയെഴുതാം:

SELECT * FROM i1_test
WHERE owner=?
AND modified>?

സോഴ്സ് ടേബിൾ ഫോട്ടോകളിലെയും ഇൻഡക്സ് ടേബിൾ i1 ലെയും ഡാറ്റയുടെ സ്ഥിരത കോഓർഡിനേറ്റർ സ്വയമേവ പരിപാലിക്കുന്നു. ഡാറ്റ സ്കീമയെ മാത്രം അടിസ്ഥാനമാക്കി, ഒരു മാറ്റം ലഭിക്കുമ്പോൾ, പ്രധാന പട്ടികയിൽ മാത്രമല്ല, പകർപ്പുകളിലും കോർഡിനേറ്റർ ഒരു മാറ്റം സൃഷ്ടിക്കുകയും സംഭരിക്കുകയും ചെയ്യുന്നു. ഇൻഡെക്സ് ടേബിളിൽ അധിക പ്രവർത്തനങ്ങളൊന്നും നടത്തുന്നില്ല, ലോഗുകൾ വായിക്കുന്നില്ല, ലോക്കുകൾ ഉപയോഗിക്കുന്നില്ല. അതായത്, സൂചികകൾ ചേർക്കുന്നത് മിക്കവാറും വിഭവങ്ങളൊന്നും ഉപയോഗിക്കുന്നില്ല, മാത്രമല്ല പരിഷ്ക്കരണങ്ങൾ പ്രയോഗിക്കുന്നതിന്റെ വേഗതയെ ഫലത്തിൽ ബാധിക്കില്ല.

ACID ഉപയോഗിച്ച്, SQL പോലുള്ള സൂചികകൾ നടപ്പിലാക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു. അവ സ്ഥിരതയുള്ളതും അളക്കാവുന്നതും വേഗതയുള്ളതും കമ്പോസബിൾ ആയതും CQL അന്വേഷണ ഭാഷയിൽ നിർമ്മിച്ചതുമാണ്. സൂചികകളെ പിന്തുണയ്ക്കുന്നതിന് ആപ്ലിക്കേഷൻ കോഡിൽ മാറ്റങ്ങളൊന്നും ആവശ്യമില്ല. എല്ലാം SQL പോലെ ലളിതമാണ്. ഏറ്റവും പ്രധാനമായി, ഇൻഡെക്സുകൾ യഥാർത്ഥ ഇടപാട് പട്ടികയിലെ പരിഷ്ക്കരണങ്ങളുടെ നിർവ്വഹണ വേഗതയെ ബാധിക്കില്ല.

എന്ത് സംഭവിച്ചു

ഞങ്ങൾ മൂന്ന് വർഷം മുമ്പ് സി* വൺ വികസിപ്പിച്ച് വാണിജ്യ പ്രവർത്തനത്തിലേക്ക് ആരംഭിച്ചു.

അവസാനം നമുക്ക് എന്താണ് ലഭിച്ചത്? ഒരു സോഷ്യൽ നെറ്റ്‌വർക്കിലെ ഏറ്റവും പ്രധാനപ്പെട്ട തരത്തിലുള്ള ഡാറ്റകളിലൊന്നായ ഫോട്ടോ പ്രോസസ്സിംഗ്, സ്റ്റോറേജ് സബ്സിസ്റ്റം എന്നിവയുടെ ഉദാഹരണം ഉപയോഗിച്ച് നമുക്ക് ഇത് വിലയിരുത്താം. നമ്മൾ സംസാരിക്കുന്നത് ഫോട്ടോഗ്രാഫുകളുടെ ശരീരത്തെക്കുറിച്ചല്ല, മറിച്ച് എല്ലാത്തരം മെറ്റാ വിവരങ്ങളെക്കുറിച്ചുമാണ്. ഇപ്പോൾ Odnoklassniki ന് അത്തരം 20 ബില്ല്യൺ റെക്കോർഡുകൾ ഉണ്ട്, സിസ്റ്റം സെക്കൻഡിൽ 80 ആയിരം റീഡ് അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നു, ഡാറ്റ പരിഷ്കരണവുമായി ബന്ധപ്പെട്ട സെക്കൻഡിൽ 8 ആയിരം ACID ഇടപാടുകൾ വരെ.

ഞങ്ങൾ റെപ്ലിക്കേഷൻ ഫാക്ടർ = 1 ഉപയോഗിച്ച് SQL ഉപയോഗിക്കുമ്പോൾ (എന്നാൽ RAID 10 ൽ), മൈക്രോസോഫ്റ്റ് SQL സെർവർ (കൂടാതെ 32 ബാക്കപ്പുകൾ) പ്രവർത്തിക്കുന്ന 11 മെഷീനുകളുടെ വളരെ ലഭ്യമായ ക്ലസ്റ്ററിലാണ് ഫോട്ടോ മെറ്റൈൻഫോർമേഷൻ സംഭരിച്ചത്. ബാക്കപ്പുകൾ സൂക്ഷിക്കാൻ 10 സെർവറുകളും അനുവദിച്ചു. ആകെ 50 വിലകൂടിയ കാറുകൾ. അതേ സമയം, റിസർവ് ഇല്ലാതെ, റേറ്റുചെയ്ത ലോഡിൽ സിസ്റ്റം പ്രവർത്തിച്ചു.

പുതിയ സിസ്റ്റത്തിലേക്ക് മൈഗ്രേറ്റ് ചെയ്‌തതിന് ശേഷം, ഞങ്ങൾക്ക് റെപ്ലിക്കേഷൻ ഫാക്ടർ = 3 - ഓരോ ഡാറ്റാ സെന്ററിലും ഒരു പകർപ്പ് ലഭിച്ചു. സിസ്റ്റത്തിൽ 63 കസാന്ദ്ര സ്റ്റോറേജ് നോഡുകളും 6 കോർഡിനേറ്റർ മെഷീനുകളും ഉൾപ്പെടുന്നു, ആകെ 69 സെർവറുകൾ. എന്നാൽ ഈ മെഷീനുകൾ വളരെ വിലകുറഞ്ഞതാണ്, അവയുടെ ആകെ ചെലവ് ഒരു SQL സിസ്റ്റത്തിന്റെ വിലയുടെ ഏകദേശം 30% ആണ്. അതേ സമയം, ലോഡ് 30% ആയി സൂക്ഷിക്കുന്നു.

C*Oൺ അവതരിപ്പിച്ചതോടെ, ലേറ്റൻസിയും കുറഞ്ഞു: SQL-ൽ, ഒരു റൈറ്റ് ഓപ്പറേഷൻ ഏകദേശം 4,5 ms എടുത്തു. C* One-ൽ - ഏകദേശം 1,6 ms. ഇടപാട് ദൈർഘ്യം ശരാശരി 40 ms-ൽ താഴെയാണ്, പ്രതിബദ്ധത 2 ms-ൽ പൂർത്തിയാകും, വായിക്കാനും എഴുതാനുമുള്ള ദൈർഘ്യം ശരാശരി 2 ms ആണ്. 99-ാമത്തെ പെർസെൻറ്റൈൽ - 3-3,1 എംഎസ് മാത്രം, ടൈംഔട്ടുകളുടെ എണ്ണം 100 മടങ്ങ് കുറഞ്ഞു - എല്ലാം ഊഹക്കച്ചവടത്തിന്റെ വ്യാപകമായ ഉപയോഗം കാരണം.

ഇപ്പോൾ, മിക്ക SQL സെർവർ നോഡുകളും ഡീകമ്മീഷൻ ചെയ്തു; പുതിയ ഉൽപ്പന്നങ്ങൾ C*Oൺ ഉപയോഗിച്ച് മാത്രം വികസിപ്പിക്കുന്നു. ഞങ്ങളുടെ ക്ലൗഡിൽ പ്രവർത്തിക്കാൻ ഞങ്ങൾ സി*വൺ സ്വീകരിച്ചു ഒരു മേഘം, ഇത് പുതിയ ക്ലസ്റ്ററുകളുടെ വിന്യാസം വേഗത്തിലാക്കാനും കോൺഫിഗറേഷൻ ലളിതമാക്കാനും പ്രവർത്തനം ഓട്ടോമേറ്റ് ചെയ്യാനും സാധ്യമാക്കി. സോഴ്സ് കോഡ് ഇല്ലാതെ, ഇത് ചെയ്യുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടുള്ളതും ബുദ്ധിമുട്ടുള്ളതുമായിരിക്കും.

ഇപ്പോൾ ഞങ്ങൾ ഞങ്ങളുടെ മറ്റ് സ്റ്റോറേജ് സൗകര്യങ്ങൾ ക്ലൗഡിലേക്ക് മാറ്റാനുള്ള ശ്രമത്തിലാണ് - എന്നാൽ ഇത് തികച്ചും വ്യത്യസ്തമായ കഥയാണ്.

അവലംബം: www.habr.com