ഇലാസ്റ്റിക് സെർച്ച് ഉള്ള ഒരു ഹൈലോഡ് പ്രോജക്റ്റിൽ ഒപ്റ്റിമൈസേഷൻ ലോഡ് ചെയ്യുക

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

പദ്ധതി എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഞങ്ങളുടെ ബാക്കെൻഡിൽ, ഞങ്ങളുടെ ക്ലയന്റിന്റെ വെബ്‌സൈറ്റുകളുടെയും മൊബൈൽ ആപ്ലിക്കേഷന്റെയും പ്രകടനം ഉറപ്പാക്കുന്ന സേവനങ്ങൾ ഞങ്ങൾ സൃഷ്ടിക്കുന്നു. പൊതുവായ ഘടന ഡയഗ്രാമിൽ കാണാം:

ജോലിയുടെ പ്രക്രിയയിൽ, ഞങ്ങൾ ധാരാളം ഇടപാടുകൾ പ്രോസസ്സ് ചെയ്യുന്നു: വാങ്ങലുകൾ, പേയ്‌മെന്റുകൾ, ഉപയോക്തൃ ബാലൻസുകളുള്ള പ്രവർത്തനങ്ങൾ, ഇതിനായി ഞങ്ങൾ ധാരാളം ലോഗുകൾ സംഭരിക്കുന്നു, കൂടാതെ ഈ ഡാറ്റ ബാഹ്യ സിസ്റ്റങ്ങളിലേക്ക് ഇറക്കുമതി ചെയ്യുകയും കയറ്റുമതി ചെയ്യുകയും ചെയ്യുന്നു.

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

ഹ്രസ്വ പശ്ചാത്തലം

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

ഞങ്ങൾ എല്ലാ ഡാറ്റയും Postgres-ൽ സംഭരിച്ചു: ഇടപാടുകൾ മുതൽ വാർത്തകൾ വരെ. എന്നാൽ ഉപയോക്താക്കളുടെ എണ്ണം വർദ്ധിച്ചു, അതോടൊപ്പം അഭ്യർത്ഥനകളുടെ എണ്ണവും.

മനസ്സിലാക്കുന്നതിന്, ഡെസ്‌ക്‌ടോപ്പ് സൈറ്റിൽ മാത്രം 2017-ലെ വാർഷിക സെഷനുകളുടെ എണ്ണം 131 ദശലക്ഷമാണ്. 2018-ൽ - 125 ദശലക്ഷം. 2019 വീണ്ടും 130 ദശലക്ഷം. സൈറ്റിന്റെയും മൊബൈൽ ആപ്ലിക്കേഷന്റെയും മൊബൈൽ പതിപ്പിൽ നിന്ന് മറ്റൊരു 100-200 ദശലക്ഷം ചേർക്കുക, നിങ്ങൾ ഒരുപാട് അഭ്യർത്ഥനകൾ ലഭിക്കും.

പ്രോജക്റ്റിന്റെ വളർച്ചയോടെ, പോസ്റ്റ്‌ഗ്രേസ് ലോഡുമായി പൊരുത്തപ്പെടുന്നത് നിർത്തി, ഞങ്ങൾക്ക് സമയമില്ല - ധാരാളം വിവിധ അന്വേഷണങ്ങൾ പ്രത്യക്ഷപ്പെട്ടു, അതിനായി ഞങ്ങൾക്ക് മതിയായ എണ്ണം സൂചികകൾ സൃഷ്ടിക്കാൻ കഴിഞ്ഞില്ല.

ഞങ്ങളുടെ ആവശ്യങ്ങൾ നൽകുകയും PostgreSQL-ൽ നിന്ന് ലോഡ് കുറയ്ക്കുകയും ചെയ്യുന്ന മറ്റ് ഡാറ്റ സ്റ്റോറുകളുടെ ആവശ്യമുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. ഇലാസ്റ്റിക് സെർച്ചും മോംഗോഡിബിയും സാധ്യമായ ഓപ്ഷനുകളായി പരിഗണിക്കപ്പെട്ടു. രണ്ടാമത്തേത് ഇനിപ്പറയുന്ന പോയിന്റുകളിൽ നഷ്ടപ്പെട്ടു:

1. സൂചികകളിലെ ഡാറ്റയുടെ അളവ് വർദ്ധിക്കുന്നതിനനുസരിച്ച് വേഗത കുറഞ്ഞ ഇൻഡെക്സിംഗ് വേഗത. ഇലാസ്റ്റിക് ഉപയോഗിച്ച്, വേഗത ഡാറ്റയുടെ അളവിനെ ആശ്രയിക്കുന്നില്ല.
2. പൂർണ്ണമായ വാചക തിരയലില്ല

അതിനാൽ ഞങ്ങൾ സ്വയം ഇലാസ്റ്റിക് തിരഞ്ഞെടുത്ത് പരിവർത്തനത്തിന് തയ്യാറെടുത്തു.

ഇലാസ്റ്റിക് ലേക്കുള്ള പരിവർത്തനം

1. ഞങ്ങൾ പോയിന്റ് ഓഫ് സെയിൽ തിരയൽ സേവനത്തിൽ നിന്ന് പരിവർത്തനം ആരംഭിച്ചു. ഞങ്ങളുടെ ക്ലയന്റിന് മൊത്തം 70 പോയിന്റ് വിൽപ്പനയുണ്ട്, ഇതിന് സൈറ്റിലും ആപ്ലിക്കേഷനിലും നിരവധി തരം തിരയലുകൾ ആവശ്യമാണ്:

• നഗരത്തിന്റെ പേര് ഉപയോഗിച്ച് വാചക തിരയൽ
• ഏതെങ്കിലുമൊരു ബിന്ദുവിൽ നിന്ന് ഒരു നിശ്ചിത പരിധിക്കുള്ളിൽ ജിയോസേർച്ച്. ഉദാഹരണത്തിന്, ഉപയോക്താവിന് തന്റെ വീടിന് ഏറ്റവും അടുത്തുള്ള വിൽപ്പന പോയിന്റുകൾ ഏതൊക്കെയാണെന്ന് കാണാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ.
• തന്നിരിക്കുന്ന ചതുരം ഉപയോഗിച്ച് തിരയുക - ഉപയോക്താവ് മാപ്പിൽ ഒരു ചതുരം വരയ്ക്കുന്നു, ഈ റേഡിയസിലെ എല്ലാ പോയിന്റുകളും അവനെ കാണിക്കുന്നു.
• അധിക ഫിൽട്ടറുകൾ ഉപയോഗിച്ച് തിരയുക. വിൽപ്പന പോയിന്റുകൾ ശേഖരണത്തിൽ പരസ്പരം വ്യത്യാസപ്പെട്ടിരിക്കുന്നു

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

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

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

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

ആനുകാലികത

ഇപ്പോൾ അപ്‌ഡേറ്റുകൾ ഇനിപ്പറയുന്ന വ്യവസ്ഥകൾക്കനുസരിച്ച് ഇവന്റ് അടിസ്ഥാനമാക്കി ക്രമീകരിച്ചിരിക്കുന്നു:

1. വിൽപ്പന പോയിന്റുകൾ. ഒരു ബാഹ്യ ഉറവിടത്തിൽ നിന്ന് ഞങ്ങൾക്ക് ഡാറ്റ ലഭിച്ചാലുടൻ, ഞങ്ങൾ ഉടൻ തന്നെ അപ്‌ഡേറ്റ് ആരംഭിക്കും.
2. വാർത്ത. സൈറ്റിൽ എന്തെങ്കിലും വാർത്തകൾ എഡിറ്റ് ചെയ്താലുടൻ അത് ഇലാസ്റ്റിക് എന്നതിലേക്ക് സ്വയമേവ അയയ്‌ക്കും.

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

സംയോജന രീതികൾ

ഇലാസ്റ്റിക് ഉപയോഗിച്ച് സംയോജിപ്പിക്കാൻ 2 വഴികളുണ്ട്:

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

HTTP ഇന്റർഫേസിന് നന്ദി, HTTP ക്ലയന്റിൻറെ അസമന്വിത നിർവ്വഹണം നൽകുന്ന ലൈബ്രറികൾ നമുക്ക് ഉപയോഗിക്കാം. വലിയ പ്രമോഷന്റെ ദിവസങ്ങളിൽ വളരെയധികം സഹായിച്ച ഉയർന്ന പ്രകടനത്തിന് കാരണമാകുന്ന ബാച്ചിന്റെയും അസിൻക്രണസ് എപിഐയുടെയും പ്രയോജനം നമുക്ക് പ്രയോജനപ്പെടുത്താം (താഴെയുള്ളതിൽ കൂടുതൽ)

താരതമ്യത്തിനായി ചില സംഖ്യകൾ:

• ഗ്രൂപ്പ് ചെയ്യാതെ 20 ത്രെഡുകളിൽ പോസ്റ്റ്‌ഗ്രെസ് ബൗണ്ടി ഉപയോക്താക്കളെ സംരക്ഷിക്കുന്നു: 460713 സെക്കൻഡിനുള്ളിൽ 42 റെക്കോർഡുകൾ
• 10 ത്രെഡുകൾക്കുള്ള ഇലാസ്റ്റിക് + റിയാക്ടീവ് ക്ലയന്റ് + 1000 ഘടകങ്ങൾക്കുള്ള ബാച്ച്: 596749 സെക്കൻഡിനുള്ളിൽ 11 റെക്കോർഡുകൾ
• 10 ത്രെഡുകൾക്കുള്ള ഇലാസ്റ്റിക് + റിയാക്ടീവ് ക്ലയന്റ് + 1000 ഘടകങ്ങൾക്കുള്ള ബാച്ച്: 23801684 മിനിറ്റിനുള്ളിൽ 4 എൻട്രികൾ

ഇപ്പോൾ ഞങ്ങൾ ഒരു HTTP അഭ്യർത്ഥന മാനേജർ എഴുതിയിട്ടുണ്ട്, അത് JSON-നെ ബാച്ച്/അല്ല ബാച്ച് ആയി നിർമ്മിക്കുകയും ലൈബ്രറി പരിഗണിക്കാതെ ഏതെങ്കിലും HTTP ക്ലയന്റ് വഴി അയയ്ക്കുകയും ചെയ്യുന്നു. നിങ്ങൾക്ക് അഭ്യർത്ഥനകൾ സമന്വയിപ്പിച്ചോ അസമന്വിതമായോ അയയ്ക്കാനും തിരഞ്ഞെടുക്കാം.

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

വലിയ പ്രമോഷൻ

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

സാധാരണയായി അവധി ദിവസങ്ങളിൽ ലോഡുകളുടെ കൊടുമുടികൾ ഉണ്ടാകാറുണ്ട്, എന്നാൽ ഈ പ്രമോഷൻ തികച്ചും വ്യത്യസ്തമായ തലത്തിലാണ്. കഴിഞ്ഞ വർഷം, പ്രമോഷന്റെ ദിവസം ഞങ്ങൾ 27 യൂണിറ്റ് സാധനങ്ങൾ വിറ്റു. ഡാറ്റ അരമണിക്കൂറിലധികം പ്രോസസ്സ് ചെയ്തു, ഇത് ഉപയോക്താക്കൾക്ക് അസൗകര്യമുണ്ടാക്കി. പങ്കാളിത്തത്തിന് ഉപയോക്താക്കൾക്ക് സമ്മാനങ്ങൾ ലഭിച്ചു, പക്ഷേ പ്രക്രിയ ത്വരിതപ്പെടുത്തേണ്ടതുണ്ടെന്ന് വ്യക്തമായി.

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

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

ഉപസംഹാരം / നിഗമനങ്ങൾ

ഇപ്പോൾ, ഞങ്ങൾ ആഗ്രഹിച്ച എല്ലാ സേവനങ്ങളും ഞങ്ങൾ ഇലാസ്റ്റിക് ആയി മാറ്റി, തൽക്കാലം ഇത് താൽക്കാലികമായി നിർത്തി. ഉപയോക്തൃ ലോഡ് ഏറ്റെടുക്കുന്ന Postgres-ലെ പ്രധാന പെർസിസ്റ്റന്റ് സ്റ്റോറേജിന് മുകളിൽ ഞങ്ങൾ ഇപ്പോൾ ഇലാസ്റ്റിക് ഒരു ഇൻഡക്സ് നിർമ്മിക്കുകയാണ്.

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

പ്രവർത്തനക്ഷമതയിൽ ഫുൾ-ടെക്‌സ്‌റ്റ് തിരയൽ ആവശ്യമുണ്ടെങ്കിൽ അല്ലെങ്കിൽ ഞങ്ങൾക്ക് വ്യത്യസ്ത തിരയൽ മാനദണ്ഡങ്ങൾ ഉണ്ടെങ്കിൽ, ഇത് ഇലാസ്റ്റിക് ഭാഷയിലേക്ക് വിവർത്തനം ചെയ്യേണ്ടതുണ്ടെന്ന് ഞങ്ങൾക്കറിയാം.

⌘⌘⌘

വായിച്ചതിന് നന്ദി. നിങ്ങളുടെ കമ്പനിയും ElasticSearch ഉപയോഗിക്കുകയും അതിന്റേതായ നടപ്പാക്കൽ കേസുകൾ ഉണ്ടെങ്കിൽ, ഞങ്ങളോട് പറയുക. മറ്റുള്ളവർ എങ്ങനെയാണെന്ന് അറിയുന്നത് രസകരമായിരിക്കും 🙂

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