സെർവർലെസ്സ് ഡാറ്റാബേസുകളിലേക്കുള്ള വഴിയിൽ - എങ്ങനെ, എന്തുകൊണ്ട്

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് ഗോലോവ് നിക്കോളായ്. മുമ്പ്, ഞാൻ Avito-യിൽ ജോലി ചെയ്യുകയും ആറ് വർഷത്തേക്ക് ഡാറ്റ പ്ലാറ്റ്ഫോം കൈകാര്യം ചെയ്യുകയും ചെയ്തു, അതായത്, ഞാൻ എല്ലാ ഡാറ്റാബേസുകളിലും പ്രവർത്തിച്ചു: അനലിറ്റിക്കൽ (Vertica, ClickHouse), സ്ട്രീമിംഗ്, OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). ഈ സമയത്ത്, ഞാൻ ധാരാളം ഡാറ്റാബേസുകൾ കൈകാര്യം ചെയ്തു - വളരെ വ്യത്യസ്തവും അസാധാരണവും അവയുടെ ഉപയോഗത്തിന്റെ നിലവാരമില്ലാത്ത കേസുകളും.

ഞാൻ ഇപ്പോൾ ManyChat-ൽ ജോലി ചെയ്യുന്നു. സാരാംശത്തിൽ, ഇതൊരു സ്റ്റാർട്ടപ്പ് ആണ് - പുതിയതും അതിമോഹവും അതിവേഗം വളരുന്നതും. ഞാൻ ആദ്യമായി കമ്പനിയിൽ ചേർന്നപ്പോൾ, ഒരു ക്ലാസിക് ചോദ്യം ഉയർന്നു: "ഒരു യുവ സ്റ്റാർട്ടപ്പ് ഇപ്പോൾ DBMS-ൽ നിന്നും ഡാറ്റാബേസ് മാർക്കറ്റിൽ നിന്നും എന്താണ് എടുക്കേണ്ടത്?"

ഈ ലേഖനത്തിൽ, എന്റെ റിപ്പോർട്ടിനെ അടിസ്ഥാനമാക്കി ഓൺലൈൻ ഉത്സവം RIT++2020, ഞാൻ ഈ ചോദ്യത്തിന് ഉത്തരം നൽകും. റിപ്പോർട്ടിന്റെ വീഡിയോ പതിപ്പ് ഇവിടെ ലഭ്യമാണ് YouTube.

സാധാരണയായി അറിയപ്പെടുന്ന ഡാറ്റാബേസുകൾ 2020

ഇത് 2020 ആണ്, ഞാൻ ചുറ്റും നോക്കി മൂന്ന് തരം ഡാറ്റാബേസുകൾ കണ്ടു.

ആദ്യ തരം - ക്ലാസിക് OLTP ഡാറ്റാബേസുകൾ: PostgreSQL, SQL സെർവർ, ഒറാക്കിൾ, MySQL. അവ വളരെക്കാലം മുമ്പ് എഴുതിയതാണ്, പക്ഷേ അവ ഇപ്പോഴും പ്രസക്തമാണ്, കാരണം അവ ഡെവലപ്പർ കമ്മ്യൂണിറ്റിക്ക് വളരെ പരിചിതമാണ്.

രണ്ടാം തരം - "പൂജ്യം" മുതൽ അടിസ്ഥാനങ്ങൾ. ബിൽറ്റ്-ഇൻ ഷാർഡിംഗും മറ്റ് ആകർഷകമായ സവിശേഷതകളും ചേർത്ത്, SQL, പരമ്പരാഗത ഘടനകൾ, ACID എന്നിവ ഉപേക്ഷിച്ച് അവർ ക്ലാസിക് പാറ്റേണുകളിൽ നിന്ന് മാറാൻ ശ്രമിച്ചു. ഉദാഹരണത്തിന്, ഇതാണ് കസാന്ദ്ര, മോംഗോഡിബി, റെഡിസ് അല്ലെങ്കിൽ ടാരന്റൂൾ. ഈ പരിഹാരങ്ങളെല്ലാം വിപണിയിൽ അടിസ്ഥാനപരമായി പുതിയ എന്തെങ്കിലും നൽകാൻ ആഗ്രഹിച്ചു, ചില ജോലികൾക്ക് അവ വളരെ സൗകര്യപ്രദമായി മാറിയതിനാൽ അവയുടെ സ്ഥാനം കൈവശപ്പെടുത്തി. ഈ ഡാറ്റാബേസുകളെ ഞാൻ NOSQL എന്ന കുട എന്ന പദം ഉപയോഗിച്ച് സൂചിപ്പിക്കും.

“പൂജ്യം” അവസാനിച്ചു, ഞങ്ങൾ NOSQL ഡാറ്റാബേസുകളുമായി പരിചയപ്പെട്ടു, എന്റെ കാഴ്ചപ്പാടിൽ ലോകം അടുത്ത ഘട്ടം സ്വീകരിച്ചു - നിയന്ത്രിത ഡാറ്റാബേസുകൾ. ഈ ഡാറ്റാബേസുകൾക്ക് ക്ലാസിക് OLTP ഡാറ്റാബേസുകളോ പുതിയ NoSQL യോ ഉള്ള അതേ കോർ ഉണ്ട്. എന്നാൽ അവർക്ക് DBA, DevOps എന്നിവയുടെ ആവശ്യമില്ല, കൂടാതെ ക്ലൗഡുകളിൽ മാനേജ് ചെയ്ത ഹാർഡ്‌വെയറിൽ പ്രവർത്തിക്കുന്നു. ഒരു ഡവലപ്പറെ സംബന്ധിച്ചിടത്തോളം, ഇത് എവിടെയോ പ്രവർത്തിക്കുന്ന "ഒരു അടിസ്ഥാനം" ആണ്, എന്നാൽ ഇത് സെർവറിൽ എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യപ്പെടുന്നു, ആരാണ് സെർവർ കോൺഫിഗർ ചെയ്‌തത്, ആരാണ് അത് അപ്‌ഡേറ്റ് ചെയ്യുന്നത് എന്നിവ ആരും ശ്രദ്ധിക്കുന്നില്ല.

അത്തരം ഡാറ്റാബേസുകളുടെ ഉദാഹരണങ്ങൾ:

• AWS RDS എന്നത് PostgreSQL/MySQL-നുള്ള ഒരു നിയന്ത്രിത റാപ്പറാണ്.
• Redis, MongoDB എന്നിവയ്ക്ക് സമാനമായ ഒരു ഡോക്യുമെന്റ് അടിസ്ഥാനമാക്കിയുള്ള ഡാറ്റാബേസിന്റെ AWS അനലോഗ് ആണ് DynamoDB.
• നിയന്ത്രിത അനലിറ്റിക്കൽ ഡാറ്റാബേസാണ് ആമസോൺ റെഡ്ഷിഫ്റ്റ്.

ഇവ അടിസ്ഥാനപരമായി പഴയ ഡാറ്റാബേസുകളാണ്, എന്നാൽ ഹാർഡ്‌വെയറുമായി പ്രവർത്തിക്കേണ്ട ആവശ്യമില്ലാതെ, നിയന്ത്രിത പരിതസ്ഥിതിയിൽ വളർന്നു.

കുറിപ്പ്. ഉദാഹരണങ്ങൾ AWS പരിതസ്ഥിതിക്ക് വേണ്ടി എടുത്തതാണ്, എന്നാൽ അവയുടെ അനലോഗുകൾ Microsoft Azure, Google Cloud, അല്ലെങ്കിൽ Yandex.Cloud എന്നിവയിലും നിലവിലുണ്ട്.

ഇതിൽ എന്താണ് പുതിയത്? 2020-ൽ ഇതൊന്നും ഇല്ല.

സെർവർലെസ് ആശയം

2020-ൽ വിപണിയിൽ ശരിക്കും പുതിയത് സെർവർലെസ് അല്ലെങ്കിൽ സെർവർലെസ് സൊല്യൂഷനുകളാണ്.

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

വേറെ എന്തെങ്കിലും വഴിയുണ്ടോ? സെർവർലെസ് സേവനങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് കഴിയും.

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

ഈ സമീപനം ചിത്രങ്ങളിലൂടെ വിശദീകരിക്കാൻ ഞാൻ ശ്രമിക്കും.


ക്ലാസിക് വിന്യാസം. ഞങ്ങൾക്ക് ഒരു നിശ്ചിത ലോഡുള്ള ഒരു സേവനം ഉണ്ട്. ഞങ്ങൾ രണ്ട് ഉദാഹരണങ്ങൾ ഉയർത്തുന്നു: ഫിസിക്കൽ സെർവറുകൾ അല്ലെങ്കിൽ AWS-ലെ സന്ദർഭങ്ങൾ. ഈ സന്ദർഭങ്ങളിലേക്ക് ബാഹ്യ അഭ്യർത്ഥനകൾ അയയ്ക്കുകയും അവിടെ പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു.

നിങ്ങൾക്ക് ചിത്രത്തിൽ കാണാൻ കഴിയുന്നതുപോലെ, സെർവറുകൾ തുല്യമായി നീക്കം ചെയ്യപ്പെടുന്നില്ല. ഒന്ന് 100% ഉപയോഗിച്ചു, രണ്ട് അഭ്യർത്ഥനകളുണ്ട്, ഒന്ന് 50% മാത്രം - ഭാഗികമായി നിഷ്‌ക്രിയമാണ്. മൂന്ന് അഭ്യർത്ഥനകൾ വന്നില്ലെങ്കിലും 30 ആണെങ്കിൽ, മുഴുവൻ സിസ്റ്റത്തിനും ലോഡിനെ നേരിടാൻ കഴിയില്ല, മാത്രമല്ല വേഗത കുറയ്ക്കാൻ തുടങ്ങുകയും ചെയ്യും.

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

ഒരു അഭ്യർത്ഥന - ഒരു കണ്ടെയ്നർ ഉയർത്തി, 1000 അഭ്യർത്ഥനകൾ - 1000 കണ്ടെയ്നറുകൾ. ഹാർഡ്‌വെയർ സെർവറുകളിലെ വിന്യാസം ഇതിനകം തന്നെ ക്ലൗഡ് ദാതാവിന്റെ പ്രവർത്തനമാണ്. ഇത് സെർവർലെസ് ചട്ടക്കൂടിനാൽ പൂർണ്ണമായും മറച്ചിരിക്കുന്നു. ഈ ആശയത്തിൽ ഞങ്ങൾ ഓരോ കോളിനും പണം നൽകുന്നു. ഉദാഹരണത്തിന്, ഒരു ദിവസം ഒരു കോൾ വന്നു - ഞങ്ങൾ ഒരു കോളിന് പണം നൽകി, മിനിറ്റിന് ഒരു ദശലക്ഷം വന്നു - ഞങ്ങൾ ഒരു ദശലക്ഷത്തിന് പണം നൽകി. അല്ലെങ്കിൽ ഒരു നിമിഷം, ഇതും സംഭവിക്കുന്നു.

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

ഈ ഡാറ്റാബേസുകളുടെ പൊതുവായ പരിമിതി എന്താണ്? സ്ഥിരമായി ഉപയോഗിക്കുന്ന ക്ലൗഡ് അല്ലെങ്കിൽ ഹാർഡ്‌വെയർ സെർവറിന്റെ (അല്ലെങ്കിൽ നിരവധി സെർവറുകൾ) ചിലവുകളാണിത്. ഞങ്ങൾ ഒരു ക്ലാസിക് അല്ലെങ്കിൽ നിയന്ത്രിത ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നുണ്ടോ, ഞങ്ങൾക്ക് Devops ഉം ഒരു അഡ്മിനും ഉണ്ടോ ഇല്ലയോ എന്നത് പ്രശ്നമല്ല, ഞങ്ങൾ ഇപ്പോഴും ഹാർഡ്‌വെയർ, വൈദ്യുതി, ഡാറ്റാ സെന്റർ വാടകയ്ക്ക് 24/7 പണം നൽകുന്നു. ഞങ്ങൾക്ക് ഒരു ക്ലാസിക് അടിത്തറയുണ്ടെങ്കിൽ, യജമാനനും അടിമയ്ക്കും ഞങ്ങൾ പണം നൽകുന്നു. ഇത് വളരെ ലോഡുചെയ്‌ത ഷാർഡ് ഡാറ്റാബേസ് ആണെങ്കിൽ, ഞങ്ങൾ 10, 20 അല്ലെങ്കിൽ 30 സെർവറുകൾക്ക് പണം നൽകുന്നു, ഞങ്ങൾ നിരന്തരം പണമടയ്ക്കുന്നു.

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

സെർവർലെസ്സ് ഡാറ്റാബേസ് - സിദ്ധാന്തം

2020-ലെ ചോദ്യം: ഒരു ഡാറ്റാബേസ് സെർവർരഹിതമാക്കാനും കഴിയുമോ? സെർവർലെസ് ബാക്കെൻഡിനെക്കുറിച്ച് എല്ലാവരും കേട്ടിട്ടുണ്ട്... ഡാറ്റാബേസ് സെർവർരഹിതമാക്കാൻ ശ്രമിക്കാം?

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

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

അതനുസരിച്ച്, ആശയം ഇതാണ്: യുക്തിയുടെ ഒരു ഭാഗം സ്‌റ്റേറ്റ്‌ലെസ് എക്‌സിക്യൂഷൻ അനുവദിക്കുകയാണെങ്കിൽ, എന്തുകൊണ്ട് അടിസ്ഥാനത്തെ സ്‌റ്റേറ്റ്‌ഫുൾ, സ്‌റ്റേറ്റ്‌ലെസ് ഭാഗങ്ങളായി വിഭജിച്ചുകൂടാ.

OLAP പരിഹാരങ്ങൾക്കായി സെർവർലെസ്സ്

പ്രായോഗിക ഉദാഹരണങ്ങൾ ഉപയോഗിച്ച് ഒരു ഡാറ്റാബേസ് സ്റ്റേറ്റ്ഫുൾ, സ്റ്റേറ്റ്ലെസ് ഭാഗങ്ങളായി മുറിക്കുന്നത് എങ്ങനെയെന്ന് നോക്കാം.

ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് ഒരു വിശകലന ഡാറ്റാബേസ് ഉണ്ട്: ബാഹ്യ ഡാറ്റ (ഇടതുവശത്ത് ചുവന്ന സിലിണ്ടർ), ഡാറ്റാബേസിലേക്ക് ഡാറ്റ ലോഡ് ചെയ്യുന്ന ഒരു ETL പ്രക്രിയ, ഡാറ്റാബേസിലേക്ക് SQL അന്വേഷണങ്ങൾ അയയ്ക്കുന്ന ഒരു അനലിസ്റ്റ്. ഇതൊരു ക്ലാസിക് ഡാറ്റ വെയർഹൗസ് ഓപ്പറേഷൻ സ്കീമാണ്.

ഈ സ്കീമിൽ, ETL ഒരു തവണ സോപാധികമായി നടപ്പിലാക്കുന്നു. ETL നിറച്ച ഡാറ്റ ഉപയോഗിച്ച് ഡാറ്റാബേസ് പ്രവർത്തിക്കുന്ന സെർവറുകൾക്കായി നിങ്ങൾ നിരന്തരം പണം നൽകേണ്ടതുണ്ട്, അതുവഴി ചോദ്യങ്ങൾ അയയ്‌ക്കാൻ എന്തെങ്കിലും ഉണ്ട്.

AWS Athena Serverless-ൽ നടപ്പിലാക്കിയ ഒരു ബദൽ സമീപനം നോക്കാം. ഡൗൺലോഡ് ചെയ്‌ത ഡാറ്റ സംഭരിക്കുന്ന സ്ഥിരമായി സമർപ്പിത ഹാർഡ്‌വെയർ ഒന്നുമില്ല. ഇതിന് പകരം:

• ഉപയോക്താവ് അഥീനയ്ക്ക് ഒരു SQL അന്വേഷണം സമർപ്പിക്കുന്നു. അഥീന ഒപ്റ്റിമൈസർ SQL ചോദ്യം വിശകലനം ചെയ്യുകയും ചോദ്യം എക്സിക്യൂട്ട് ചെയ്യുന്നതിന് ആവശ്യമായ നിർദ്ദിഷ്ട ഡാറ്റയ്ക്കായി മെറ്റാഡാറ്റ സ്റ്റോറിൽ (മെറ്റാഡാറ്റ) തിരയുകയും ചെയ്യുന്നു.
• ഒപ്റ്റിമൈസർ, ശേഖരിച്ച ഡാറ്റയെ അടിസ്ഥാനമാക്കി, ബാഹ്യ ഉറവിടങ്ങളിൽ നിന്ന് ആവശ്യമായ ഡാറ്റ താൽക്കാലിക സംഭരണത്തിലേക്ക് (താൽക്കാലിക ഡാറ്റാബേസ്) ഡൗൺലോഡ് ചെയ്യുന്നു.
• ഉപയോക്താവിൽ നിന്നുള്ള ഒരു SQL ചോദ്യം താൽക്കാലിക സംഭരണത്തിൽ എക്സിക്യൂട്ട് ചെയ്യുകയും ഫലം ഉപയോക്താവിന് തിരികെ നൽകുകയും ചെയ്യുന്നു.
• താൽക്കാലിക സംഭരണം മായ്‌ക്കുകയും ഉറവിടങ്ങൾ റിലീസ് ചെയ്യുകയും ചെയ്യുന്നു.

ഈ വാസ്തുവിദ്യയിൽ, അഭ്യർത്ഥന നടപ്പിലാക്കുന്നതിനുള്ള പ്രക്രിയയ്ക്ക് മാത്രമേ ഞങ്ങൾ പണം നൽകൂ. അഭ്യർത്ഥനകളില്ല - ചെലവുകളില്ല.

ഇത് ഒരു പ്രവർത്തന സമീപനമാണ്, അഥീന സെർവർലെസിൽ മാത്രമല്ല, റെഡ്ഷിഫ്റ്റ് സ്പെക്ട്രത്തിലും (AWS-ൽ) ഇത് നടപ്പിലാക്കുന്നു.

പതിനായിരക്കണക്കിന് ടെറാബൈറ്റ് ഡാറ്റയുള്ള യഥാർത്ഥ അന്വേഷണങ്ങളിൽ സെർവർലെസ്സ് ഡാറ്റാബേസ് പ്രവർത്തിക്കുന്നുവെന്ന് അഥീന ഉദാഹരണം കാണിക്കുന്നു. നൂറുകണക്കിന് ടെറാബൈറ്റുകൾക്ക് നൂറുകണക്കിന് സെർവറുകൾ ആവശ്യമായി വരും, എന്നാൽ അവയ്‌ക്കായി ഞങ്ങൾ പണം നൽകേണ്ടതില്ല - അഭ്യർത്ഥനകൾക്ക് ഞങ്ങൾ പണം നൽകുന്നു. വെർട്ടിക്ക പോലുള്ള പ്രത്യേക അനലിറ്റിക്കൽ ഡാറ്റാബേസുകളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഓരോ അഭ്യർത്ഥനയുടെയും വേഗത (വളരെ) കുറവാണ്, എന്നാൽ പ്രവർത്തനരഹിതമായ കാലയളവുകൾക്ക് ഞങ്ങൾ പണം നൽകുന്നില്ല.

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

OLTP സൊല്യൂഷനുകൾക്കായി സെർവർലെസ്സ്

മുമ്പത്തെ ഉദാഹരണം OLAP (അനലിറ്റിക്കൽ) ടാസ്‌ക്കുകൾ പരിശോധിച്ചു. ഇനി OLTP ടാസ്‌ക്കുകൾ നോക്കാം.

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

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

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

പ്രവർത്തിക്കുന്ന ഈ അറോറ കപ്പാസിറ്റി യൂണിറ്റുകളുടെ എണ്ണം ക്രമീകരിക്കാവുന്ന പരാമീറ്ററാണ്. കുറഞ്ഞ അളവ് ഒന്നോ പൂജ്യമോ ആകാം (ഈ സാഹചര്യത്തിൽ, അഭ്യർത്ഥനകളില്ലെങ്കിൽ ഡാറ്റാബേസ് പ്രവർത്തിക്കില്ല).

ബേസിന് അഭ്യർത്ഥനകൾ ലഭിക്കുമ്പോൾ, പ്രോക്സി ഫ്ലീറ്റ് അറോറ കപ്പാസിറ്റി യൂണിറ്റുകൾ ഉയർത്തുന്നു, ഇത് സിസ്റ്റത്തിന്റെ പ്രകടന ഉറവിടങ്ങൾ വർദ്ധിപ്പിക്കുന്നു. ഉറവിടങ്ങൾ കൂട്ടാനും കുറയ്ക്കാനുമുള്ള കഴിവ് സിസ്റ്റത്തെ റിസോഴ്‌സുകളെ "ജഗ്ഗിൽ" ​​ചെയ്യാൻ അനുവദിക്കുന്നു: വ്യക്തിഗത ACU-കൾ സ്വയമേവ പ്രദർശിപ്പിക്കുക (അവയെ പുതിയവ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുക) കൂടാതെ പിൻവലിക്കപ്പെട്ട ഉറവിടങ്ങളിലേക്ക് നിലവിലുള്ള എല്ലാ അപ്‌ഡേറ്റുകളും റോൾ ഔട്ട് ചെയ്യുക.

അറോറ സെർവർലെസ് ബേസിന് റീഡിംഗ് ലോഡ് സ്കെയിൽ ചെയ്യാൻ കഴിയും. എന്നാൽ ഡോക്യുമെന്റേഷനിൽ ഇത് നേരിട്ട് പറയുന്നില്ല. അവർക്ക് ഒരു മൾട്ടി-മാസ്റ്ററെ ഉയർത്താൻ കഴിയുമെന്ന് തോന്നിയേക്കാം. മാന്ത്രികതയില്ല.

പ്രവചനാതീതമായ ആക്‌സസ് ഉള്ള സിസ്റ്റങ്ങളിൽ വലിയ തുക ചെലവഴിക്കുന്നത് ഒഴിവാക്കാൻ ഈ ഡാറ്റാബേസ് അനുയോജ്യമാണ്. ഉദാഹരണത്തിന്, MVP സൃഷ്ടിക്കുമ്പോഴോ ബിസിനസ് കാർഡ് സൈറ്റുകൾ വിപണനം ചെയ്യുമ്പോഴോ, സ്ഥിരമായ ഒരു ലോഡ് ഞങ്ങൾ സാധാരണയായി പ്രതീക്ഷിക്കുന്നില്ല. അതനുസരിച്ച്, ആക്സസ് ഇല്ലെങ്കിൽ, ഞങ്ങൾ ഉദാഹരണങ്ങൾക്ക് പണം നൽകുന്നില്ല. അപ്രതീക്ഷിത ലോഡ് സംഭവിക്കുമ്പോൾ, ഉദാഹരണത്തിന് ഒരു കോൺഫറൻസ് അല്ലെങ്കിൽ പരസ്യ കാമ്പെയ്‌നിന് ശേഷം, ആൾക്കൂട്ടം സൈറ്റ് സന്ദർശിക്കുകയും ലോഡ് ഗണ്യമായി വർദ്ധിക്കുകയും ചെയ്യുന്നു, Aurora Serverless ഈ ലോഡ് സ്വയമേവ എടുത്ത് നഷ്‌ടമായ ഉറവിടങ്ങളെ (ACU) വേഗത്തിൽ ബന്ധിപ്പിക്കുന്നു. തുടർന്ന് കോൺഫറൻസ് കടന്നുപോകുന്നു, എല്ലാവരും പ്രോട്ടോടൈപ്പിനെക്കുറിച്ച് മറക്കുന്നു, സെർവറുകൾ (ACU) ഇരുണ്ടുപോകുന്നു, ചെലവ് പൂജ്യമായി കുറയുന്നു - സൗകര്യപ്രദമാണ്.

ഈ പരിഹാരം സ്ഥിരതയുള്ള ഹൈലോഡിന് അനുയോജ്യമല്ല, കാരണം ഇത് എഴുത്ത് ലോഡ് സ്കെയിൽ ചെയ്യുന്നില്ല. ഈ എല്ലാ കണക്ഷനുകളും വിഭവങ്ങളുടെ വിച്ഛേദനങ്ങളും സംഭവിക്കുന്നത് “സ്കെയിൽ പോയിന്റ്” എന്ന് വിളിക്കപ്പെടുന്ന സമയത്താണ് - ഒരു ഇടപാടോ താൽക്കാലിക പട്ടികകളോ ഡാറ്റാബേസിനെ പിന്തുണയ്ക്കാത്ത സമയത്താണ്. ഉദാഹരണത്തിന്, ഒരാഴ്‌ചയ്‌ക്കുള്ളിൽ സ്‌കെയിൽ പോയിന്റ് സംഭവിക്കാനിടയില്ല, അടിസ്ഥാനം ഒരേ ഉറവിടങ്ങളിൽ പ്രവർത്തിക്കുന്നു, മാത്രമല്ല വിപുലീകരിക്കാനോ ചുരുങ്ങാനോ കഴിയില്ല.

മാജിക് ഒന്നുമില്ല - ഇത് പതിവ് PostgreSQL ആണ്. എന്നാൽ യന്ത്രങ്ങൾ കൂട്ടിച്ചേർക്കുകയും അവ വിച്ഛേദിക്കുകയും ചെയ്യുന്ന പ്രക്രിയ ഭാഗികമായി ഓട്ടോമേറ്റഡ് ആണ്.

ഡിസൈൻ പ്രകാരം സെർവർലെസ്

സെർവർലെസിന്റെ ചില ആനുകൂല്യങ്ങൾ പ്രയോജനപ്പെടുത്തുന്നതിനായി ക്ലൗഡിനായി മാറ്റിയെഴുതിയ പഴയ ഡാറ്റാബേസാണ് അറോറ സെർവർലെസ്സ്. സെർവർലെസ്-ബൈ-ഡിസൈൻ - സെർവർലെസ് സമീപനത്തിനായി ക്ലൗഡിനായി ആദ്യം എഴുതിയ അടിത്തറയെക്കുറിച്ച് ഇപ്പോൾ ഞാൻ നിങ്ങളോട് പറയും. ഫിസിക്കൽ സെർവറുകളിൽ പ്രവർത്തിക്കുമെന്ന അനുമാനമില്ലാതെ ഇത് ഉടനടി വികസിപ്പിച്ചെടുത്തു.

ഈ അടിത്തറയെ സ്നോഫ്ലെക്ക് എന്ന് വിളിക്കുന്നു. ഇതിന് മൂന്ന് പ്രധാന ബ്ലോക്കുകളുണ്ട്.

ആദ്യത്തേത് ഒരു മെറ്റാഡാറ്റ ബ്ലോക്ക് ആണ്. സുരക്ഷ, മെറ്റാഡാറ്റ, ഇടപാടുകൾ, അന്വേഷണ ഒപ്റ്റിമൈസേഷൻ (ഇടതുവശത്തുള്ള ചിത്രീകരണത്തിൽ കാണിച്ചിരിക്കുന്നു) എന്നിവയിലെ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്ന വേഗതയേറിയ ഇൻ-മെമ്മറി സേവനമാണിത്.

രണ്ടാമത്തെ ബ്ലോക്ക് കണക്കുകൂട്ടലുകൾക്കായുള്ള വെർച്വൽ കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്ററുകളുടെ ഒരു കൂട്ടമാണ് (ചിത്രത്തിൽ ഒരു കൂട്ടം നീല സർക്കിളുകൾ ഉണ്ട്).

മൂന്നാമത്തെ ബ്ലോക്ക് S3 അടിസ്ഥാനമാക്കിയുള്ള ഒരു ഡാറ്റ സ്റ്റോറേജ് സിസ്റ്റമാണ്. AWS-ലെ അളവില്ലാത്ത ഒബ്‌ജക്‌റ്റ് സംഭരണമാണ് S3, ബിസിനസ്സിനായുള്ള അളവില്ലാത്ത ഡ്രോപ്പ്‌ബോക്‌സ് പോലെയാണ്.

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

ഇപ്പോൾ ഒരു ഉപയോക്താവ് ഞങ്ങളുടെ ഡാറ്റാബേസിൽ വന്ന് ഒരു SQL അന്വേഷണം അയച്ചതായി സങ്കൽപ്പിക്കുക. പ്രോസസ്സിംഗിനായി SQL അന്വേഷണം ഉടനടി മെറ്റാഡാറ്റ സേവനത്തിലേക്ക് അയയ്ക്കുന്നു. അതനുസരിച്ച്, ഒരു അഭ്യർത്ഥന ലഭിക്കുമ്പോൾ, ഈ സേവനം അഭ്യർത്ഥന, ലഭ്യമായ ഡാറ്റ, ഉപയോക്തൃ അനുമതികൾ എന്നിവ വിശകലനം ചെയ്യുകയും എല്ലാം ശരിയാണെങ്കിൽ, അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള ഒരു പ്ലാൻ തയ്യാറാക്കുകയും ചെയ്യുന്നു.

അടുത്തതായി, സേവനം കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്ററിന്റെ സമാരംഭം ആരംഭിക്കുന്നു. കണക്കുകൂട്ടലുകൾ നടത്തുന്ന സെർവറുകളുടെ ഒരു കൂട്ടമാണ് കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്റർ. അതായത്, 1 സെർവർ, 2 സെർവറുകൾ, 4, 8, 16, 32 - നിങ്ങൾക്ക് ആവശ്യമുള്ളത്രയും അടങ്ങിയിരിക്കാവുന്ന ഒരു ക്ലസ്റ്ററാണിത്. നിങ്ങൾ ഒരു അഭ്യർത്ഥന ഇട്ടാൽ ഈ ക്ലസ്റ്ററിന്റെ ലോഞ്ച് ഉടൻ ആരംഭിക്കും. ശരിക്കും സെക്കന്റുകൾ എടുക്കും.

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

ഓരോ SQL അന്വേഷണത്തിനും മുമ്പ് ലോഡ് ചെയ്ത ഡാറ്റയിൽ നിന്നുള്ള അഗ്രഗേറ്റുകൾ വായിക്കാൻ മാത്രമല്ല, ഡാറ്റാബേസിൽ പുതിയ ഡാറ്റ ലോഡുചെയ്യാനും / സൃഷ്ടിക്കാനും കഴിയും. അതായത്, ഇത് ഒരു അന്വേഷണമായിരിക്കാം, ഉദാഹരണത്തിന്, മറ്റൊരു ടേബിളിലേക്ക് പുതിയ റെക്കോർഡുകൾ തിരുകുന്നു, ഇത് കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്ററിൽ ഒരു പുതിയ പാർട്ടീഷൻ പ്രത്യക്ഷപ്പെടുന്നതിലേക്ക് നയിക്കുന്നു, അത് ഒരൊറ്റ S3 സ്റ്റോറേജിൽ യാന്ത്രികമായി സംരക്ഷിക്കപ്പെടും.

മുകളിൽ വിവരിച്ച സാഹചര്യം, ഉപയോക്താവിന്റെ വരവ് മുതൽ ക്ലസ്റ്ററിന്റെ വർദ്ധനവ്, ഡാറ്റ ലോഡുചെയ്യൽ, അന്വേഷണങ്ങൾ നടപ്പിലാക്കൽ, ഫലങ്ങൾ നേടൽ, ഉയർത്തിയ വെർച്വൽ കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്റർ, വെർച്വൽ വെയർഹൗസ് ഉപയോഗിക്കുന്നതിന് മിനിറ്റുകൾക്കുള്ള നിരക്കിൽ പണം നൽകുന്നു. AWS സോണും ക്ലസ്റ്റർ വലുപ്പവും അനുസരിച്ച് നിരക്ക് വ്യത്യാസപ്പെടുന്നു, എന്നാൽ ശരാശരി ഇത് മണിക്കൂറിന് കുറച്ച് ഡോളറാണ്. നാല് മെഷീനുകളുടെ ഒരു ക്ലസ്റ്ററിന് രണ്ട് മെഷീനുകളുടെ ഒരു ക്ലസ്റ്ററിന്റെ ഇരട്ടി വിലയുണ്ട്, എട്ട് മെഷീനുകളുടെ ഒരു ക്ലസ്റ്ററിന് ഇപ്പോഴും ഇരട്ടി വിലയുണ്ട്. അഭ്യർത്ഥനകളുടെ സങ്കീർണ്ണതയെ ആശ്രയിച്ച് 16, 32 മെഷീനുകളുടെ ഓപ്ഷനുകൾ ലഭ്യമാണ്. എന്നാൽ ക്ലസ്റ്റർ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുമ്പോൾ ആ മിനിറ്റുകൾക്ക് മാത്രമേ നിങ്ങൾ പണം നൽകൂ, കാരണം അഭ്യർത്ഥനകളൊന്നുമില്ലെങ്കിൽ, നിങ്ങൾ ഒരു തരത്തിൽ കൈകൾ എടുക്കും, 5-10 മിനിറ്റ് കാത്തിരിപ്പിന് ശേഷം (കോൺഫിഗർ ചെയ്യാവുന്ന പാരാമീറ്റർ) അത് സ്വന്തമായി പുറത്തുപോകും, വിഭവങ്ങൾ സ്വതന്ത്രമാക്കുകയും സ്വതന്ത്രനാകുകയും ചെയ്യുക.

നിങ്ങൾ ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുമ്പോൾ, താരതമ്യേന പറഞ്ഞാൽ, ക്ലസ്റ്റർ പോപ്പ് അപ്പ് ചെയ്യുമ്പോൾ, ഒരു മിനിറ്റിനുള്ളിൽ, അത് മറ്റൊരു മിനിറ്റ് കണക്കാക്കുന്നു, തുടർന്ന് അടച്ചുപൂട്ടാൻ അഞ്ച് മിനിറ്റ്, ഈ ക്ലസ്റ്ററിന്റെ ഏഴ് മിനിറ്റ് പ്രവർത്തനത്തിന് നിങ്ങൾ പണം നൽകേണ്ടിവരും, കൂടാതെ മാസങ്ങളും വർഷങ്ങളും അല്ല.

സിംഗിൾ-ഉപയോക്തൃ ക്രമീകരണത്തിൽ സ്നോഫ്ലെക്ക് ഉപയോഗിക്കുന്നത് വിവരിച്ച ആദ്യത്തെ രംഗം. ഇപ്പോൾ ധാരാളം ഉപയോക്താക്കൾ ഉണ്ടെന്ന് സങ്കൽപ്പിക്കാം, അത് യഥാർത്ഥ സാഹചര്യത്തോട് അടുത്താണ്.

ലളിതമായ അനലിറ്റിക്കൽ എസ്‌ക്യുഎൽ അന്വേഷണങ്ങൾ ഉപയോഗിച്ച് ഞങ്ങളുടെ ഡാറ്റാബേസിൽ നിരന്തരം ബോംബെറിയുന്ന ധാരാളം അനലിസ്റ്റുകളും ടേബിൾ റിപ്പോർട്ടുകളും ഞങ്ങളുടെ പക്കലുണ്ടെന്ന് പറയാം.

കൂടാതെ, ഡാറ്റ ഉപയോഗിച്ച് ഭയാനകമായ കാര്യങ്ങൾ ചെയ്യാൻ ശ്രമിക്കുന്ന, പതിനായിരക്കണക്കിന് ടെറാബൈറ്റുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ ശ്രമിക്കുന്ന, കോടിക്കണക്കിന് ട്രില്യൺ ഡാറ്റ നിരകൾ വിശകലനം ചെയ്യുന്ന കണ്ടുപിടുത്തമുള്ള ഡാറ്റാ സയന്റിസ്റ്റുകൾ ഞങ്ങളുടെ പക്കലുണ്ടെന്ന് പറയാം.

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

ധാരാളം ലൈറ്റ് ക്വറികൾക്കായി, നിങ്ങൾക്ക് 2-3 ചെറിയ ക്ലസ്റ്ററുകൾ, ഏകദേശം 2 മെഷീനുകൾ വീതം ഉയർത്താം. ഈ സ്വഭാവം മറ്റ് കാര്യങ്ങൾക്കൊപ്പം, സ്വയമേവയുള്ള ക്രമീകരണങ്ങൾ ഉപയോഗിച്ച് നടപ്പിലാക്കാൻ കഴിയും. അതിനാൽ നിങ്ങൾ പറയുന്നു, “മഞ്ഞുതുള്ളി, ഒരു ചെറിയ ക്ലസ്റ്റർ ഉയർത്തുക. അതിലെ ലോഡ് ഒരു നിശ്ചിത പരാമീറ്ററിന് മുകളിൽ വർദ്ധിക്കുകയാണെങ്കിൽ, സമാനമായ രണ്ടാമത്തെ, മൂന്നാമത്തേത് ഉയർത്തുക. ലോഡ് കുറയാൻ തുടങ്ങുമ്പോൾ, അധികമുള്ളത് കെടുത്തിക്കളയുക. അതിനാൽ എത്ര അനലിസ്റ്റുകൾ വന്ന് റിപ്പോർട്ടുകൾ നോക്കാൻ തുടങ്ങിയാലും എല്ലാവർക്കും മതിയായ വിഭവങ്ങൾ ഉണ്ട്.

അതേ സമയം, വിശകലന വിദഗ്ധർ ഉറങ്ങുകയാണെങ്കിൽ ആരും റിപ്പോർട്ടുകൾ നോക്കുന്നില്ലെങ്കിൽ, ക്ലസ്റ്ററുകൾ പൂർണ്ണമായും ഇരുണ്ടുപോകാം, നിങ്ങൾ അവയ്ക്ക് പണം നൽകുന്നത് നിർത്തും.

അതേ സമയം, കനത്ത ചോദ്യങ്ങൾക്ക് (ഡാറ്റ സയന്റിസ്റ്റുകളിൽ നിന്ന്), നിങ്ങൾക്ക് 32 മെഷീനുകൾക്കായി ഒരു വലിയ ക്ലസ്റ്റർ ഉയർത്താം. നിങ്ങളുടെ ഭീമമായ അഭ്യർത്ഥന അവിടെ പ്രവർത്തിക്കുമ്പോൾ ആ മിനിറ്റുകൾക്കും മണിക്കൂറുകൾക്കും മാത്രമേ ഈ ക്ലസ്റ്ററിന് പണം ലഭിക്കൂ.

മുകളിൽ വിവരിച്ച അവസരം നിങ്ങളെ 2 മാത്രമല്ല, കൂടുതൽ തരം ജോലിഭാരവും ക്ലസ്റ്ററുകളായി വിഭജിക്കാൻ അനുവദിക്കുന്നു (ETL, നിരീക്ഷണം, റിപ്പോർട്ട് മെറ്റീരിയലൈസേഷൻ,...).

നമുക്ക് സ്നോഫ്ലെക്ക് സംഗ്രഹിക്കാം. അടിസ്ഥാനം മനോഹരമായ ഒരു ആശയവും പ്രവർത്തനക്ഷമമായ നടപ്പാക്കലും സമന്വയിപ്പിക്കുന്നു. ManyChat-ൽ, ഞങ്ങളുടെ പക്കലുള്ള എല്ലാ ഡാറ്റയും വിശകലനം ചെയ്യാൻ ഞങ്ങൾ സ്നോഫ്ലെക്ക് ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിലെന്നപോലെ ഞങ്ങൾക്ക് മൂന്ന് ക്ലസ്റ്ററുകളില്ല, എന്നാൽ 5 മുതൽ 9 വരെ വ്യത്യസ്ത വലുപ്പത്തിലുള്ളവയാണ്. ചില ജോലികൾക്കായി ഞങ്ങൾക്ക് പരമ്പരാഗത 16-മെഷീൻ, 2-മെഷീൻ, കൂടാതെ സൂപ്പർ-സ്മോൾ 1-മെഷീൻ എന്നിവയുണ്ട്. അവർ ലോഡ് വിജയകരമായി വിതരണം ചെയ്യുകയും ധാരാളം ലാഭിക്കാൻ ഞങ്ങളെ അനുവദിക്കുകയും ചെയ്യുന്നു.

ഡാറ്റാബേസ് വായനയുടെയും എഴുത്തിന്റെയും ലോഡിനെ വിജയകരമായി അളക്കുന്നു. വായനാ ഭാരം മാത്രം വഹിച്ച അതേ "അറോറ" യുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇത് ഒരു വലിയ വ്യത്യാസവും വലിയ മുന്നേറ്റവുമാണ്. ഈ കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്ററുകൾ ഉപയോഗിച്ച് നിങ്ങളുടെ എഴുത്ത് ജോലിഭാരം അളക്കാൻ സ്നോഫ്ലെക്ക് നിങ്ങളെ അനുവദിക്കുന്നു. അതായത്, ഞാൻ സൂചിപ്പിച്ചതുപോലെ, ഞങ്ങൾ ManyChat-ൽ നിരവധി ക്ലസ്റ്ററുകൾ ഉപയോഗിക്കുന്നു, ചെറുതും ചെറുതുമായ ക്ലസ്റ്ററുകൾ പ്രധാനമായും ETL-ന്, ഡാറ്റ ലോഡുചെയ്യുന്നതിന് ഉപയോഗിക്കുന്നു. കൂടാതെ, വിശകലന വിദഗ്ധർ ഇതിനകം തന്നെ ഇടത്തരം ക്ലസ്റ്ററുകളിൽ താമസിക്കുന്നു, അവ ETL ലോഡിനെ ബാധിക്കില്ല, അതിനാൽ അവ വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു.

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

ഫലം

ഡാറ്റാബേസിനെ സ്‌റ്റേറ്റ്‌ലെസ്, സ്‌റ്റേറ്റ്‌ഫുൾ ഭാഗങ്ങളായി വിഭജിച്ച് സെർവർലെസ് ഡാറ്റാബേസ് സാധ്യമാണ്. മുകളിൽ പറഞ്ഞിരിക്കുന്ന എല്ലാ ഉദാഹരണങ്ങളിലും, സ്‌റ്റേറ്റ്‌ഫുൾ ഭാഗം, താരതമ്യേന പറഞ്ഞാൽ, S3-ൽ മൈക്രോ-പാർട്ടീഷനുകൾ സംഭരിക്കുന്നതും, സ്റ്റേറ്റ്‌ലെസ്സ് ഒപ്റ്റിമൈസറും, മെറ്റാഡാറ്റയുമായി പ്രവർത്തിക്കുന്നതും, സ്വതന്ത്ര ലൈറ്റ്‌വെയ്റ്റ് സ്റ്റേറ്റ്‌ലെസ് സേവനങ്ങളായി ഉയർത്താവുന്ന സുരക്ഷാ പ്രശ്‌നങ്ങൾ കൈകാര്യം ചെയ്യുന്നതും നിങ്ങൾ ശ്രദ്ധിച്ചിരിക്കാം.

SQL ക്വറികൾ എക്സിക്യൂട്ട് ചെയ്യുന്നത് സ്നോഫ്ലെക്ക് കമ്പ്യൂട്ടിംഗ് ക്ലസ്റ്ററുകൾ പോലെയുള്ള സെർവർലെസ് മോഡിൽ പോപ്പ് അപ്പ് ചെയ്യാനും ആവശ്യമായ ഡാറ്റ മാത്രം ഡൗൺലോഡ് ചെയ്യാനും ചോദ്യം എക്സിക്യൂട്ട് ചെയ്യാനും "പുറത്തേക്ക് പോകാനും" കഴിയുന്ന ലൈറ്റ്-സ്റ്റേറ്റ് സേവനങ്ങളായി കണക്കാക്കാം.

സെർവർലെസ്സ് പ്രൊഡക്ഷൻ ലെവൽ ഡാറ്റാബേസുകൾ ഇതിനകം തന്നെ ഉപയോഗത്തിന് ലഭ്യമാണ്, അവ പ്രവർത്തിക്കുന്നു. ഈ സെർവർലെസ് ഡാറ്റാബേസുകൾ OLAP ടാസ്‌ക്കുകൾ കൈകാര്യം ചെയ്യാൻ തയ്യാറാണ്. നിർഭാഗ്യവശാൽ, OLTP ടാസ്ക്കുകൾക്കായി അവ ഉപയോഗിക്കുന്നു... സൂക്ഷ്മതകളോടെ, പരിമിതികൾ ഉള്ളതിനാൽ. ഒരു വശത്ത്, ഇത് ഒരു മൈനസ് ആണ്. പക്ഷേ, മറുവശത്ത്, ഇത് ഒരു അവസരമാണ്. അറോറയുടെ പരിമിതികളില്ലാതെ, ഒരു OLTP ഡാറ്റാബേസ് പൂർണ്ണമായും സെർവർരഹിതമാക്കുന്നതിനുള്ള ഒരു മാർഗം വായനക്കാരിൽ ഒരാൾ കണ്ടെത്തിയേക്കാം.

നിങ്ങൾ അത് രസകരമായി കണ്ടെത്തിയെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. സെർവർലെസ് ആണ് ഭാവി :)

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