VKontakte സന്ദേശ ഡാറ്റാബേസ് ആദ്യം മുതൽ വീണ്ടും എഴുതുക, അതിജീവിക്കുക

ഞങ്ങളുടെ ഉപയോക്താക്കൾ ക്ഷീണം അറിയാതെ പരസ്പരം സന്ദേശങ്ങൾ എഴുതുന്നു.

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

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

ഞങ്ങളെ സംബന്ധിച്ചിടത്തോളം ഈ നിമിഷം ഒന്നര വർഷം മുമ്പാണ് വന്നത്. ഞങ്ങൾ ഇതിലേക്ക് എങ്ങനെ എത്തി, അവസാനം എന്താണ് സംഭവിച്ചത് - ഞങ്ങൾ നിങ്ങളോട് ക്രമത്തിൽ പറയുന്നു.

പശ്ചാത്തലം

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

2009 അവസാനത്തോടെ, ആദ്യത്തെ ടെക്സ്റ്റ് എഞ്ചിൻ ശേഖരം എഴുതപ്പെട്ടു, 2010-ൽ അതിലേക്ക് സന്ദേശങ്ങൾ കൈമാറി.

ടെക്സ്റ്റ് എഞ്ചിനിൽ, സന്ദേശങ്ങൾ ലിസ്റ്റുകളിൽ സംഭരിച്ചു - ഒരുതരം "മെയിൽബോക്സുകൾ". അത്തരം ഓരോ ലിസ്റ്റും നിർണ്ണയിക്കുന്നത് ഒരു uid ആണ് - ഈ സന്ദേശങ്ങളെല്ലാം സ്വന്തമാക്കിയ ഉപയോക്താവ്. ഒരു സന്ദേശത്തിന് ഒരു കൂട്ടം ആട്രിബ്യൂട്ടുകൾ ഉണ്ട്: ഇന്റർലോക്കുട്ടർ ഐഡന്റിഫയർ, ടെക്‌സ്‌റ്റ്, അറ്റാച്ച്‌മെന്റുകൾ തുടങ്ങിയവ. "ബോക്സിനുള്ളിലെ" സന്ദേശ ഐഡന്റിഫയർ ലോക്കൽ_ഐഡിയാണ്, അത് ഒരിക്കലും മാറില്ല, പുതിയ സന്ദേശങ്ങൾക്കായി ക്രമാനുഗതമായി നിയോഗിക്കപ്പെടുന്നു. "ബോക്സുകൾ" സ്വതന്ത്രവും എഞ്ചിനിനുള്ളിൽ പരസ്പരം സമന്വയിപ്പിക്കപ്പെടുന്നില്ല; അവ തമ്മിലുള്ള ആശയവിനിമയം PHP തലത്തിലാണ് നടക്കുന്നത്. ടെക്സ്റ്റ് എഞ്ചിന്റെ ഡാറ്റാ ഘടനയും കഴിവുകളും നിങ്ങൾക്ക് അകത്ത് നിന്ന് നോക്കാം ഇവിടെ.

രണ്ട് ഉപയോക്താക്കൾ തമ്മിലുള്ള കത്തിടപാടുകൾക്ക് ഇത് മതിയായിരുന്നു. പിന്നീട് എന്താണ് സംഭവിച്ചതെന്ന് ഊഹിക്കുക?

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

"PHP, നമുക്ക് ചാറ്റിലേക്ക് ഒരു സന്ദേശം അയയ്ക്കാം," ഉപയോക്താവ് പറയുന്നു.
“വരൂ, {username},” PHP പറയുന്നു.

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

2015 അവസാനത്തോടെ, ഞങ്ങൾ കമ്മ്യൂണിറ്റി സന്ദേശങ്ങൾ സമാരംഭിച്ചു, 2016 ന്റെ തുടക്കത്തിൽ ഞങ്ങൾ അവർക്കായി ഒരു API സമാരംഭിച്ചു. കമ്മ്യൂണിറ്റികളിൽ വലിയ ചാറ്റ്ബോട്ടുകളുടെ വരവോടെ, ലോഡ് വിതരണത്തെക്കുറിച്ച് പോലും മറക്കാൻ കഴിഞ്ഞു.

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

2016-ലെ സന്ദേശ എഞ്ചിനുകൾ ചാറ്റ്-അംഗങ്ങളുടെയും അംഗ-ചാറ്റുകളുടെയും 100 സന്ദർഭങ്ങളും 8000 ടെക്സ്റ്റ് എഞ്ചിനുകളുമാണ്. അവ ആയിരം സെർവറുകളിൽ ഹോസ്റ്റ് ചെയ്തു, ഓരോന്നിനും 64 ജിബി മെമ്മറി. ആദ്യത്തെ അടിയന്തര നടപടിയെന്ന നിലയിൽ, ഞങ്ങൾ മെമ്മറി 32 ജിബി കൂടി വർദ്ധിപ്പിച്ചു. ഞങ്ങൾ പ്രവചനങ്ങൾ കണക്കാക്കി. കാര്യമായ മാറ്റങ്ങളില്ലാതെ, ഇത് ഏകദേശം ഒരു വർഷത്തേക്ക് മതിയാകും. നിങ്ങൾ ഒന്നുകിൽ ഹാർഡ്‌വെയർ പിടിക്കുകയോ ഡാറ്റാബേസുകൾ സ്വയം ഒപ്റ്റിമൈസ് ചെയ്യുകയോ ചെയ്യേണ്ടതുണ്ട്.

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

പുതിയ ആശയം

പുതിയ സമീപനത്തിന്റെ കേന്ദ്ര സാരാംശം ചാറ്റ് ആണ്. ഒരു ചാറ്റിന് അതുമായി ബന്ധപ്പെട്ട സന്ദേശങ്ങളുടെ ഒരു ലിസ്റ്റ് ഉണ്ട്. ഉപയോക്താവിന് ചാറ്റുകളുടെ ഒരു ലിസ്റ്റ് ഉണ്ട്.

ആവശ്യമായ ഏറ്റവും കുറഞ്ഞത് രണ്ട് പുതിയ ഡാറ്റാബേസുകളാണ്:

• ചാറ്റ്-എഞ്ചിൻ. ഇത് ചാറ്റ് വെക്റ്ററുകളുടെ ഒരു ശേഖരമാണ്. ഓരോ ചാറ്റിനും അതുമായി ബന്ധപ്പെട്ട സന്ദേശങ്ങളുടെ ഒരു വെക്റ്റർ ഉണ്ട്. ഓരോ സന്ദേശത്തിനും ചാറ്റിനുള്ളിൽ ഒരു ടെക്‌സ്റ്റും തനതായ സന്ദേശ ഐഡന്റിഫയറും ഉണ്ട് - chat_local_id.
• ഉപയോക്തൃ-എഞ്ചിൻ. ഇത് ഉപയോക്താക്കൾക്കുള്ള വെക്റ്ററുകളുടെ സംഭരണമാണ് - ഉപയോക്താക്കളിലേക്കുള്ള ലിങ്കുകൾ. ഓരോ ഉപയോക്താവിനും peer_id (ഇന്റർലോക്കുട്ടർമാർ - മറ്റ് ഉപയോക്താക്കൾ, മൾട്ടി-ചാറ്റ് അല്ലെങ്കിൽ കമ്മ്യൂണിറ്റികൾ) ഒരു വെക്‌ടറും സന്ദേശങ്ങളുടെ വെക്‌ടറും ഉണ്ട്. ഓരോ peer_id-നും അതുമായി ബന്ധപ്പെട്ട സന്ദേശങ്ങളുടെ ഒരു വെക്റ്റർ ഉണ്ട്. ഓരോ സന്ദേശത്തിനും ഒരു chat_local_id ഉം ആ ഉപയോക്താവിനായി ഒരു അദ്വിതീയ സന്ദേശ ഐഡിയും ഉണ്ട് - user_local_id.

പുതിയ ക്ലസ്റ്ററുകൾ ടിസിപി ഉപയോഗിച്ച് പരസ്പരം ആശയവിനിമയം നടത്തുന്നു - അഭ്യർത്ഥനകളുടെ ക്രമം മാറുന്നില്ലെന്ന് ഇത് ഉറപ്പാക്കുന്നു. അഭ്യർത്ഥനകളും അവയ്ക്കുള്ള സ്ഥിരീകരണങ്ങളും ഹാർഡ് ഡ്രൈവിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ട് - അതിനാൽ എഞ്ചിൻ പരാജയപ്പെടുകയോ പുനരാരംഭിക്കുകയോ ചെയ്തതിന് ശേഷം എപ്പോൾ വേണമെങ്കിലും ക്യൂവിന്റെ അവസ്ഥ പുനഃസ്ഥാപിക്കാൻ കഴിയും. ഉപയോക്തൃ-എഞ്ചിനും ചാറ്റ്-എഞ്ചിനും 4 ആയിരം ഷാർഡുകൾ വീതമുള്ളതിനാൽ, ക്ലസ്റ്ററുകൾക്കിടയിലുള്ള അഭ്യർത്ഥന ക്യൂ തുല്യമായി വിതരണം ചെയ്യും (എന്നാൽ വാസ്തവത്തിൽ ഒന്നുമില്ല - ഇത് വളരെ വേഗത്തിൽ പ്രവർത്തിക്കുന്നു).

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

അതേ സമയം, ഹാർഡ് ഡ്രൈവിലെ ഡാറ്റ തന്നെ ഒരു ദിവസത്തിൽ ഒരിക്കൽ മാത്രം മാറുന്നു - മോസ്കോയിൽ രാത്രി വൈകി, ലോഡ് കുറഞ്ഞത്. ഇതിന് നന്ദി (ഡിസ്കിലെ ഘടന ദിവസം മുഴുവനും സ്ഥിരമാണെന്ന് അറിഞ്ഞുകൊണ്ട്), വെക്റ്ററുകൾ ഒരു നിശ്ചിത വലുപ്പത്തിലുള്ള ശ്രേണികൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കാൻ ഞങ്ങൾക്ക് കഴിയും - ഇതുമൂലം, മെമ്മറി നേടുക.

പുതിയ സ്കീമിൽ ഒരു സന്ദേശം അയക്കുന്നത് ഇതുപോലെയാണ്:

1. ഒരു സന്ദേശം അയയ്‌ക്കാനുള്ള അഭ്യർത്ഥനയോടെ PHP ബാക്കെൻഡ് ഉപയോക്തൃ എഞ്ചിനുമായി ബന്ധപ്പെടുന്നു.
2. ഉപയോക്താവ്-എഞ്ചിൻ ആവശ്യമുള്ള ചാറ്റ്-എഞ്ചിൻ ഇൻസ്‌റ്റൻസിലേക്കുള്ള അഭ്യർത്ഥന പ്രോക്‌സി ചെയ്യുന്നു, അത് ഉപയോക്തൃ എഞ്ചിനിലേക്ക് മടങ്ങുന്നു chat_local_id - ഈ ചാറ്റിലെ ഒരു പുതിയ സന്ദേശത്തിന്റെ തനതായ ഐഡന്റിഫയർ. chat_engine തുടർന്ന് ചാറ്റിലെ എല്ലാ സ്വീകർത്താക്കൾക്കും സന്ദേശം പ്രക്ഷേപണം ചെയ്യുന്നു.
3. ഉപയോക്തൃ-എഞ്ചിൻ ചാറ്റ്-എഞ്ചിനിൽ നിന്ന് chat_local_id സ്വീകരിക്കുകയും user_local_id PHP-ലേക്ക് തിരികെ നൽകുകയും ചെയ്യുന്നു - ഈ ഉപയോക്താവിനുള്ള ഒരു അദ്വിതീയ സന്ദേശ ഐഡന്റിഫയർ. ഈ ഐഡന്റിഫയർ പിന്നീട് ഉപയോഗിക്കും, ഉദാഹരണത്തിന്, API വഴിയുള്ള സന്ദേശങ്ങളുമായി പ്രവർത്തിക്കാൻ.

എന്നാൽ യഥാർത്ഥത്തിൽ സന്ദേശങ്ങൾ അയയ്‌ക്കുന്നതിനു പുറമേ, നിങ്ങൾ കുറച്ച് കൂടി പ്രധാനപ്പെട്ട കാര്യങ്ങൾ നടപ്പിലാക്കേണ്ടതുണ്ട്:

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

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

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

ചാറ്റുകളേക്കാൾ വളരെ കുറച്ച് ഉപയോക്താക്കൾ ഉള്ളതിനാൽ, റാൻഡം-ആക്സസ് ഡിസ്ക് അഭ്യർത്ഥനകൾ ചാറ്റ് എഞ്ചിനിൽ സംരക്ഷിക്കുന്നതിന്, ഞങ്ങൾ സന്ദേശങ്ങൾ ഉപയോക്തൃ എഞ്ചിനിൽ കാഷെ ചെയ്യുന്നു.

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

ശരി, എല്ലാ വിശദാംശങ്ങളും കണക്കിലെടുത്തിട്ടുണ്ട്, ഒരു പുതിയ സ്കീമിലേക്ക് മാറുക മാത്രമാണ് അവശേഷിക്കുന്നത് - ഉപയോക്താക്കൾ അത് ശ്രദ്ധിക്കാതെ തന്നെ.

ഡാറ്റ മൈഗ്രേഷൻ

അതിനാൽ, ഉപയോക്താക്കൾ മുഖേന സന്ദേശങ്ങൾ സംഭരിക്കുന്ന ഒരു ടെക്‌സ്‌റ്റ് എഞ്ചിനും മൾട്ടി-ചാറ്റ് റൂമുകളെയും അവയിലെ ഉപയോക്താക്കളെയും കുറിച്ചുള്ള ഡാറ്റ സംഭരിക്കുന്ന രണ്ട് ക്ലസ്റ്ററുകൾ ചാറ്റ്-അംഗങ്ങളും അംഗ-ചാറ്റുകളും ഞങ്ങൾക്കുണ്ട്. ഇതിൽ നിന്ന് പുതിയ യൂസർ എഞ്ചിനിലേക്കും ചാറ്റ് എഞ്ചിനിലേക്കും എങ്ങനെ മാറാം?

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

ചാറ്റ് അംഗങ്ങൾക്കായുള്ള ക്യൂ. ഇതിൽ 100 ​​സംഭവങ്ങൾ ഉൾപ്പെടുന്നു, അതേസമയം ചാറ്റ് എഞ്ചിനിൽ 4 ആയിരം ഉണ്ട്. ഡാറ്റ കൈമാറാൻ, നിങ്ങൾ അത് പാലിക്കേണ്ടതുണ്ട് - ഇതിനായി, ചാറ്റ്-അംഗങ്ങളെ അതേ 4 ആയിരം പകർപ്പുകളായി വിഭജിച്ചു, തുടർന്ന് ചാറ്റ്-മെമ്പർമാരുടെ ബിൻലോഗ് വായിക്കുന്നത് ചാറ്റ് എഞ്ചിനിൽ പ്രവർത്തനക്ഷമമാക്കി.

ഇപ്പോൾ ചാറ്റ്-എഞ്ചിന് ചാറ്റ്-അംഗങ്ങളിൽ നിന്നുള്ള മൾട്ടി-ചാറ്റിനെക്കുറിച്ച് അറിയാം, എന്നാൽ രണ്ട് ഇന്റർലോക്കുട്ടർമാരുമായുള്ള സംഭാഷണങ്ങളെക്കുറിച്ച് അതിന് ഇതുവരെ ഒന്നും അറിയില്ല. അത്തരം ഡയലോഗുകൾ ഉപയോക്താക്കൾക്കായി ടെക്സ്റ്റ് എഞ്ചിനിൽ സ്ഥിതിചെയ്യുന്നു. ഇവിടെ ഞങ്ങൾ "ഹെഡ്-ഓൺ" ഡാറ്റ എടുത്തു: ഓരോ ചാറ്റ്-എഞ്ചിൻ സംഭവങ്ങളും എല്ലാ ടെക്സ്റ്റ്-എഞ്ചിൻ സംഭവങ്ങളോടും ആവശ്യമായ ഡയലോഗ് ഉണ്ടോ എന്ന് ചോദിച്ചു.

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

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

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

ഇറക്കുമതി ചെയ്ത സന്ദേശങ്ങൾ സംഭരിക്കുന്നതിന് ഞങ്ങൾ ഒരു പ്രത്യേക ഡാറ്റാ ഘടന ഉപയോഗിക്കുന്നു.

ഇത് വലുപ്പമുള്ള ഒരു വെക്റ്ററിനെ പ്രതിനിധീകരിക്കുന്നു എല്ലാവരും എവിടെയാണ് - വ്യത്യസ്‌തവും അവരോഹണ ക്രമത്തിൽ ക്രമീകരിച്ചിരിക്കുന്നവയും മൂലകങ്ങളുടെ പ്രത്യേക ക്രമവും. സൂചികകളുള്ള ഓരോ വിഭാഗത്തിലും ഘടകങ്ങൾ അടുക്കിയിരിക്കുന്നു. അത്തരമൊരു ഘടനയിൽ ഒരു ഘടകത്തിനായി തിരയുന്നതിന് സമയമെടുക്കും മുഖാന്തിരം ബൈനറി തിരയലുകൾ. ഒരു മൂലകത്തിന്റെ കൂട്ടിച്ചേർക്കൽ അമോർട്ടൈസ് ചെയ്തു .

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

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

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

ഫലങ്ങൾ

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

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

മാത്രമല്ല, സെർവറുകളുടെ എണ്ണം ഇരട്ടിയാക്കുന്നതിനുപകരം, ഞങ്ങൾ അവയുടെ എണ്ണം പകുതിയായി കുറച്ചു - ഇപ്പോൾ യൂസർ-എഞ്ചിനും ചാറ്റ്-എഞ്ചിനും 500 ഫിസിക്കൽ മെഷീനുകളിൽ തത്സമയമാണ്, അതേസമയം പുതിയ സ്കീമിൽ ലോഡിന് വലിയ ഹെഡ്‌റൂം ഉണ്ട്. ഞങ്ങൾ ഉപകരണങ്ങളിൽ ധാരാളം പണം ലാഭിച്ചു - ഏകദേശം $ 5 ദശലക്ഷം + പ്രവർത്തന ചെലവിൽ പ്രതിവർഷം $ 750 ആയിരം.

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

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

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