യഥാർത്ഥ ആപ്ലിക്കേഷനുകളിൽ ClickHouse ഉപയോഗിക്കുന്നതിനുള്ള സിദ്ധാന്തവും പരിശീലനവും. അലക്സാണ്ടർ സെയ്റ്റ്സെവ് (2018)

ഇപ്പോൾ മിക്കവാറും എല്ലായിടത്തും ധാരാളം ഡാറ്റ ഉണ്ടെങ്കിലും, അനലിറ്റിക്കൽ ഡാറ്റാബേസുകൾ ഇപ്പോഴും തികച്ചും വിചിത്രമാണ്. അവ മോശമായി അറിയപ്പെടുന്നു, മാത്രമല്ല അവ ഫലപ്രദമായി ഉപയോഗിക്കാനുള്ള കഴിവും കുറവാണ്. പലരും MySQL അല്ലെങ്കിൽ PostgreSQL ഉപയോഗിച്ച് കള്ളിച്ചെടി കഴിക്കുന്നത് തുടരുന്നു, അവ മറ്റ് സാഹചര്യങ്ങൾക്കായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു, NoSQL-മായി പോരാടുന്നു, അല്ലെങ്കിൽ വാണിജ്യ പരിഹാരങ്ങൾക്കായി അമിതമായി പണം നൽകുന്നു. ClickHouse ഒരു ഗെയിം ചേഞ്ചറാണ് കൂടാതെ അനലിറ്റിക്കൽ DBMS-ന്റെ ലോകത്തേക്ക് പ്രവേശിക്കുന്നതിനുള്ള തടസ്സം ഗണ്യമായി കുറയ്ക്കുന്നു.

റിപ്പോർട്ട് BackEnd Conf 2018-ൽ നിന്നുള്ളതാണ്, അത് സ്പീക്കറുടെ അനുമതിയോടെയാണ് പ്രസിദ്ധീകരിക്കുന്നത്.

ഞാൻ ആരാണ്, എന്തുകൊണ്ടാണ് ഞാൻ ക്ലിക്ക്ഹൗസിനെക്കുറിച്ച് സംസാരിക്കുന്നത്? ClickHouse ഉപയോഗിക്കുന്ന ലൈഫ്‌സ്ട്രീറ്റിലെ ഡെവലപ്‌മെന്റ് ഡയറക്ടറാണ് ഞാൻ. ആൾട്ടിനിറ്റിയുടെ സ്ഥാപകൻ കൂടിയാണ് ഞാൻ. ഇത് ClickHouse പ്രമോട്ട് ചെയ്യുന്ന Yandex പങ്കാളിയാണ്, കൂടാതെ ClickHouse കൂടുതൽ വിജയകരമാക്കാൻ Yandex-നെ സഹായിക്കുന്നു. ClickHouse നെ കുറിച്ചുള്ള അറിവ് പങ്കുവെക്കാനും ഞാൻ തയ്യാറാണ്.

ഞാൻ പെത്യ സെയ്‌റ്റ്‌സേവിന്റെ സഹോദരനുമല്ല. എന്നോട് പലപ്പോഴും ഇതിനെക്കുറിച്ച് ചോദിക്കാറുണ്ട്. ഇല്ല, ഞങ്ങൾ സഹോദരങ്ങളല്ല.

ക്ലിക്ക്ഹൗസ് "എല്ലാവർക്കും അറിയാം":

• വളരെ വേഗം,
• വളരെ സൗകര്യപ്രദമായ,
• Yandex-ൽ ഉപയോഗിച്ചു.

ഏതൊക്കെ കമ്പനികളിൽ ഇത് എങ്ങനെ ഉപയോഗിക്കുന്നു എന്നതിനെ കുറിച്ച് അൽപ്പം കുറവാണ്.

Yandex കൂടാതെ ClickHouse എന്തിന്, എവിടെ, എങ്ങനെ ഉപയോഗിക്കുന്നു എന്ന് ഞാൻ നിങ്ങളോട് പറയും.

വ്യത്യസ്‌ത കമ്പനികളിലെ ClickHouse ഉപയോഗിച്ച് നിർദ്ദിഷ്ട പ്രശ്‌നങ്ങൾ എങ്ങനെ പരിഹരിക്കപ്പെടുന്നു, നിങ്ങളുടെ ടാസ്‌ക്കുകൾക്കായി നിങ്ങൾക്ക് എന്ത് ClickHouse ടൂളുകൾ ഉപയോഗിക്കാം, അവ വ്യത്യസ്ത കമ്പനികളിൽ എങ്ങനെ ഉപയോഗിച്ചു എന്നിവ ഞാൻ നിങ്ങളോട് പറയും.

വ്യത്യസ്ത വശങ്ങളിൽ നിന്ന് ClickHouse കാണിക്കുന്ന മൂന്ന് ഉദാഹരണങ്ങൾ ഞാൻ തിരഞ്ഞെടുത്തു. അത് രസകരമായിരിക്കുമെന്ന് ഞാൻ കരുതുന്നു.

ആദ്യത്തെ ചോദ്യം ഇതാണ്: "നിങ്ങൾക്ക് എന്തുകൊണ്ട് ClickHouse ആവശ്യമാണ്?" ചോദ്യം തികച്ചും വ്യക്തമാണെന്ന് തോന്നുന്നു, പക്ഷേ ഇതിന് ഒന്നിലധികം ഉത്തരങ്ങളുണ്ട്.

• ആദ്യ ഉത്തരം പ്രകടന കാരണങ്ങളാലാണ്. ClickHouse വളരെ വേഗതയുള്ളതാണ്. ClickHouse-ലെ അനലിറ്റിക്‌സും വളരെ വേഗതയുള്ളതാണ്. മറ്റെന്തെങ്കിലും വളരെ സാവധാനത്തിലോ വളരെ മോശമായോ പ്രവർത്തിക്കുന്നിടത്ത് ഇത് പലപ്പോഴും ഉപയോഗിക്കാം.
• രണ്ടാമത്തെ ഉത്തരം ചെലവാണ്. ഒന്നാമതായി, സ്കെയിലിംഗിന്റെ ചെലവ്. ഉദാഹരണത്തിന്, വെർട്ടിക്ക തികച്ചും മികച്ച ഒരു ഡാറ്റാബേസ് ആണ്. നിങ്ങൾക്ക് ധാരാളം ടെറാബൈറ്റ് ഡാറ്റ ഇല്ലെങ്കിൽ ഇത് വളരെ നന്നായി പ്രവർത്തിക്കുന്നു. എന്നാൽ നമ്മൾ നൂറുകണക്കിന് ടെറാബൈറ്റുകളെക്കുറിച്ചോ പെറ്റാബൈറ്റുകളെക്കുറിച്ചോ സംസാരിക്കുമ്പോൾ, ഒരു ലൈസൻസിന്റെയും പിന്തുണയുടെയും വില വളരെ പ്രധാനപ്പെട്ട തുകയാണ്. അത് ചെലവേറിയതുമാണ്. കൂടാതെ ClickHouse സൗജന്യമാണ്.
• മൂന്നാമത്തെ ഉത്തരം പ്രവർത്തന ചെലവാണ്. ഇത് അല്പം വ്യത്യസ്തമായ സമീപനമാണ്. റെഡ്ഷിഫ്റ്റ് ഒരു മികച്ച അനലോഗ് ആണ്. RedShift ഉപയോഗിച്ച് നിങ്ങൾക്ക് വളരെ വേഗത്തിൽ തീരുമാനമെടുക്കാൻ കഴിയും. ഇത് നന്നായി പ്രവർത്തിക്കും, എന്നാൽ അതേ സമയം, ഓരോ മണിക്കൂറിലും, എല്ലാ ദിവസവും, എല്ലാ മാസവും നിങ്ങൾ ആമസോണിന് ധാരാളം പണം നൽകും, കാരണം ഇത് വളരെ ചെലവേറിയ സേവനമാണ്. Google BigQuery-യും. ആരെങ്കിലും അത് ഉപയോഗിച്ചിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് അവിടെ നിരവധി ചോദ്യങ്ങൾ പ്രവർത്തിപ്പിക്കാമെന്നും നൂറുകണക്കിന് ഡോളറുകൾക്ക് പെട്ടെന്ന് ഒരു ഇൻവോയ്സ് ലഭിക്കുമെന്നും അവനറിയാം.

ClickHouse-ന് ഈ പ്രശ്നങ്ങളില്ല.

ClickHouse ഇപ്പോൾ എവിടെയാണ് ഉപയോഗിക്കുന്നത്? Yandex കൂടാതെ, ClickHouse വിവിധ ബിസിനസ്സുകളിലും കമ്പനികളിലും ഉപയോഗിക്കുന്നു.

• ഒന്നാമതായി, ഇത് വെബ് ആപ്ലിക്കേഷൻ അനലിറ്റിക്സ് ആണ്, അതായത് ഇത് Yandex-ൽ നിന്ന് വന്ന ഒരു ഉപയോഗ കേസാണ്.
• പല AdTech കമ്പനികളും ClickHouse ഉപയോഗിക്കുന്നു.
• വിവിധ സ്രോതസ്സുകളിൽ നിന്നുള്ള പ്രവർത്തന ലോഗുകൾ വിശകലനം ചെയ്യേണ്ട നിരവധി കമ്പനികൾ.
• സുരക്ഷാ ലോഗുകൾ നിരീക്ഷിക്കാൻ നിരവധി കമ്പനികൾ ClickHouse ഉപയോഗിക്കുന്നു. അവർ അവയെ ClickHouse-ലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും റിപ്പോർട്ടുകൾ തയ്യാറാക്കുകയും അവർക്ക് ആവശ്യമായ ഫലങ്ങൾ നേടുകയും ചെയ്യുന്നു.
• സാമ്പത്തിക വിശകലനത്തിൽ കമ്പനികൾ ഇത് ഉപയോഗിക്കാൻ തുടങ്ങുന്നു, അതായത് ക്രമേണ വലിയ ബിസിനസുകളും ClickHouse-നെ സമീപിക്കുന്നു.
• CloudFlare. ആരെങ്കിലും ClickHouse പിന്തുടരുകയാണെങ്കിൽ, നിങ്ങൾ ഈ കമ്പനിയുടെ പേര് കേട്ടിരിക്കാം. കമ്മ്യൂണിറ്റിയിൽ നിന്നുള്ള പ്രധാന സംഭാവനകളിൽ ഒരാളാണ് ഇത്. അവർക്ക് വളരെ ഗുരുതരമായ ClickHouse ഇൻസ്റ്റാളേഷൻ ഉണ്ട്. ഉദാഹരണത്തിന്, ക്ലിക്ക്ഹൗസിനായി അവർ കാഫ്ക എഞ്ചിൻ ഉണ്ടാക്കി.
• ടെലികമ്മ്യൂണിക്കേഷൻ കമ്പനികൾ ഉപയോഗിക്കാൻ തുടങ്ങി. നിരവധി കമ്പനികൾ ക്ലിക്ക്ഹൗസ് ആശയത്തിന്റെ തെളിവായി അല്ലെങ്കിൽ ഇതിനകം നിർമ്മാണത്തിലുണ്ട്.
• ഉൽപ്പാദന പ്രക്രിയകൾ നിരീക്ഷിക്കാൻ ഒരു കമ്പനി ClickHouse ഉപയോഗിക്കുന്നു. അവർ മൈക്രോ സർക്യൂട്ടുകൾ പരീക്ഷിക്കുന്നു, ഒരു കൂട്ടം പാരാമീറ്ററുകൾ എഴുതിത്തള്ളുന്നു, ഏകദേശം 2 സവിശേഷതകൾ ഉണ്ട്. എന്നിട്ട് അവർ ബാച്ച് നല്ലതാണോ ചീത്തയാണോ എന്ന് വിശകലനം ചെയ്യുന്നു.
• ബ്ലോക്ക്ചെയിൻ അനലിറ്റിക്സ്. Bloxy.info എന്ന റഷ്യൻ കമ്പനിയുണ്ട്. ഇത് Ethereum നെറ്റ്‌വർക്കിന്റെ വിശകലനമാണ്. ക്ലിക്ക്ഹൗസിലും അവർ ഇത് ചെയ്തു.

മാത്രമല്ല, വലിപ്പം പ്രശ്നമല്ല. ഒരു ചെറിയ സെർവർ ഉപയോഗിക്കുന്ന നിരവധി കമ്പനികളുണ്ട്. അവരുടെ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ അവൻ അവരെ അനുവദിക്കുന്നു. കൂടുതൽ കമ്പനികൾ നിരവധി സെർവറുകൾ അല്ലെങ്കിൽ ഡസൻ കണക്കിന് സെർവറുകളുടെ വലിയ ക്ലസ്റ്ററുകൾ ഉപയോഗിക്കുന്നു.

നിങ്ങൾ രേഖകൾ നോക്കുകയാണെങ്കിൽ, പിന്നെ:

• Yandex: 500+ സെർവറുകൾ, അവർ അവിടെ ഒരു ദിവസം 25 ബില്ല്യൺ റെക്കോർഡുകൾ സംഭരിക്കുന്നു.
• ലൈഫ് സ്ട്രീറ്റ്: 60 സെർവറുകൾ, പ്രതിദിനം ഏകദേശം 75 ബില്യൺ റെക്കോർഡുകൾ. Yandex-ൽ ഉള്ളതിനേക്കാൾ കുറച്ച് സെർവറുകളും കൂടുതൽ റെക്കോർഡുകളും ഉണ്ട്.
• CloudFlare: 36 സെർവറുകൾ, അവർ പ്രതിദിനം 200 ബില്യൺ റെക്കോർഡുകൾ സംഭരിക്കുന്നു. അവർക്ക് കുറച്ച് സെർവറുകൾ മാത്രമേയുള്ളൂ, കൂടുതൽ ഡാറ്റ സംഭരിക്കുന്നു.
• ബ്ലൂംബെർഗ്: 102 സെർവറുകൾ, പ്രതിദിനം ഏകദേശം ഒരു ട്രില്യൺ റെക്കോർഡുകൾ. റെക്കോർഡ് ഉടമ.

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

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

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

നിരവധി കമ്പനികളിൽ ClickHouse-ന്റെ യഥാർത്ഥ ഉപയോഗത്തിന്റെ ഉദാഹരണങ്ങളാണിവ.

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

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

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

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

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

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

മറുവശത്ത്, ഓപ്പൺ സോഴ്‌സ് സൊല്യൂഷനുകളുണ്ട്, അവയിൽ അധികമില്ല, അതായത് അനലിറ്റിക്‌സിന് അവ ഒരു വശത്ത് കണക്കാക്കാം. അവ സൗജന്യമോ വിലകുറഞ്ഞതോ ആണ്, പക്ഷേ അവ സാവധാനത്തിൽ പ്രവർത്തിക്കുന്നു. അവയ്ക്ക് പലപ്പോഴും ആവശ്യമായതും ഉപയോഗപ്രദവുമായ പ്രവർത്തനക്ഷമതയില്ല.

വാണിജ്യ ഡാറ്റാബേസുകളിലുള്ള നല്ല കാര്യങ്ങളും ഓപ്പൺ സോഴ്‌സിലെ എല്ലാ സൗജന്യ കാര്യങ്ങളും സംയോജിപ്പിക്കാൻ ഒന്നുമില്ല.

ഒരു മാന്ത്രികന്റെ മുയലിനെപ്പോലെ Yandex പെട്ടെന്ന് ക്ലിക്ക്ഹൗസ് തൊപ്പിയിൽ നിന്ന് പുറത്തെടുക്കുന്നതുവരെ ഒന്നും സംഭവിച്ചില്ല. ഇതൊരു അപ്രതീക്ഷിത തീരുമാനമായിരുന്നു; ആളുകൾ ഇപ്പോഴും ചോദ്യം ചോദിക്കുന്നു: "എന്തുകൊണ്ട്?", എന്നിരുന്നാലും.

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

ഞാൻ വളരെ മടിയനായിരുന്നില്ല, കഴിഞ്ഞ ദിവസം കൂടുതൽ Yandex ടെസ്റ്റുകൾ നോക്കി. അവിടെയും ഇതുതന്നെയാണ്: ക്ലിക്ക്ഹൗസ് വെർട്ടിക്കയേക്കാൾ ഇരട്ടി വേഗതയുള്ളതാണ്, അതിനാൽ അവർ പലപ്പോഴും അതിനെക്കുറിച്ച് സംസാരിക്കുന്നു.

എന്നാൽ ചോദ്യങ്ങളിൽ ചേരലുകൾ അടങ്ങിയിട്ടുണ്ടെങ്കിൽ, എല്ലാം വളരെ വ്യക്തമല്ല. കൂടാതെ ClickHouse വെർട്ടിക്കയുടെ ഇരട്ടി സ്ലോ ആയിരിക്കാം. നിങ്ങൾ അഭ്യർത്ഥന കുറച്ച് ശരിയാക്കി മാറ്റിയെഴുതുകയാണെങ്കിൽ, അവ ഏകദേശം തുല്യമായിരിക്കും. മോശമല്ല. അത് സൗജന്യവുമാണ്.

കൂടാതെ പരിശോധനാ ഫലങ്ങൾ ലഭിച്ച്, വിവിധ കോണുകളിൽ നിന്ന് നോക്കിയതിന് ശേഷം ലൈഫ്സ്ട്രീറ്റ് ക്ലിക്ക്ഹൗസിലേക്ക് പോയി.

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

അതിനാൽ, ഞാൻ ഇതിനെക്കുറിച്ച് വിശദമായി സംസാരിക്കില്ല, ഞാൻ അന്ന് സംസാരിക്കാത്ത ഫലങ്ങളെയും രസകരമായ കുറച്ച് കാര്യങ്ങളെയും കുറിച്ച് മാത്രമേ സംസാരിക്കൂ.

ഫലങ്ങൾ ഇവയാണ്:

• വിജയകരമായ കുടിയേറ്റവും സംവിധാനവും ഒരു വർഷത്തിലേറെയായി ഉൽപ്പാദനത്തിലാണ്.
• ഉൽപ്പാദനക്ഷമതയും വഴക്കവും വർദ്ധിച്ചു. ചുരുങ്ങിയ സമയത്തേക്ക് മാത്രം നമുക്ക് പ്രതിദിനം സംഭരിക്കാൻ കഴിയുന്ന 10 ബില്ല്യൺ റെക്കോർഡുകളിൽ നിന്ന്, LifeStreet ഇപ്പോൾ പ്രതിദിനം 75 ബില്ല്യൺ റെക്കോർഡുകൾ സംഭരിക്കുന്നു, 3 മാസമോ അതിലധികമോ സമയത്തേക്ക് അങ്ങനെ ചെയ്യാൻ കഴിയും. നിങ്ങൾ ഏറ്റവും ഉയർന്ന നിലയിൽ കണക്കാക്കുകയാണെങ്കിൽ, ഇത് സെക്കൻഡിൽ ഒരു ദശലക്ഷം ഇവന്റുകൾ വരെ സംഭരിക്കും. ഒരു ദിവസം ഒരു ദശലക്ഷത്തിലധികം SQL അന്വേഷണങ്ങൾ ഈ സിസ്റ്റത്തിൽ എത്തുന്നു, കൂടുതലും വിവിധ റോബോട്ടുകളിൽ നിന്നാണ്.
• ക്ലിക്ക്ഹൗസ് വെർട്ടിക്കയേക്കാൾ കൂടുതൽ സെർവറുകൾ ഉപയോഗിക്കാൻ തുടങ്ങിയിട്ടും, ഹാർഡ്‌വെയറിലും സേവിംഗ്സ് നടത്തി, കാരണം വെർട്ടിക്ക വളരെ ചെലവേറിയ എസ്‌എഎസ് ഡിസ്കുകൾ ഉപയോഗിച്ചു. ClickHouse SATA ഉപയോഗിച്ചു. എന്തുകൊണ്ട്? കാരണം വെർട്ടിക്കയിൽ ഇൻസേർട്ട് സിൻക്രണസ് ആണ്. സമന്വയത്തിന് ഡിസ്കുകൾ വളരെ മന്ദഗതിയിലാകാതിരിക്കാനും നെറ്റ്‌വർക്ക് വളരെയധികം മന്ദഗതിയിലാകാതിരിക്കാനും ആവശ്യമാണ്, അതായത്, വളരെ ചെലവേറിയ പ്രവർത്തനം. ക്ലിക്ക്ഹൗസിൽ ഇൻസേർട്ട് അസിൻക്രണസ് ആണ്. മാത്രമല്ല, നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും എല്ലാം പ്രാദേശികമായി എഴുതാൻ കഴിയും, ഇതിന് അധിക ചിലവുകളൊന്നുമില്ല, അതിനാൽ വേഗതയേറിയ ഡിസ്കുകളിൽ പോലും വെർട്ടികയേക്കാൾ വളരെ വേഗത്തിൽ ക്ലിക്ക്ഹൗസിലേക്ക് ഡാറ്റ ചേർക്കാൻ കഴിയും. വായനയും ഏതാണ്ട് സമാനമാണ്. SATA-യിൽ വായിക്കുന്നത്, അവർ റെയ്ഡിലാണെങ്കിൽ, എല്ലാം വേഗത്തിൽ മതിയാകും.
• ലൈസൻസ് പ്രകാരം പരിധിയില്ലാത്തത്, അതായത് 3 സെർവറുകളിലെ 60 പെറ്റാബൈറ്റ് ഡാറ്റയും (20 സെർവറുകൾ ഒരു പകർപ്പാണ്) കൂടാതെ വസ്തുതകളിലും സംഗ്രഹങ്ങളിലും 6 ട്രില്യൺ റെക്കോർഡുകൾ. വെർട്ടിക്കയ്ക്ക് ഇതുപോലൊന്ന് താങ്ങാൻ കഴിഞ്ഞില്ല.

ഇപ്പോൾ ഞാൻ ഈ ഉദാഹരണത്തിലെ പ്രായോഗിക കാര്യങ്ങളിലേക്ക് കടക്കുകയാണ്.

• ആദ്യത്തേത് ഫലപ്രദമായ ഒരു പദ്ധതിയാണ്. ഒരുപാട് സ്കീമിനെ ആശ്രയിച്ചിരിക്കുന്നു.
• രണ്ടാമത്തേത് കാര്യക്ഷമമായ SQL സൃഷ്ടിക്കുന്നു.

ഒരു സാധാരണ OLAP അന്വേഷണം തിരഞ്ഞെടുത്തിരിക്കുന്നു. ചില കോളങ്ങൾ ഗ്രൂപ്പ് ബൈയിലേക്കും ചില കോളങ്ങൾ മൊത്തം ഫംഗ്‌ഷനുകളിലേക്കും പോകുന്നു. ഒരു ക്യൂബിന്റെ സ്ലൈസ് ആയി കരുതാവുന്ന ഒരിടമുണ്ട്. മുഴുവൻ ഗ്രൂപ്പും ഒരു പ്രൊജക്ഷൻ ആയി കണക്കാക്കാം. അതുകൊണ്ടാണ് ഇതിനെ മൾട്ടിവേരിയേറ്റ് ഡാറ്റ വിശകലനം എന്ന് വിളിക്കുന്നത്.

പലപ്പോഴും ഇത് ഒരു നക്ഷത്ര ഡയഗ്രം രൂപത്തിലാണ് രൂപപ്പെടുത്തിയിരിക്കുന്നത്, ഈ വസ്തുതയുടെ ഒരു കേന്ദ്ര വസ്തുതയും സവിശേഷതകളും വശങ്ങളിൽ, കിരണങ്ങൾക്കൊപ്പം ഉണ്ടാകുമ്പോൾ.

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

എന്നാൽ ClickHouse-ൽ ഇത് നന്നായി പ്രവർത്തിക്കുന്നില്ല. രണ്ട് കാരണങ്ങളുണ്ട്:

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

ക്ലിക്ക്ഹൗസിൽ ഇതിനൊരു പോംവഴിയുണ്ട്. രണ്ട് പോലും:

• ആദ്യത്തേത് നിഘണ്ടുക്കളുടെ ഉപയോഗമാണ്. സ്റ്റാർ സ്‌കീമിലെ പ്രശ്‌നം പരിഹരിക്കാൻ 99% സഹായിക്കുന്നത് എക്‌സ്‌റ്റേണൽ ഡിക്ഷണറികളാണ്, അപ്‌ഡേറ്റുകളും മറ്റും.
• രണ്ടാമത്തേത് അറേകളുടെ ഉപയോഗമാണ്. നോർമലൈസേഷനിലെ ജോയിനുകളും പ്രശ്നങ്ങളും ഒഴിവാക്കാൻ അറേകൾ സഹായിക്കുന്നു.

• ചേരേണ്ട ആവശ്യമില്ല.
• അപ്ഡേറ്റ് ചെയ്യാവുന്നത്. 2018 മാർച്ച് മുതൽ, നിഘണ്ടുക്കൾ ഭാഗികമായി അപ്ഡേറ്റ് ചെയ്യുന്നതിനുള്ള ഒരു രേഖപ്പെടുത്താത്ത അവസരം (നിങ്ങൾ ഇത് ഡോക്യുമെന്റേഷനിൽ കാണില്ല) പ്രത്യക്ഷപ്പെട്ടു, അതായത് മാറിയ എൻട്രികൾ. പ്രായോഗികമായി, ഇത് ഒരു മേശ പോലെയാണ്.
• എല്ലായ്പ്പോഴും മെമ്മറിയിൽ, അതിനാൽ ഡിസ്കിൽ കിടക്കുന്ന ഒരു ടേബിളിനേക്കാൾ വേഗത്തിൽ ഒരു നിഘണ്ടു ജോലിയുമായി ചേരുന്നു, അത് കാഷെയിലാണെന്നത് ഒരു വസ്തുതയല്ല, മിക്കവാറും അല്ല.

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

ഇത് വാക്കുകൾക്ക് വേണ്ടിയല്ല. വളരെ ലളിതമായും ഗംഭീരമായും പല കാര്യങ്ങളും ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്ന വളരെ ശക്തമായ ഒരു പ്രവർത്തനമാണിത്.

അറേകൾ പരിഹരിക്കാൻ സഹായിക്കുന്ന സാധാരണ ഉദാഹരണങ്ങൾ. ഈ ഉദാഹരണങ്ങൾ ലളിതവും വ്യക്തവുമാണ്:

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

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

എന്നാൽ ClickHouse-ൽ നിങ്ങൾ ഒന്നും ചെയ്യേണ്ടതില്ല, ഹാഷ്‌ടാഗുകൾക്കായി ഒരു സ്ട്രിംഗ് അറേ വിവരിക്കുക അല്ലെങ്കിൽ കീ-മൂല്യം സിസ്റ്റങ്ങൾക്കായി ഒരു നെസ്റ്റഡ് ഘടന സൃഷ്ടിക്കുക.

ഒരു നെസ്റ്റഡ് ഘടന മികച്ച പേരായിരിക്കില്ല. പേരിന്റെ പൊതുവായ ഭാഗവും ചില അനുബന്ധ സവിശേഷതകളും ഉള്ള രണ്ട് അറേകളാണിത്.

ടാഗ് ഉപയോഗിച്ച് തിരയുന്നത് വളരെ എളുപ്പമാണ്. ഒരു ചടങ്ങുണ്ട് has, അറേയിൽ ഒരു ഘടകം അടങ്ങിയിട്ടുണ്ടോ എന്ന് പരിശോധിക്കുന്നു. എല്ലാവരും, ഞങ്ങളുടെ കോൺഫറൻസുമായി ബന്ധപ്പെട്ട എല്ലാ എൻട്രികളും ഞങ്ങൾ കണ്ടെത്തി.

Subid ഉപയോഗിച്ച് തിരയുന്നത് കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. നമ്മൾ ആദ്യം കീയുടെ സൂചിക കണ്ടെത്തേണ്ടതുണ്ട്, തുടർന്ന് ഈ സൂചിക ഉപയോഗിച്ച് ഘടകം എടുത്ത് ഈ മൂല്യം നമുക്ക് ആവശ്യമാണോ എന്ന് പരിശോധിക്കുക. എന്നിരുന്നാലും വളരെ ലളിതവും ഒതുക്കമുള്ളതുമാണ്.

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

മറ്റൊരു ഉദാഹരണം. നിങ്ങൾ ഐഡികൾ സംഭരിക്കുന്ന ഒരു അറേയുണ്ട്. നിങ്ങൾക്ക് അവയെ പേരുകളിലേക്ക് വിവർത്തനം ചെയ്യാൻ കഴിയും. ഫംഗ്ഷൻ arrayMap. ഇതൊരു സാധാരണ ലാംഡ ഫംഗ്‌ഷനാണ്. നിങ്ങൾ അവിടെ ലാംഡ എക്സ്പ്രഷനുകൾ പാസാക്കുന്നു. അവൾ നിഘണ്ടുവിൽ നിന്ന് ഓരോ ഐഡിയുടെയും പേരിന്റെ മൂല്യം പുറത്തെടുക്കുന്നു.

നിങ്ങൾക്ക് അതേ രീതിയിൽ ഒരു തിരയൽ നടത്താം. ഒരു പ്രെഡിക്കേറ്റ് ഫംഗ്‌ഷൻ കടന്നുപോകുന്നു, അത് ഘടകങ്ങൾ പൊരുത്തപ്പെടുന്നത് പരിശോധിക്കുന്നു.

ഈ കാര്യങ്ങൾ സർക്യൂട്ടിനെ വളരെയധികം ലളിതമാക്കുകയും ഒരു കൂട്ടം പ്രശ്നങ്ങൾ പരിഹരിക്കുകയും ചെയ്യുന്നു.

എന്നാൽ ഞങ്ങൾ നേരിട്ട അടുത്ത പ്രശ്നം കാര്യക്ഷമമായ അന്വേഷണങ്ങളാണ്.

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

ലളിതമായ സന്ദർഭങ്ങളിൽ പോലും, ചിലപ്പോൾ നിങ്ങൾ ഷെഡ്യൂളറുടെ ജോലി ചെയ്യുകയും ചോദ്യങ്ങൾ അൽപ്പം തിരുത്തിയെഴുതുകയും ചെയ്യേണ്ടതുണ്ട്.

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

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

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

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

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

നമുക്ക് അടുത്ത ഉദാഹരണത്തിലേക്ക് കടക്കാം. യുഎസ്എയിൽ നിന്നുള്ള കമ്പനി X. അവൾ എന്താണ് ചെയ്യുന്നത്?

ഒരു ടാസ്ക് ഉണ്ടായിരുന്നു:

• പരസ്യ ഇടപാടുകളുടെ ഓഫ്‌ലൈൻ ലിങ്കിംഗ്.
• വ്യത്യസ്ത ബൈൻഡിംഗ് മോഡലുകളുടെ സിമുലേഷൻ.

എന്താണ് രംഗം?

ഒരു സാധാരണ സന്ദർശകൻ സൈറ്റ് സന്ദർശിക്കുന്നു, ഉദാഹരണത്തിന്, വ്യത്യസ്ത പരസ്യങ്ങളിൽ നിന്ന് മാസത്തിൽ 20 തവണ, അല്ലെങ്കിൽ ചിലപ്പോൾ അവൻ പരസ്യങ്ങളൊന്നുമില്ലാതെ വരുന്നു, കാരണം അവൻ ഈ സൈറ്റ് ഓർക്കുന്നു. ചില ഉൽപ്പന്നങ്ങൾ നോക്കുന്നു, കൊട്ടയിൽ ഇടുന്നു, കൊട്ടയിൽ നിന്ന് പുറത്തെടുക്കുന്നു. അവസാനം, അവൻ എന്തെങ്കിലും വാങ്ങുന്നു.

ന്യായമായ ചോദ്യങ്ങൾ: "ആവശ്യമെങ്കിൽ ആരാണ് പരസ്യത്തിന് പണം നൽകേണ്ടത്?" കൂടാതെ "എന്ത് പരസ്യമാണ് അവനെ സ്വാധീനിച്ചതെങ്കിൽ?" അതായത്, അവൻ എന്തിനാണ് വാങ്ങിയത്, ഈ വ്യക്തിയോട് സാമ്യമുള്ള ആളുകളും വാങ്ങുന്നുവെന്ന് എങ്ങനെ ഉറപ്പാക്കാം?

ഈ പ്രശ്നം പരിഹരിക്കുന്നതിന്, നിങ്ങൾ വെബ്സൈറ്റിൽ സംഭവിക്കുന്ന ഇവന്റുകൾ ശരിയായ രീതിയിൽ ബന്ധിപ്പിക്കേണ്ടതുണ്ട്, അതായത്, എങ്ങനെയെങ്കിലും അവയ്ക്കിടയിൽ ഒരു കണക്ഷൻ ഉണ്ടാക്കുക. തുടർന്ന് അവ വിശകലനത്തിനായി DWH-ലേക്ക് മാറ്റുന്നു. ഈ വിശകലനത്തെ അടിസ്ഥാനമാക്കി, ആർക്ക് എന്ത് പരസ്യം കാണിക്കണം എന്നതിന്റെ മാതൃകകൾ നിർമ്മിക്കുക.

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

നിരവധി ബൈൻഡിംഗ് മോഡലുകൾ ഉണ്ട്.

ഏറ്റവും ജനപ്രിയമായവ ഇവയാണ്:

• അവസാന ഇടപെടൽ, ഇവിടെ ഇടപെടൽ ഒന്നുകിൽ ഒരു ക്ലിക്ക് അല്ലെങ്കിൽ ഇംപ്രഷൻ ആണ്.
• ആദ്യ ഇടപെടൽ, അതായത് ഒരു വ്യക്തിയെ സൈറ്റിലേക്ക് കൊണ്ടുവന്ന ആദ്യ കാര്യം.
• ലീനിയർ കോമ്പിനേഷൻ - എല്ലാവർക്കും തുല്യ വിഹിതം.
• ശോഷണം.
• ഇത്യാദി.

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

അഭ്യർത്ഥനയിൽ ഒരു ഇടപാട് ഐഡി അടങ്ങിയിരിക്കുന്നത് നിങ്ങൾ ഭാഗ്യവാനാണെങ്കിൽ, ഇത് എളുപ്പമാണ്. എന്നാൽ സാധാരണയായി നിങ്ങൾക്ക് ഭാഗ്യമുണ്ടാകില്ല. അതിനാൽ, അവസാന ഇടപാട് അല്ലെങ്കിൽ അവസാന ക്ലിക്കിലൂടെ ഇടപാട് മുതലായവ കണ്ടെത്തേണ്ടത് ആവശ്യമാണ്.

ലിങ്കിംഗ് അവസാന ക്ലിക്കിലേക്ക് ആകുന്നതുവരെ എല്ലാം നന്നായി പ്രവർത്തിച്ചു. കാരണം, നിങ്ങൾ ഒരു മാസത്തേക്ക് ഒരു വിൻഡോ സജ്ജീകരിച്ചാൽ, പ്രതിദിനം 10 ദശലക്ഷം ക്ലിക്കുകൾ ഉണ്ട്, പ്രതിമാസം 300 ദശലക്ഷം. വേഗത്തിൽ പ്രവർത്തിക്കാൻ കസാന്ദ്രയിൽ എല്ലാം മെമ്മറിയിൽ ഉണ്ടായിരിക്കേണ്ടതിനാൽ, വേഗത്തിൽ പ്രതികരിക്കാൻ റൺടൈം ആവശ്യമുള്ളതിനാൽ, ഏകദേശം 10-15 സെർവറുകൾ ആവശ്യമാണ്.

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

ഞങ്ങൾ ക്ലിക്ക്ഹൗസിലേക്ക് പോയി. ClickHouse-ൽ ഇത് എങ്ങനെ ചെയ്യാം? ഒറ്റനോട്ടത്തിൽ, ഇതൊരു ആന്റിപാറ്റേണുകളുടെ കൂട്ടമാണെന്ന് തോന്നുന്നു.

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

അതായത്, ആന്റിപാറ്റേണുകളുടെ ഒരു കൂട്ടം.

എന്നിരുന്നാലും, വളരെ നന്നായി പ്രവർത്തിക്കുന്ന ഒരു സിസ്റ്റം സൃഷ്ടിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു.

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

ഈ രൂപത്തിൽ അത് നന്നായി പ്രവർത്തിച്ചില്ല. കൂടാതെ ClickHouse-ന് ഇത് എളുപ്പമാക്കുന്നതിന്, ഒരു സന്ദർശന ഐഡിക്ക് ഒരു അഭ്യർത്ഥന ഉണ്ടായപ്പോൾ, അവർ ഈ അഭ്യർത്ഥനകളെ 1-000 വിസിറ്റ് ഐഡികളുടെ ബ്ലോക്കുകളായി തരംതിരിക്കുകയും 2-000 ആളുകൾക്കുള്ള എല്ലാ ഇടപാടുകളും പിൻവലിക്കുകയും ചെയ്തു. പിന്നെ എല്ലാം പ്രവർത്തിച്ചു.

നിങ്ങൾ ClickHouse-ന്റെ ഉള്ളിലേക്ക് നോക്കിയാൽ, 3 പ്രധാന ടേബിളുകൾ മാത്രമേ ഇവയെല്ലാം നൽകുന്നുള്ളൂ.

ലോഗുകൾ അപ്‌ലോഡ് ചെയ്‌ത ആദ്യ പട്ടിക, ഫലത്തിൽ പ്രോസസ്സിംഗ് ഇല്ലാതെ തന്നെ ലോഗുകൾ അപ്‌ലോഡ് ചെയ്യുന്നു.

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

ഇവിടെ വാചകം SQL ൽ എഴുതിയിരിക്കുന്നു. അതിൽ പ്രധാനപ്പെട്ട പല കാര്യങ്ങളിലും അഭിപ്രായം പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

json-ൽ നിന്ന് കോളങ്ങളും ഫീൽഡുകളും എക്‌സ്‌ട്രാക്‌റ്റ് ചെയ്യാനുള്ള ClickHouse-ലെ കഴിവാണ് ആദ്യത്തെ പ്രധാന കാര്യം. അതായത്, ക്ലിക്ക്ഹൗസിന് json-നൊപ്പം പ്രവർത്തിക്കാൻ ചില രീതികളുണ്ട്. അവ വളരെ വളരെ പ്രാകൃതമാണ്.

visitParamExtractInt നിങ്ങളെ json-ൽ നിന്ന് ആട്രിബ്യൂട്ടുകൾ എക്‌സ്‌ട്രാക്‌റ്റുചെയ്യാൻ അനുവദിക്കുന്നു, അതായത് ആദ്യത്തെ ഹിറ്റ് ട്രിഗർ ചെയ്‌തു. ഇതുവഴി നിങ്ങൾക്ക് ഇടപാട് ഐഡി അല്ലെങ്കിൽ വിസിറ്റ് ഐഡി പുറത്തെടുക്കാം. ഇത്തവണ.

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

ഈ സാഹചര്യത്തിൽ, അസംസ്കൃത സ്ട്രിംഗുകൾക്കുള്ളതാണ് മെറ്റീരിയലൈസ്ഡ് വ്യൂ. ഏതാണ്ട് അസംസ്കൃത ലോഗുകളുള്ള ആദ്യ പട്ടിക ഉപയോഗിക്കുന്നു. പിന്നെ അത് എന്ത് ചെയ്യുന്നു? ഒന്നാമതായി, ഇത് സോർട്ടിംഗിനെ മാറ്റുന്നു, അതായത് സോർട്ടിംഗ് ഇപ്പോൾ വിസിറ്റ് ഐഡി ഉപയോഗിച്ചാണ് ചെയ്യുന്നത്, കാരണം ഒരു നിർദ്ദിഷ്ട വ്യക്തിക്ക് വേണ്ടിയുള്ള അവന്റെ ഇടപാട് ഞങ്ങൾ വേഗത്തിൽ പിൻവലിക്കേണ്ടതുണ്ട്.

രണ്ടാമത്തെ പ്രധാന കാര്യം സൂചിക_ഗ്രാനുലാരിറ്റിയാണ്. നിങ്ങൾ MergeTree കണ്ടിട്ടുണ്ടെങ്കിൽ, സാധാരണയായി ഡിഫോൾട്ട് മൂല്യം 8 index_granularity ആണ്. അത് എന്താണ്? ഇതാണ് സൂചിക സ്പാർസിറ്റി പാരാമീറ്റർ. ClickHouse-ൽ, സൂചിക വിരളമാണ്; അത് ഒരിക്കലും എല്ലാ റെക്കോർഡുകളും സൂചികയിലാക്കുന്നില്ല. ഓരോ 192-ലും ഇത് ചെയ്യുന്നു. നിങ്ങൾക്ക് ധാരാളം ഡാറ്റ കണക്കാക്കേണ്ടിവരുമ്പോൾ ഇത് നല്ലതാണ്, പക്ഷേ നിങ്ങൾക്ക് കുറച്ച് കണക്കാക്കേണ്ടിവരുമ്പോൾ ഇത് മോശമാണ്, കാരണം ധാരാളം ഓവർഹെഡ് ഉണ്ട്. ഞങ്ങൾ സൂചിക ഗ്രാനുലാരിറ്റി കുറയ്ക്കുകയാണെങ്കിൽ, ഞങ്ങൾ ഓവർഹെഡ് കുറയ്ക്കുന്നു. നിങ്ങൾക്ക് ഇത് ഒന്നായി കുറയ്ക്കാൻ കഴിയില്ല, കാരണം മതിയായ മെമ്മറി ഇല്ലായിരിക്കാം. സൂചിക എപ്പോഴും മെമ്മറിയിൽ സൂക്ഷിക്കുന്നു.

സ്നാപ്പ്ഷോട്ട് മറ്റ് ചില രസകരമായ ClickHouse ഫംഗ്ഷനുകൾ ഉപയോഗിക്കുന്നു.

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

• ബൈൻഡിംഗ് റൺടൈമിൽ നിന്ന് "അവ്യക്തമാണ്".
• പ്രതിമാസം 3 ബില്യൺ ഇടപാടുകൾ വരെ സംഭരിക്കുകയും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു. ഇത് കസാന്ദ്രയേക്കാൾ വലിയ അളവിലുള്ള ഒരു ക്രമമാണ്, അതായത്, ഒരു സാധാരണ ഇടപാട് സംവിധാനത്തിൽ.
• 2x5 ക്ലിക്ക്ഹൗസ് സെർവറുകളുടെ ക്ലസ്റ്റർ. 5 സെർവറുകൾ, ഓരോ സെർവറിനും ഒരു പകർപ്പുണ്ട്. ക്ലിക്ക് അധിഷ്‌ഠിത ആട്രിബ്യൂഷൻ ചെയ്യുന്നതിനായി ഇത് കസാന്ദ്രയിൽ ഉണ്ടായിരുന്നതിനേക്കാൾ കുറവാണ്, എന്നാൽ ഇവിടെ നമുക്ക് ഇംപ്രഷൻ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. അതായത്, സെർവറുകളുടെ എണ്ണം 30 മടങ്ങ് വർദ്ധിപ്പിക്കുന്നതിന് പകരം അവ കുറച്ചു.

അവസാനത്തെ ഉദാഹരണം ഫിനാൻഷ്യൽ കമ്പനിയായ Y ആണ്, അത് സ്റ്റോക്ക് വിലകളിലെ മാറ്റങ്ങളുടെ പരസ്പര ബന്ധങ്ങൾ വിശകലനം ചെയ്തു.

ചുമതല ഇതായിരുന്നു:

• ഏകദേശം 5 ഷെയറുകളുണ്ട്.
• ഓരോ 100 മില്ലിസെക്കൻഡിലും ഉദ്ധരണികൾ അറിയാം.
• 10 വർഷത്തിലേറെയായി ഡാറ്റ ശേഖരിച്ചു. പ്രത്യക്ഷത്തിൽ, ചില കമ്പനികൾക്ക് ഇത് കൂടുതലാണ്, ചിലർക്ക് ഇത് കുറവാണ്.
• മൊത്തത്തിൽ ഏകദേശം 100 ബില്യൺ വരികളുണ്ട്.

മാറ്റങ്ങളുടെ പരസ്പരബന്ധം കണക്കാക്കേണ്ടത് ആവശ്യമാണ്.

രണ്ട് ഓഹരികളും അവയുടെ ഉദ്ധരണികളും ഇവിടെയുണ്ട്. ഒന്ന് മുകളിലേക്ക് പോകുകയും മറ്റൊന്ന് ഉയരുകയും ചെയ്യുന്നുവെങ്കിൽ, ഇത് ഒരു പോസിറ്റീവ് കോറിലേഷനാണ്, അതായത് ഒന്ന് മുകളിലേക്ക് പോകുകയും മറ്റൊന്ന് ഉയരുകയും ചെയ്യുന്നു. ഗ്രാഫിന്റെ അവസാനത്തിലെന്നപോലെ ഒന്ന് മുകളിലേക്ക് പോകുകയും മറ്റൊന്ന് താഴേക്ക് പോകുകയും ചെയ്താൽ, ഇത് ഒരു നെഗറ്റീവ് കോറിലേഷൻ ആണ്, അതായത് ഒന്ന് മുകളിലേക്ക് പോകുമ്പോൾ മറ്റൊന്ന് താഴേക്ക് പോകുന്നു.

ഈ പരസ്പര മാറ്റങ്ങളെ വിശകലനം ചെയ്യുന്നതിലൂടെ, സാമ്പത്തിക വിപണിയിൽ പ്രവചനങ്ങൾ നടത്താൻ കഴിയും.

എന്നാൽ ചുമതല ബുദ്ധിമുട്ടാണ്. ഇതിനായി എന്താണ് ചെയ്യുന്നത്? ഞങ്ങൾക്ക് 100 ബില്യൺ റെക്കോർഡുകൾ ഉണ്ട്: സമയം, സ്റ്റോക്ക്, വില. പ്രൈസ് അൽഗോരിതത്തിൽ നിന്നുള്ള റണ്ണിംഗ് ഡിഫറൻസിന്റെ 100 ബില്യൺ മടങ്ങ് നമ്മൾ ആദ്യം കണക്കാക്കേണ്ടതുണ്ട്. രണ്ട് വരികൾ തമ്മിലുള്ള വ്യത്യാസം തുടർച്ചയായി കണക്കാക്കുന്ന ക്ലിക്ക്ഹൗസിലെ ഒരു ഫംഗ്ഷനാണ് RunningDifference.

അതിനുശേഷം നമ്മൾ പരസ്പരബന്ധം കണക്കാക്കേണ്ടതുണ്ട്, കൂടാതെ ഓരോ ജോഡിക്കും പരസ്പരബന്ധം കണക്കാക്കണം. 5 ഷെയറുകൾക്ക്, ജോഡികൾ 000 ദശലക്ഷമാണ്. ഇത് ധാരാളം, അതായത് 12,5 തവണ നിങ്ങൾ ഈ പരസ്പര ബന്ധ ഫംഗ്ഷൻ കണക്കാക്കേണ്ടതുണ്ട്.

ആരെങ്കിലും മറന്നുപോയാൽ, ͞x ഉം ͞y ഉം ചെക്ക്മേറ്റ് ആണ്. മാതൃകാ പ്രതീക്ഷ. അതായത്, നിങ്ങൾ വേരുകളും തുകകളും മാത്രമല്ല, ഈ തുകയ്ക്കുള്ളിലെ മറ്റ് തുകകളും കണക്കാക്കേണ്ടതുണ്ട്. ധാരാളം കണക്കുകൂട്ടലുകൾ 12,5 ദശലക്ഷം തവണ ചെയ്യേണ്ടതുണ്ട്, അവയും മണിക്കൂറുകൾക്കനുസരിച്ച് ഗ്രൂപ്പുചെയ്യേണ്ടതുണ്ട്. കൂടാതെ ഞങ്ങൾക്ക് ധാരാളം മണിക്കൂറുകൾ ഉണ്ട്. നിങ്ങൾ ഇത് 60 സെക്കൻഡിനുള്ളിൽ ചെയ്യണം. ഒരു തമാശ ആകുന്നു.

ഞങ്ങൾക്കിത് എങ്ങനെയെങ്കിലും ഉണ്ടാക്കണം, കാരണം ക്ലിക്ക്ഹൗസ് എത്തുന്നതിന് മുമ്പ് എല്ലാം വളരെ സാവധാനത്തിൽ പ്രവർത്തിച്ചു.

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

തുടർന്ന് ക്ലിക്ക്ഹൗസ് വന്നു, എല്ലാം വളരെ മികച്ചതായി.

ഡാറ്റാ ലോക്കാലിറ്റിയിൽ ഞങ്ങൾക്ക് ഒരു പ്രശ്നമുണ്ടെന്ന് ഞാൻ നിങ്ങളെ ഓർമ്മിപ്പിക്കട്ടെ, അതിനാൽ പരസ്പര ബന്ധങ്ങൾ പ്രാദേശികവൽക്കരിക്കാൻ കഴിയില്ല. ഞങ്ങൾക്ക് കുറച്ച് ഡാറ്റ ഒരു സെർവറിലേക്കും ചിലത് മറ്റൊന്നിലേക്ക് ചേർക്കാനും കണക്കാക്കാനും കഴിയില്ല; ഞങ്ങൾക്ക് എല്ലാ ഡാറ്റയും എല്ലായിടത്തും ഉണ്ടായിരിക്കണം.

അവർ എന്താണ് ചെയ്തത്? തുടക്കത്തിൽ, ഡാറ്റ പ്രാദേശികവൽക്കരിച്ചിരിക്കുന്നു. ഓരോ സെർവറും ഒരു നിശ്ചിത ഷെയറുകളുടെ വിലനിർണ്ണയ ഡാറ്റ സംഭരിക്കുന്നു. മാത്രമല്ല അവ തമ്മിൽ കൂട്ടിമുട്ടുകയുമില്ല. അതിനാൽ, ലോഗ് റിട്ടേൺ സമാന്തരമായും സ്വതന്ത്രമായും കണക്കാക്കാൻ കഴിയും; ഇതെല്ലാം സമാന്തരമായും വിതരണം ചെയ്യപ്പെടുന്നതുമാണ്.

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

ഇത് പിന്നീട് ആവർത്തിക്കാം. "r" എന്ന അക്ഷരം അർത്ഥമാക്കുന്നത് ഞങ്ങൾ ഈ ഡാറ്റ പകർത്തി എന്നാണ്. അതായത്, മൂന്ന് സെർവറുകളിലും ഞങ്ങൾക്ക് ഒരേ ഡാറ്റയുണ്ട് - ഇവയാണ് അറേകൾ.

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

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

ആശയത്തിന്റെ തെളിവിൽ, ചുമതല ഒരു ഉപടാസ്‌ക് ആയിരുന്നു, അതായത് അവർ കുറച്ച് ഡാറ്റയാണ് എടുത്തത്. മൂന്ന് സെർവറുകളിൽ മാത്രം.

ഈ ആദ്യ രണ്ട് ഘട്ടങ്ങൾ: Log_return കണക്കാക്കുന്നതിനും അറേകളിൽ പൊതിയുന്നതിനും ഏകദേശം ഒരു മണിക്കൂർ വീതം എടുത്തു.

പരസ്പരബന്ധം കണക്കാക്കുന്നത് ഏകദേശം 50 മണിക്കൂർ എടുക്കും. എന്നാൽ 50 മണിക്കൂർ പര്യാപ്തമല്ല, കാരണം മുമ്പ് ഇത് ആഴ്ചകളോളം അവർക്കായി പ്രവർത്തിച്ചു. അത് വലിയ വിജയമായിരുന്നു. നിങ്ങൾ കണക്കാക്കുകയാണെങ്കിൽ, ഈ ക്ലസ്റ്ററിൽ എല്ലാം സെക്കൻഡിൽ 70 തവണ കണക്കാക്കി.

എന്നാൽ ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം, ഈ സംവിധാനത്തിന് ഫലത്തിൽ തടസ്സങ്ങളൊന്നുമില്ല, അതായത് ഇത് ഏതാണ്ട് രേഖീയമായി സ്കെയിൽ ചെയ്യുന്നു എന്നതാണ്. അവർ അത് പരിശോധിച്ചു. ഇത് വിജയകരമായി സ്കെയിൽ ചെയ്തു.

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

ഈ ഹ്രസ്വ സംഭാഷണത്തെ സംഗ്രഹിക്കുന്നതിന്, വാണിജ്യ ഡാറ്റാബേസുകളുടെയും ഓപ്പൺ സോഴ്‌സ് ഡാറ്റാബേസുകളുടെയും പ്രദേശം ClickHouse ഇപ്പോൾ ദൃഢമായി കൈവശപ്പെടുത്തിയിരിക്കുന്നു എന്ന് നമുക്ക് പറയാം, അതായത് പ്രത്യേകമായി അനലിറ്റിക്‌സ്. അവൻ ഈ ഭൂപ്രകൃതിയിൽ തികച്ചും യോജിക്കുന്നു. എന്തിനധികം, അത് പതുക്കെ മറ്റുള്ളവരെ സ്ഥാനഭ്രഷ്ടനാക്കാൻ തുടങ്ങുന്നു, കാരണം ClickHouse ഉള്ളപ്പോൾ നിങ്ങൾക്ക് InfiniDB ആവശ്യമില്ല. സാധാരണ SQL പിന്തുണ നൽകുകയാണെങ്കിൽ ലംബമായത് ഉടൻ ആവശ്യമില്ല. ഉപയോഗികുക!

-റിപ്പോർട്ടിന് നന്ദി! വളരെ രസകരമാണ്! അപ്പാച്ചെ ഫീനിക്സുമായി എന്തെങ്കിലും താരതമ്യങ്ങൾ ഉണ്ടായിട്ടുണ്ടോ?

- ഇല്ല, ആരും താരതമ്യം ചെയ്യുന്നത് ഞാൻ കേട്ടിട്ടില്ല. വ്യത്യസ്‌ത ഡാറ്റാബേസുകളുള്ള ClickHouse-ന്റെ എല്ലാ താരതമ്യങ്ങളുടെയും ട്രാക്ക് സൂക്ഷിക്കാൻ ഞങ്ങളും Yandex ഉം ശ്രമിക്കുന്നു. കാരണം പെട്ടെന്ന് എന്തെങ്കിലും ക്ലിക്ക്ഹൗസിനേക്കാൾ വേഗതയേറിയതായി മാറുകയാണെങ്കിൽ, ലെഷ മിലോവിഡോവിന് രാത്രിയിൽ ഉറങ്ങാൻ കഴിയില്ല, അത് വേഗത്തിൽ വേഗത്തിലാക്കാൻ തുടങ്ങുന്നു. അങ്ങനെയൊരു താരതമ്യം ഞാൻ കേട്ടിട്ടില്ല.

• (Alexey Milovidov) Hbase അടിസ്ഥാനമാക്കിയുള്ള ഒരു SQL എഞ്ചിനാണ് അപ്പാച്ചെ ഫീനിക്സ്. Hbase പ്രധാനമായും രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത് കീ-വാല്യൂ ടൈപ്പ് വർക്ക് സാഹചര്യത്തിനാണ്. അവിടെ, ഓരോ വരിയിലും അനിയന്ത്രിതമായ പേരുകളുള്ള നിരകളുടെ അനിയന്ത്രിതമായ എണ്ണം ഉണ്ടായിരിക്കാം. Hbase, Cassandra തുടങ്ങിയ സംവിധാനങ്ങളെക്കുറിച്ച് ഇത് പറയാം. മാത്രമല്ല, അവർക്ക് സാധാരണയായി പ്രവർത്തിക്കാത്ത കൃത്യമായ വിശകലന അന്വേഷണങ്ങളാണ്. അല്ലെങ്കിൽ ClickHouse-ൽ നിങ്ങൾക്ക് അനുഭവം ഇല്ലെങ്കിൽ അവ നന്നായി പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾ കരുതിയേക്കാം.

• Спасибо

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

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

റിപ്പോർട്ടിന് നന്ദി! ഏറ്റവും പുതിയ സാമ്പത്തിക കേസിനെക്കുറിച്ച് എനിക്ക് ഒരു ചോദ്യമുണ്ട്. അവർക്ക് അനലിറ്റിക്സ് ഉണ്ടായിരുന്നു. അവ എങ്ങനെ മുകളിലേക്കും താഴേക്കും പോകുന്നു എന്ന് താരതമ്യം ചെയ്യേണ്ടത് ആവശ്യമാണ്. ഈ വിശകലനത്തിനായി നിങ്ങൾ പ്രത്യേകമായി സിസ്റ്റം നിർമ്മിച്ചതാണെന്ന് ഞാൻ മനസ്സിലാക്കുന്നു? നാളെ, പറയട്ടെ, അവർക്ക് ഈ ഡാറ്റയെക്കുറിച്ച് മറ്റെന്തെങ്കിലും റിപ്പോർട്ട് ആവശ്യമുണ്ടോ, അവർ വീണ്ടും ഡയഗ്രം നിർമ്മിക്കുകയും ഡാറ്റ ലോഡുചെയ്യുകയും ചെയ്യേണ്ടതുണ്ടോ? അതായത്, അഭ്യർത്ഥന സ്വീകരിക്കുന്നതിന് ഏതെങ്കിലും തരത്തിലുള്ള പ്രീപ്രോസസിംഗ് നടത്തണോ?

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

ഇത് വ്യക്തമാണ്. പ്രോസസ്സ് ചെയ്യാൻ 50 മണിക്കൂർ എടുത്തെന്ന് നിങ്ങൾ പറഞ്ഞു. നിങ്ങൾ ഡാറ്റ ലോഡുചെയ്യുമ്പോഴോ ഫലങ്ങൾ ലഭിക്കുമ്പോഴോ അത് ആദ്യം മുതൽ ആരംഭിക്കുന്നുണ്ടോ?

അതെ അതെ.

ഓകെ. നിങ്ങളോട് വളരെയധികം നന്ദിയുണ്ട്.

ഇത് 3 സെർവർ ക്ലസ്റ്ററിലാണ്.

ആശംസകൾ! റിപ്പോർട്ടിന് നന്ദി! എല്ലാം വളരെ രസകരമാണ്. പ്രവർത്തനക്ഷമതയെക്കുറിച്ചല്ല, സ്ഥിരതയുടെ വീക്ഷണകോണിൽ നിന്ന് ClickHouse ഉപയോഗിക്കുന്നതിനെക്കുറിച്ചാണ് ഞാൻ ചോദിക്കുന്നത്. അതായത്, നിങ്ങൾക്ക് എന്തെങ്കിലും പ്രശ്നങ്ങൾ ഉണ്ടായിട്ടുണ്ടോ, അവ പുനഃസ്ഥാപിക്കേണ്ടതുണ്ടോ? ClickHouse എങ്ങനെയാണ് പെരുമാറുന്നത്? നിങ്ങളുടെ പകർപ്പും തകർന്നതായി എപ്പോഴെങ്കിലും സംഭവിച്ചിട്ടുണ്ടോ? ഉദാഹരണത്തിന്, ClickHouse അതിന്റെ പരിധിക്കപ്പുറം പോയി വീണപ്പോൾ ഞങ്ങൾ ഒരു പ്രശ്നം നേരിട്ടു.

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

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

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

Спасибо.

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