“നമ്മുടെ രഹസ്യ പ്രപഞ്ചം: കോശത്തിന്റെ മറഞ്ഞിരിക്കുന്ന ജീവിതം” എന്ന സിനിമയിൽ നിന്ന് ഇപ്പോഴും

നിക്ഷേപ ബിസിനസ്സ് ബാങ്കിംഗ് ലോകത്തിലെ ഏറ്റവും സങ്കീർണ്ണമായ മേഖലകളിലൊന്നാണ്, കാരണം വായ്പകൾ, വായ്പകൾ, നിക്ഷേപങ്ങൾ എന്നിവ മാത്രമല്ല, സെക്യൂരിറ്റികൾ, കറൻസികൾ, ചരക്കുകൾ, ഡെറിവേറ്റീവുകൾ, ഘടനാപരമായ ഉൽപ്പന്നങ്ങളുടെ രൂപത്തിൽ എല്ലാത്തരം സങ്കീർണ്ണതകളും ഉണ്ട്.

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

കൂടാതെ, റഷ്യൻ, വിദേശ രാജ്യങ്ങളിലെ റെഗുലേറ്റർമാരുടെ ആവശ്യങ്ങൾ വളരുകയാണ്.

നിലവിലെ ആവശ്യങ്ങൾ നിറവേറ്റുന്നതിനും ഭാവിയിലെ നവീകരണങ്ങൾക്ക് അടിത്തറയിടുന്നതിനും, ഞങ്ങൾ Tarantool അടിസ്ഥാനമാക്കിയുള്ള ഒരു നിക്ഷേപ ബിസിനസ് കോർ വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്.

ചില സ്ഥിതിവിവരക്കണക്കുകൾ. ആൽഫ-ബാങ്കിന്റെ നിക്ഷേപ ബിസിനസ്സ് വ്യക്തികൾക്കും നിയമപരമായ സ്ഥാപനങ്ങൾക്കും വിവിധ സെക്യൂരിറ്റീസ് മാർക്കറ്റുകളിൽ വ്യാപാരം ചെയ്യുന്നതിനുള്ള ബ്രോക്കറേജ് സേവനങ്ങൾ നൽകുന്നു, സെക്യൂരിറ്റികളുടെ സംഭരണത്തിനുള്ള ഡിപ്പോസിറ്ററി സേവനങ്ങൾ, സ്വകാര്യവും വലിയ മൂലധനവുമുള്ള വ്യക്തികൾക്കുള്ള ട്രസ്റ്റ് മാനേജ്മെന്റ് സേവനങ്ങൾ, മറ്റ് കമ്പനികൾക്ക് സെക്യൂരിറ്റികൾ നൽകുന്നതിനുള്ള സേവനങ്ങൾ. . ആൽഫ-ബാങ്കിന്റെ നിക്ഷേപ ബിസിനസ്സിൽ സെക്കൻഡിൽ മൂവായിരത്തിലധികം ഉദ്ധരണികൾ ഉൾപ്പെടുന്നു, അവ വിവിധ ട്രേഡിംഗ് പ്ലാറ്റ്‌ഫോമുകളിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്യുന്നു. പ്രവൃത്തി ദിവസത്തിൽ, ബാങ്കിനോ അതിന്റെ ക്ലയന്റുകൾക്കോ ​​വേണ്ടി മാർക്കറ്റുകളിൽ 3 ആയിരത്തിലധികം ഇടപാടുകൾ സമാപിക്കുന്നു. ബാഹ്യവും ആന്തരികവുമായ പ്ലാറ്റ്‌ഫോമുകളിൽ സെക്കൻഡിൽ 300 ആയിരം ഓർഡർ എക്‌സിക്യൂഷനുകൾ വരെ സംഭവിക്കുന്നു. അതേ സമയം, എല്ലാ ക്ലയന്റുകളും, ആന്തരികവും ബാഹ്യവുമായ, തത്സമയം അവരുടെ സ്ഥാനങ്ങൾ കാണാൻ ആഗ്രഹിക്കുന്നു.

ചരിത്രാതീതകാലം

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

കൂടാതെ, സിസ്റ്റങ്ങളുടെ കോഡ് ബേസ് ഇതിനകം തന്നെ കാലഹരണപ്പെട്ടതാണ്, കാരണം ചില ഉൽപ്പന്നങ്ങൾ 1990-കളുടെ മധ്യത്തിലാണ് ഉത്ഭവിച്ചത്. ചില മേഖലകളിൽ ഇത് വികസന പ്രക്രിയയെ മന്ദഗതിയിലാക്കി, പ്രകടന പ്രശ്നങ്ങളും ഉണ്ടായി.

ഒരു പുതിയ പരിഹാരത്തിനുള്ള ആവശ്യകതകൾ

കൂടുതൽ വികസനത്തിന് സാങ്കേതിക പരിവർത്തനം സുപ്രധാനമാണെന്ന് ബിസിനസുകൾ തിരിച്ചറിഞ്ഞു. ഞങ്ങൾക്ക് ചുമതലകൾ നൽകി:

1. എല്ലാ ബിസിനസ് ഡാറ്റയും ഒറ്റ, വേഗത്തിലുള്ള സംഭരണത്തിലും ഒരൊറ്റ ഡാറ്റ മോഡലിലും ശേഖരിക്കുക.
2. ഈ വിവരങ്ങൾ നഷ്‌ടപ്പെടുകയോ മാറ്റുകയോ ചെയ്യരുത്.
3. ഡാറ്റ പതിപ്പ് ചെയ്യേണ്ടത് ആവശ്യമാണ്, കാരണം ഏത് നിമിഷവും റെഗുലേറ്റർ മുൻ വർഷങ്ങളിലെ സ്ഥിതിവിവരക്കണക്കുകൾ ആവശ്യപ്പെട്ടേക്കാം.
4. ഞങ്ങൾ ചില പുതിയ, ഫാഷനബിൾ DBMS കൊണ്ടുവരിക മാത്രമല്ല, ബിസിനസ് പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഒരു പ്ലാറ്റ്ഫോം സൃഷ്ടിക്കുകയും വേണം.

കൂടാതെ, ഞങ്ങളുടെ ആർക്കിടെക്റ്റുകൾ അവരുടേതായ വ്യവസ്ഥകൾ സജ്ജമാക്കുന്നു:

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

ഞങ്ങൾ സ്റ്റാൻഡേർഡ് റൂട്ട് പിന്തുടർന്നു: ഞങ്ങൾ ആവശ്യകതകൾ രൂപപ്പെടുത്തുകയും വാങ്ങൽ വകുപ്പുമായി ബന്ധപ്പെടുകയും ചെയ്തു. പൊതുവേ, ഞങ്ങൾക്കായി ഇത് ചെയ്യാൻ തയ്യാറുള്ള കമ്പനികളുടെ ഒരു ലിസ്റ്റ് അവിടെ നിന്ന് ഞങ്ങൾക്ക് ലഭിച്ചു. പ്രശ്‌നത്തെക്കുറിച്ച് ഞങ്ങൾ എല്ലാവരോടും പറയുകയും അവരിൽ ആറുപേരിൽ നിന്ന് പരിഹാരങ്ങളുടെ ഒരു വിലയിരുത്തൽ ലഭിക്കുകയും ചെയ്തു.

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

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

അടുത്തതായി, ഞങ്ങളുടെ സിസ്റ്റം എങ്ങനെ വളർന്നു, അത് എങ്ങനെ വികസിച്ചു, ഞങ്ങൾ എന്താണ് ചെയ്‌തത്, എന്തിനാണ് ഇത് എന്നതിനെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയും.

വികസനം

ഞങ്ങളുടെ നിലവിലെ സിസ്റ്റങ്ങളിൽ നിന്ന് എങ്ങനെ ഡാറ്റ നേടാം എന്നതായിരുന്നു ഞങ്ങൾ സ്വയം ചോദിച്ച ആദ്യ ചോദ്യം. HTTP ഞങ്ങൾക്ക് തികച്ചും അനുയോജ്യമാണെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു, കാരണം നിലവിലുള്ള എല്ലാ സിസ്റ്റങ്ങളും HTTP വഴി XML അല്ലെങ്കിൽ JSON അയച്ചുകൊണ്ട് പരസ്പരം ആശയവിനിമയം നടത്തുന്നു.

SSL സെഷനുകൾ അവസാനിപ്പിക്കേണ്ട ആവശ്യമില്ലാത്തതിനാൽ Tarantool-ൽ നിർമ്മിച്ച HTTP സെർവർ ഞങ്ങൾ ഉപയോഗിക്കുന്നു, അതിന്റെ പ്രകടനം ഞങ്ങൾക്ക് മതിയാകും.

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

പരിവർത്തനത്തിന് ശേഷം, ഞങ്ങൾ സൃഷ്ടിക്കുന്ന മോഡലിന് അനുസൃതമായി ഡാറ്റ പരിശോധിക്കണം. മാതൃക എന്തായിരിക്കണം, അതിനെ വിവരിക്കാൻ ഏത് ഭാഷ ഉപയോഗിക്കണം എന്ന് ഞങ്ങൾ വളരെക്കാലം ചർച്ച ചെയ്തു. ഞങ്ങൾ Apache Avro തിരഞ്ഞെടുത്തു, കാരണം ഭാഷ ലളിതമാണ്, അതിന് Tarantool-ൽ നിന്നുള്ള പിന്തുണയുണ്ട്. മോഡലിന്റെയും ഇഷ്‌ടാനുസൃത കോഡിന്റെയും പുതിയ പതിപ്പുകൾ ദിവസത്തിൽ എപ്പോൾ വേണമെങ്കിലും ലോഡിന് താഴെയോ അല്ലാതെയോ നിരവധി തവണ പ്രവർത്തനക്ഷമമാക്കുകയും മാറ്റങ്ങളുമായി വളരെ വേഗത്തിൽ പൊരുത്തപ്പെടുകയും ചെയ്യാം.

പരിശോധിച്ചുറപ്പിച്ച ശേഷം, ഡാറ്റ സേവ് ചെയ്യണം. ഞങ്ങൾ ഇത് ചെയ്യുന്നത് vshard ഉപയോഗിച്ചാണ് (നമ്മുടെ ജിയോ ഡിസ്പേർസ്ഡ് പകർപ്പുകൾ ഉണ്ട്).

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

സംരക്ഷിച്ച ഡാറ്റ എങ്ങനെ വീണ്ടെടുക്കാമെന്ന് ഇപ്പോൾ നിങ്ങൾ പഠിക്കേണ്ടതുണ്ട്. ഞങ്ങളുടെ സിസ്റ്റങ്ങളെ ഞങ്ങൾ ശ്രദ്ധാപൂർവ്വം വിശകലനം ചെയ്തു, ജാവയുടെയും ഒറാക്കിളിന്റെയും ക്ലാസിക് സ്റ്റാക്കിൽ ഡാറ്റയെ റിലേറ്റേഷനിൽ നിന്ന് ഒബ്‌ജക്റ്റിലേക്ക് പരിവർത്തനം ചെയ്യുന്ന ഏതെങ്കിലും തരത്തിലുള്ള ORM അടങ്ങിയിരിക്കണമെന്ന് ഞങ്ങൾ കണ്ടെത്തി. അപ്പോൾ എന്തുകൊണ്ട് ഒരു ഗ്രാഫിന്റെ രൂപത്തിൽ സിസ്റ്റങ്ങൾക്ക് ഒബ്ജക്റ്റുകൾ ഉടനടി നൽകരുത്? അതിനാൽ ഞങ്ങളുടെ എല്ലാ ആവശ്യങ്ങളും നിറവേറ്റുന്ന ഗ്രാഫ്ക്യുഎൽ ഞങ്ങൾ സന്തോഷത്തോടെ സ്വീകരിച്ചു. ഗ്രാഫുകളുടെ രൂപത്തിൽ ഡാറ്റ സ്വീകരിക്കാനും ഇപ്പോൾ നിങ്ങൾക്ക് ആവശ്യമുള്ളത് മാത്രം പുറത്തെടുക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. നിങ്ങൾക്ക് വളരെയധികം ഫ്ലെക്സിബിലിറ്റി ഉപയോഗിച്ച് API പതിപ്പ് പോലും ചെയ്യാം.

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

ഒരു പ്രാമാണീകരണ സംവിധാനം നടപ്പിലാക്കി.

ഞങ്ങളുടെ തീരുമാനത്തിൽ നിരവധി വേഷങ്ങൾ ക്രിസ്റ്റലൈസ് ചെയ്യുന്നത് ഞങ്ങൾ ശ്രദ്ധിച്ചു. ഒരു പങ്ക് ഫംഗ്‌ഷനുകളുടെ ഒരു തരം അഗ്രഗേറ്ററാണ്. സാധാരണയായി, റോളുകൾക്ക് വ്യത്യസ്ത ഉപകരണ ഉപയോഗ പ്രൊഫൈലുകൾ ഉണ്ട്:

• ടി-കണക്ട്: ഇൻകമിംഗ് കണക്ഷനുകൾ കൈകാര്യം ചെയ്യുന്നു, സിപിയു പരിമിതം, കുറഞ്ഞ മെമ്മറി ഉപഭോഗം, നിലയില്ലാത്തത്.
• IB-Core: Tarantool പ്രോട്ടോക്കോൾ വഴി ലഭിക്കുന്ന ഡാറ്റയെ പരിവർത്തനം ചെയ്യുന്നു, അതായത്, ഇത് പട്ടികകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു. ഇത് സംസ്ഥാനം സംഭരിക്കുന്നില്ല, അത് അളക്കാവുന്നതുമാണ്.
• സംഭരണം: ഡാറ്റ മാത്രം സംഭരിക്കുന്നു, ഒരു ലോജിക്കും ഉപയോഗിക്കുന്നില്ല. ഈ റോൾ ഏറ്റവും ലളിതമായ ഇന്റർഫേസുകൾ നടപ്പിലാക്കുന്നു. vshard-ന് സ്കേലബിൾ നന്ദി.

അതായത്, റോളുകൾ ഉപയോഗിച്ച്, ഞങ്ങൾ ക്ലസ്റ്ററിന്റെ വിവിധ ഭാഗങ്ങൾ പരസ്പരം വേർപെടുത്തി, അവ പരസ്പരം സ്വതന്ത്രമായി അളക്കാൻ കഴിയും.

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

പരിശോധിക്കുന്നു

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

പരീക്ഷണാടിസ്ഥാനത്തിലുള്ള വികസനം ഞങ്ങൾ എങ്ങനെയാണ് ഉപയോഗിക്കുന്നത്?

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

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

എന്നിരുന്നാലും, ഞങ്ങൾ ഏറ്റവും ഇഷ്ടപ്പെടുന്നത് ലോഡ് പരിശോധനയാണ്; ഞങ്ങൾ ഇത് ഏറ്റവും പ്രധാനപ്പെട്ടതായി കണക്കാക്കുകയും പതിവായി അത് നടപ്പിലാക്കുകയും ചെയ്യുന്നു.

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

ഞങ്ങൾ വളരെ സങ്കടപ്പെട്ടു. ഞങ്ങൾ സെർവർ ലോഡ് നോക്കുന്നു, പക്ഷേ അവ നിഷ്‌ക്രിയമാണെന്ന് മാറുന്നു.

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

ഒന്നുകൂടി വിശദീകരിക്കാം. വിഭവങ്ങൾ വ്യത്യസ്തമായി ഉപയോഗിക്കുന്ന റോളുകളായി വിഭജിക്കപ്പെട്ടതിനാൽ, കണക്ഷനുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനും ഡാറ്റാ പരിവർത്തനത്തിനും ഉത്തരവാദികളായ ഞങ്ങളുടെ റോളുകൾ പ്രോസസറിനെ മാത്രം ലോഡുചെയ്‌തു, ലോഡിന് കർശനമായി ആനുപാതികമാണ്.

ഈ സാഹചര്യത്തിൽ, ഇൻകമിംഗ് കണക്ഷനുകളും താൽക്കാലിക വസ്തുക്കളും പ്രോസസ്സ് ചെയ്യുന്നതിന് മാത്രമേ മെമ്മറി ഉപയോഗിച്ചിട്ടുള്ളൂ.

നേരെമറിച്ച്, സ്റ്റോറേജ് സെർവറുകളിൽ, പ്രോസസർ ലോഡ് വർദ്ധിച്ചു, പക്ഷേ കണക്ഷനുകൾ പ്രോസസ്സ് ചെയ്യുന്ന സെർവറുകളേക്കാൾ വളരെ മന്ദഗതിയിലാണ്.

ലോഡുചെയ്ത ഡാറ്റയുടെ അളവിന് നേരിട്ട് ആനുപാതികമായി മെമ്മറി ഉപഭോഗം വർദ്ധിച്ചു.

സേവനങ്ങൾ

ഞങ്ങളുടെ പുതിയ ഉൽപ്പന്നം പ്രത്യേകമായി ഒരു ആപ്ലിക്കേഷൻ പ്ലാറ്റ്‌ഫോമായി വികസിപ്പിക്കുന്നതിന്, അതിൽ സേവനങ്ങളും ലൈബ്രറികളും വിന്യസിക്കാൻ ഞങ്ങൾ ഒരു ഘടകം സൃഷ്ടിച്ചു.

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

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

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

പഴയ സംവിധാനങ്ങൾ

ഞങ്ങളുടെ എല്ലാ ലെഗസി സിസ്റ്റങ്ങൾക്കും ഞങ്ങളെ എച്ച്ടിടിപി വഴി വിളിക്കാനും ഗ്രാഫ്ക്യുഎൽ ഉപയോഗിക്കാനും കഴിയില്ല, എന്നിരുന്നാലും അവ പ്രോട്ടോക്കോൾ പിന്തുണയ്ക്കുന്നു. അതിനാൽ, ഈ സിസ്റ്റങ്ങളിലേക്ക് ഡാറ്റ പകർത്താൻ അനുവദിക്കുന്ന ഒരു സംവിധാനം ഞങ്ങൾ സൃഷ്ടിച്ചു.

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

പുതിയ മെച്ചപ്പെടുത്തലുകൾ

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

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

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

തുടക്കത്തിൽ, എല്ലാ ഡാറ്റയും സംഭരിക്കുക, പതിപ്പിക്കുക, ഇല്ലാതാക്കാതിരിക്കുക എന്ന മാതൃക ഞങ്ങൾ പാലിച്ചു. എന്നാൽ ജീവിതത്തിൽ, കാലാകാലങ്ങളിൽ നിങ്ങൾ ഇപ്പോഴും എന്തെങ്കിലും ഇല്ലാതാക്കേണ്ടതുണ്ട്, മിക്കവാറും ചില അസംസ്കൃത അല്ലെങ്കിൽ ഇന്റർമീഡിയറ്റ് വിവരങ്ങൾ. കാലഹരണപ്പെട്ടതിനെ അടിസ്ഥാനമാക്കി, കാലഹരണപ്പെട്ട ഡാറ്റയിൽ നിന്ന് സംഭരണം വൃത്തിയാക്കുന്നതിനുള്ള ഒരു സംവിധാനം ഞങ്ങൾ സൃഷ്ടിച്ചു.

മെമ്മറിയിൽ ഡാറ്റ സംഭരിക്കുന്നതിന് മതിയായ ഇടം ഇല്ലാത്ത ഒരു സാഹചര്യം ഉടൻ അല്ലെങ്കിൽ പിന്നീട് വരുമെന്നും ഞങ്ങൾ മനസ്സിലാക്കുന്നു, എന്നിരുന്നാലും ഡാറ്റ സംഭരിച്ചിരിക്കണം. ഈ ആവശ്യങ്ങൾക്കായി, ഞങ്ങൾ ഉടൻ തന്നെ ഡിസ്ക് സ്റ്റോറേജ് ഉണ്ടാക്കും.

തീരുമാനം

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

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

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

വികസനത്തിന്റെ എല്ലാ ഘട്ടങ്ങളിലും ലോഡ് ടെസ്റ്റിംഗ് നടത്തുന്നത് വളരെ പ്രധാനമാണ്. വാസ്തുവിദ്യയിലെ ചില പോരായ്മകൾ നിങ്ങൾ എത്രയും വേഗം ശ്രദ്ധിക്കുന്നുവോ, അത് പരിഹരിക്കുന്നത് എളുപ്പമാകും, ഇത് ഭാവിയിൽ നിങ്ങൾക്ക് ധാരാളം സമയം ലാഭിക്കും.

ലുവായ്ക്ക് കുഴപ്പമൊന്നുമില്ല. ആർക്കും അതിൽ എഴുതാൻ പഠിക്കാം: ജാവ ഡെവലപ്പർ, ജാവാസ്ക്രിപ്റ്റ് ഡെവലപ്പർ, പൈത്തൺ ഡെവലപ്പർ, ഫ്രണ്ട്-എൻഡ് അല്ലെങ്കിൽ ബാക്ക്-എൻഡ്. നമ്മുടെ വിശകലന വിദഗ്ധർ പോലും അതിൽ എഴുതുന്നു.

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

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

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