ഏപ്രിലിൽ, Avito എഞ്ചിനീയർമാർ പ്രധാന ClickHouse ഡവലപ്പർ അലക്സി മിലോവിഡോവ്, Integros കമ്പനിയിൽ നിന്നുള്ള Golang ഡവലപ്പർ Kirill Svakov എന്നിവരുമായി ഓൺലൈൻ മീറ്റിംഗുകൾക്കായി ഒത്തുകൂടി. ഞങ്ങൾ എങ്ങനെയാണ് ഒരു ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റം ഉപയോഗിക്കുന്നതെന്നും എന്തൊക്കെ ബുദ്ധിമുട്ടുകൾ നേരിടുന്നുവെന്നും ഞങ്ങൾ ചർച്ച ചെയ്തു.
മീറ്റിംഗിനെ അടിസ്ഥാനമാക്കി, ബാക്കപ്പുകൾ, ഡാറ്റ റീഷാർഡിംഗ്, ബാഹ്യ നിഘണ്ടുക്കൾ, Golang ഡ്രൈവർ, ClickHouse പതിപ്പുകൾ അപ്ഡേറ്റ് ചെയ്യൽ എന്നിവയെക്കുറിച്ചുള്ള ഞങ്ങളുടെയും പ്രേക്ഷകരുടെയും ചോദ്യങ്ങൾക്കുള്ള വിദഗ്ധരുടെ ഉത്തരങ്ങളുള്ള ഒരു ലേഖനം ഞങ്ങൾ സമാഹരിച്ചിരിക്കുന്നു. Yandex DBMS-ൽ ഇതിനകം സജീവമായി പ്രവർത്തിക്കുന്ന ഡവലപ്പർമാർക്കും അതിന്റെ വർത്തമാനത്തിലും ഭാവിയിലും താൽപ്പര്യമുള്ളവർക്കും ഇത് ഉപയോഗപ്രദമാകും. സ്ഥിരസ്ഥിതിയായി, ഉത്തരങ്ങൾ അലക്സി മിലോവിഡോവിൽ നിന്നുള്ളതാണ്, അല്ലാത്തപക്ഷം എഴുതിയിട്ടില്ലെങ്കിൽ.
ശ്രദ്ധിക്കുക, കട്ടിനടിയിൽ ധാരാളം വാചകങ്ങളുണ്ട്. ചോദ്യങ്ങളുള്ള ഉള്ളടക്കം നിങ്ങളെ നാവിഗേറ്റ് ചെയ്യാൻ സഹായിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.
ഉള്ളടക്കം
നിങ്ങൾക്ക് വാചകം വായിക്കാൻ താൽപ്പര്യമില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഒത്തുചേരലുകളുടെ റെക്കോർഡിംഗ് കാണാൻ കഴിയും . വീഡിയോയ്ക്ക് താഴെയുള്ള ആദ്യ കമന്റിൽ ടൈംകോഡുകൾ ഉണ്ട്.
ClickHouse നിരന്തരം അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു, പക്ഷേ ഞങ്ങളുടെ ഡാറ്റ അങ്ങനെയല്ല. അതിന് എന്ത് ചെയ്യണം?
ClickHouse നിരന്തരം അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു, ഒപ്റ്റിമൈസ് ചെയ്ത അന്തിമ പ്രോസസ്സ് ചെയ്ത ഞങ്ങളുടെ ഡാറ്റ അപ്ഡേറ്റ് ചെയ്തിട്ടില്ല, അത് ഒരു ബാക്കപ്പ് കോപ്പിയിലാണ്.
ഞങ്ങൾക്ക് എന്തെങ്കിലും പ്രശ്‌നമുണ്ടായി, ഡാറ്റ നഷ്ടപ്പെട്ടുവെന്ന് പറയാം. ഞങ്ങൾ പുനഃസ്ഥാപിക്കാൻ തീരുമാനിച്ചു, ബാക്കപ്പ് സെർവറുകളിൽ സംഭരിച്ചിരിക്കുന്ന പഴയ പാർട്ടീഷനുകൾ നിലവിൽ ഉപയോഗിക്കുന്ന ക്ലിക്ക്ഹൗസിന്റെ പതിപ്പിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണ്. അത്തരമൊരു സാഹചര്യത്തിൽ എന്തുചെയ്യണം, അത് സാധ്യമാണോ?
നിങ്ങൾ ഒരു പഴയ ഫോർമാറ്റിൽ ഒരു ബാക്കപ്പിൽ നിന്ന് ഡാറ്റ പുനഃസ്ഥാപിച്ച ഒരു സാഹചര്യം, പക്ഷേ അത് പുതിയ പതിപ്പിലേക്ക് കണക്റ്റുചെയ്യുന്നില്ല, അസാധ്യമാണ്. ClickHouse-ലെ ഡാറ്റ ഫോർമാറ്റ് എല്ലായ്പ്പോഴും പിന്നിലേക്ക് അനുയോജ്യമാണെന്ന് ഞങ്ങൾ ഉറപ്പാക്കുന്നു. അപൂർവ്വമായി ഉപയോഗിക്കുന്ന ചില ഫംഗ്‌ഷന്റെ സ്വഭാവം മാറിയിട്ടുണ്ടെങ്കിൽ, പ്രവർത്തനക്ഷമതയുടെ കാര്യത്തിൽ ഇത് പിന്നോട്ട് അനുയോജ്യതയേക്കാൾ വളരെ പ്രധാനമാണ്. ClickHouse-ന്റെ പുതിയ പതിപ്പിന് എല്ലായ്പ്പോഴും ഡിസ്കിൽ സംഭരിച്ചിരിക്കുന്ന ഡാറ്റ വായിക്കാൻ കഴിയണം. ഇതാണ് നിയമം.
ClickHouse-ൽ നിന്ന് ഡാറ്റ ബാക്കപ്പ് ചെയ്യുന്നതിനുള്ള നിലവിലെ മികച്ച രീതികൾ ഏതൊക്കെയാണ്?
അവസാന പ്രവർത്തനങ്ങൾ, ടെറാബൈറ്റുകളുടെ ഒരു വലിയ ഡാറ്റാബേസ്, കഴിഞ്ഞ മൂന്ന് ദിവസമായി അപ്ഡേറ്റ് ചെയ്ത ഡാറ്റ എന്നിവ ഒപ്റ്റിമൈസ് ചെയ്‌തിട്ടുണ്ടെന്നും തുടർന്ന് അവയ്ക്ക് നടപടിക്രമങ്ങളൊന്നും സംഭവിക്കില്ലെന്നും കണക്കിലെടുത്ത് ബാക്കപ്പുകൾ എങ്ങനെ നിർമ്മിക്കാം?
നമുക്ക് സ്വന്തമായി ഒരു സൊല്യൂഷൻ ഉണ്ടാക്കി ബാഷിൽ എഴുതാം: ഈ ബാക്കപ്പ് കോപ്പികൾ അത്തരത്തിലുള്ള രീതിയിൽ ശേഖരിക്കുക. ഒരുപക്ഷേ എന്തെങ്കിലും ഊന്നുവടി ആവശ്യമില്ല, സൈക്കിൾ വളരെക്കാലം മുമ്പ് കണ്ടുപിടിച്ചതാണോ?
ചില മികച്ച പരിശീലനങ്ങളിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം. ബാക്കപ്പുകളെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾക്ക് മറുപടിയായി, ഈ പ്രശ്നം ഇതിനകം പരിഹരിച്ച Yandex.Cloud സേവനത്തെക്കുറിച്ച് അവരെ ഓർമ്മിപ്പിക്കാൻ എന്റെ സഹപ്രവർത്തകർ എപ്പോഴും ഉപദേശിക്കുന്നു. അതിനാൽ സാധ്യമെങ്കിൽ അത് ഉപയോഗിക്കുക.
പൂർണ്ണമായ പരിഹാരമില്ല, ബാക്കപ്പുകൾക്കായി ക്ലിക്ക്ഹൗസിൽ നൂറ് ശതമാനം നിർമ്മിച്ചിരിക്കുന്നു. ഉപയോഗിക്കാവുന്ന ചില ശൂന്യതകളുണ്ട്. ഒരു സമ്പൂർണ്ണ പരിഹാരം ലഭിക്കുന്നതിന്, നിങ്ങൾ ഒന്നുകിൽ സ്വമേധയാ ടിങ്കർ ചെയ്യണം അല്ലെങ്കിൽ സ്ക്രിപ്റ്റുകളുടെ രൂപത്തിൽ റാപ്പറുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്.
ഡാറ്റയുടെ അളവും ക്ലസ്റ്ററിന്റെ വലുപ്പവും അനുസരിച്ച് ഞാൻ ഏറ്റവും ലളിതമായ പരിഹാരങ്ങളിൽ നിന്ന് ആരംഭിച്ച് ഏറ്റവും സങ്കീർണ്ണമായവയിൽ അവസാനിക്കും. വലിയ ക്ലസ്റ്റർ, പരിഹാരം കൂടുതൽ സങ്കീർണ്ണമാകും.
ഡാറ്റയുള്ള പട്ടികയ്ക്ക് കുറച്ച് ജിഗാബൈറ്റുകൾ മാത്രമേ എടുക്കൂ എങ്കിൽ, ബാക്കപ്പ് ഇതുപോലെ ചെയ്യാം:
- പട്ടിക നിർവചനം സംരക്ഷിക്കുക അതായത് മെറ്റാഡാറ്റ - സൃഷ്ടിക്കുക പട്ടിക കാണിക്കുക.
- ClickHouse ക്ലയന്റ് ഉപയോഗിച്ച് ഒരു ഡംപ് ഉണ്ടാക്കുക - തെരഞ്ഞെടുക്കുക * മേശയിൽ നിന്ന് ഒരു ഫയലിലേക്ക്. സ്ഥിരസ്ഥിതിയായി, TabSeparated ഫോർമാറ്റിൽ നിങ്ങൾക്ക് ഒരു ഫയൽ ലഭിക്കും. നിങ്ങൾക്ക് ഇത് കൂടുതൽ കാര്യക്ഷമമായി വേണമെങ്കിൽ, നിങ്ങൾക്ക് ഇത് നേറ്റീവ് ഫോർമാറ്റിൽ ചെയ്യാം.
ഡാറ്റയുടെ അളവ് വലുതാണെങ്കിൽ, ബാക്കപ്പിന് കൂടുതൽ സമയവും ധാരാളം സ്ഥലവും എടുക്കും. ഇതിനെ ലോജിക്കൽ ബാക്കപ്പ് എന്ന് വിളിക്കുന്നു; ഇത് ClickHouse ഡാറ്റ ഫോർമാറ്റുമായി ബന്ധിപ്പിച്ചിട്ടില്ല. അങ്ങനെയാണെങ്കിൽ, അവസാന ആശ്രയമെന്ന നിലയിൽ നിങ്ങൾക്ക് ഒരു ബാക്കപ്പ് എടുത്ത് പുനഃസ്ഥാപിക്കുന്നതിനായി MySQL-ലേക്ക് അപ്‌ലോഡ് ചെയ്യാം.
കൂടുതൽ വിപുലമായ കേസുകൾക്കായി, ലോക്കൽ ഫയൽ സിസ്റ്റത്തിൽ പാർട്ടീഷനുകളുടെ ഒരു സ്നാപ്പ്ഷോട്ട് സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു ബിൽറ്റ്-ഇൻ കഴിവ് ClickHouse-നുണ്ട്. ഈ സവിശേഷത ഒരു അഭ്യർത്ഥനയായി ലഭ്യമാണ്. ടേബിൾ ഫ്രീസ് പാർട്ടീഷൻ മാറ്റുക. അല്ലെങ്കിൽ ലളിതമായി ടേബിൾ ഫ്രീസ് മാറ്റുക - ഇത് മുഴുവൻ പട്ടികയുടെയും ഒരു സ്നാപ്പ്ഷോട്ട് ആണ്.
സ്നാപ്പ്ഷോട്ട് ഒരു ടേബിളിനായി ഒരു ഷാർഡിൽ സ്ഥിരമായി സൃഷ്‌ടിക്കപ്പെടും, അതായത്, ഈ രീതിയിൽ മുഴുവൻ ക്ലസ്റ്ററിന്റെയും സ്ഥിരതയുള്ള സ്നാപ്പ്ഷോട്ട് സൃഷ്‌ടിക്കുന്നത് അസാധ്യമാണ്. എന്നാൽ മിക്ക ടാസ്ക്കുകൾക്കും അത്തരം ആവശ്യമില്ല, ഓരോ ഷാർഡിലും ഒരു അഭ്യർത്ഥന നടപ്പിലാക്കുകയും സ്ഥിരമായ ഒരു സ്നാപ്പ്ഷോട്ട് നേടുകയും ചെയ്താൽ മതിയാകും. ഇത് ഹാർഡ്‌ലിങ്കുകളുടെ രൂപത്തിലാണ് സൃഷ്ടിച്ചിരിക്കുന്നത്, അതിനാൽ അധിക സ്ഥലം എടുക്കുന്നില്ല. അടുത്തതായി, നിങ്ങൾ ഈ സ്നാപ്പ്ഷോട്ട് ബാക്കപ്പ് സെർവറിലേക്കോ ബാക്കപ്പുകൾക്കായി നിങ്ങൾ ഉപയോഗിക്കുന്ന സ്റ്റോറേജിലേക്കോ പകർത്തുന്നു.
അത്തരമൊരു ബാക്കപ്പ് പുനഃസ്ഥാപിക്കുന്നത് വളരെ എളുപ്പമാണ്. ആദ്യം, നിലവിലുള്ള പട്ടിക നിർവചനങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾ പട്ടികകൾ സൃഷ്ടിക്കുന്നു. അടുത്തതായി, പാർട്ടീഷനുകളുടെ സംരക്ഷിച്ച സ്നാപ്പ്ഷോട്ടുകൾ ടേബിൾ ഡാറ്റയ്ക്കായി ഡയറക്ടറി-ഡിറ്റാച്ച്ഡിലേക്ക് പകർത്തി അന്വേഷണം പ്രവർത്തിപ്പിക്കുക പാർട്ടീഷൻ അറ്റാച്ചുചെയ്യുക. ഡാറ്റയുടെ ഏറ്റവും ഗുരുതരമായ വോള്യങ്ങൾക്ക് ഈ പരിഹാരം തികച്ചും അനുയോജ്യമാണ്.
ഓരോ സെർവറിലും പതിനായിരക്കണക്കിന് അല്ലെങ്കിൽ നൂറുകണക്കിന് ടെറാബൈറ്റുകളും നൂറുകണക്കിന് സെർവറുകളും ഉള്ള സന്ദർഭങ്ങളിൽ - ചിലപ്പോൾ നിങ്ങൾക്ക് കൂടുതൽ തണുത്ത എന്തെങ്കിലും ആവശ്യമാണ്. Yandex.Metrica-ൽ നിന്ന് എന്റെ സഹപ്രവർത്തകരിൽ നിന്ന് ഞാൻ തിരഞ്ഞെടുത്ത ഒരു പരിഹാരമുണ്ട്. ഞാൻ ഇത് എല്ലാവരോടും ശുപാർശ ചെയ്യുന്നില്ല - ഇത് വായിച്ച് ഇത് അനുയോജ്യമാണോ അല്ലയോ എന്ന് സ്വയം തീരുമാനിക്കുക.
ആദ്യം നിങ്ങൾ വലിയ ഡിസ്ക് ഷെൽഫുകളുള്ള നിരവധി സെർവറുകൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്. അടുത്തതായി, ഈ സെർവറുകളിൽ നിരവധി ClickHouse സെർവറുകൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും അവ കോൺഫിഗർ ചെയ്യുകയും ചെയ്യുക, അങ്ങനെ അവ ഒരേ ശകലങ്ങളുടെ മറ്റൊരു പകർപ്പായി പ്രവർത്തിക്കും. തുടർന്ന് സ്നാപ്പ്ഷോട്ടുകൾ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഈ സെർവറുകളിൽ ഒരു ഫയൽ സിസ്റ്റം അല്ലെങ്കിൽ ചില ടൂൾ ഉപയോഗിക്കുക. ഇവിടെ രണ്ട് ഓപ്ഷനുകൾ ഉണ്ട്. ആദ്യ ഓപ്ഷൻ എൽവിഎം സ്നാപ്പ്ഷോട്ടുകൾ ആണ്, രണ്ടാമത്തെ ഓപ്ഷൻ ലിനക്സിലെ ZFS ആണ്.
അതിനുശേഷം, എല്ലാ ദിവസവും നിങ്ങൾ ഒരു സ്നാപ്പ്ഷോട്ട് സൃഷ്ടിക്കേണ്ടതുണ്ട്, അത് കള്ളം പറയുകയും കുറച്ച് സ്ഥലം എടുക്കുകയും ചെയ്യും. സ്വാഭാവികമായും, ഡാറ്റ മാറുകയാണെങ്കിൽ, കാലക്രമേണ സ്ഥലത്തിന്റെ അളവ് വർദ്ധിക്കും. ഈ സ്നാപ്പ്ഷോട്ട് എപ്പോൾ വേണമെങ്കിലും പുറത്തെടുക്കുകയും ഡാറ്റ പുനഃസ്ഥാപിക്കുകയും ചെയ്യാം, എന്തൊരു വിചിത്രമായ പരിഹാരം. കൂടാതെ, കോൺഫിഗറിലുള്ള ഈ പകർപ്പുകൾ ഞങ്ങൾ പരിമിതപ്പെടുത്തേണ്ടതുണ്ട്, അതുവഴി അവർ നേതാക്കളാകാൻ ശ്രമിക്കരുത്.
ഷാഫ്റ്റുകളിൽ നിയന്ത്രിത കാലതാമസം ക്രമീകരിക്കാൻ കഴിയുമോ?
ഈ വർഷം നിങ്ങൾ ClickHouse-ൽ ഷാഫ്റ്റുകൾ നിർമ്മിക്കാൻ പദ്ധതിയിടുന്നു. അവയിൽ പകർപ്പുകളുടെ നിയന്ത്രിത കാലതാമസം സംഘടിപ്പിക്കാൻ കഴിയുമോ? മാറ്റങ്ങളും മറ്റ് മാറ്റങ്ങളും ഉള്ള നെഗറ്റീവ് സാഹചര്യങ്ങളിൽ നിന്ന് സ്വയം പരിരക്ഷിക്കുന്നതിന് ഇത് ഉപയോഗിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.
മാറ്റങ്ങൾക്കായി ഏതെങ്കിലും തരത്തിലുള്ള റോൾ ബാക്ക് ചെയ്യാൻ സാധിക്കുമോ? ഉദാഹരണത്തിന്, നിലവിലുള്ള ഒരു ഷാഫ്റ്റിൽ, അത് എടുത്ത് ഈ നിമിഷം വരെ മാറ്റങ്ങൾ പ്രയോഗിക്കുക എന്ന് പറയുക, ഈ നിമിഷം മുതൽ മാറ്റങ്ങൾ പ്രയോഗിക്കുന്നത് നിർത്തണോ?
ഞങ്ങളുടെ ക്ലസ്റ്ററിലേക്ക് ഒരു കമാൻഡ് വന്ന് അത് തകർത്താൽ, ഒരു മണിക്കൂർ കാലതാമസമുള്ള ഒരു സോപാധികമായ ഒരു പകർപ്പ് നമുക്കുണ്ട്, അവിടെ നമുക്ക് അത് ഇപ്പോൾ ഉപയോഗിക്കാമെന്ന് പറയാം, എന്നാൽ അവസാനത്തെ പത്ത് മിനിറ്റ് മാറ്റങ്ങൾ ഞങ്ങൾ അതിൽ പ്രയോഗിക്കില്ലേ?
ആദ്യം, പകർപ്പുകളുടെ നിയന്ത്രിത കാലതാമസത്തെക്കുറിച്ച്. ഉപയോക്താക്കളിൽ നിന്ന് അത്തരത്തിലുള്ള ഒരു അഭ്യർത്ഥന ഉണ്ടായിരുന്നു, കൂടാതെ അഭ്യർത്ഥനയോടെ ഞങ്ങൾ Github-ൽ ഒരു പ്രശ്നം സൃഷ്ടിച്ചു: "ആർക്കെങ്കിലും ഇത് ആവശ്യമുണ്ടെങ്കിൽ, അത് ലൈക്ക് ചെയ്യുക, ഒരു ഹൃദയം നൽകുക." ആരും ഡെലിവർ ചെയ്തില്ല, പ്രശ്നം അവസാനിപ്പിച്ചു. എന്നിരുന്നാലും, ClickHouse സജ്ജീകരിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് ഇതിനകം തന്നെ ഈ അവസരം ലഭിക്കും. ശരിയാണ്, പതിപ്പ് 20.3 മുതൽ ആരംഭിക്കുന്നു.
ക്ലിക്ക്ഹൗസ് പശ്ചാത്തലത്തിൽ ഡാറ്റ ലയനം നിരന്തരം നടത്തുന്നു. ഒരു ലയനം പൂർത്തിയാകുമ്പോൾ, ഒരു നിശ്ചിത ഡാറ്റാ കഷണങ്ങൾ ഒരു വലിയ കഷണം ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു. അതേ സമയം, മുമ്പ് ഉണ്ടായിരുന്ന ഡാറ്റയുടെ ഭാഗങ്ങൾ കുറച്ച് സമയത്തേക്ക് ഡിസ്കിൽ തുടരും.
ആദ്യം, നോൺ-ബ്ലോക്കിംഗ് ഓപ്പറേഷൻ ഉറപ്പാക്കാൻ, അവ ഉപയോഗിക്കുന്ന തിരഞ്ഞെടുത്ത അന്വേഷണങ്ങൾ ഉള്ളിടത്തോളം കാലം അവ സംഭരിക്കുന്നത് തുടരും. തിരഞ്ഞെടുത്ത ചോദ്യങ്ങൾ പഴയ ഭാഗങ്ങളിൽ നിന്ന് എളുപ്പത്തിൽ വായിക്കാൻ കഴിയും.
രണ്ടാമതായി, ഒരു സമയ പരിധിയും ഉണ്ട് - പഴയ ഡാറ്റ കഷണങ്ങൾ ഡിസ്കിൽ എട്ട് മിനിറ്റ് കിടക്കുന്നു. ഈ എട്ട് മിനിറ്റ് ഇഷ്‌ടാനുസൃതമാക്കാനും ഒരു ദിവസമാക്കി മാറ്റാനും കഴിയും. ഇതിന് ഡിസ്ക് സ്പേസ് ചിലവാകും: ഡാറ്റാ ഫ്ലോയെ ആശ്രയിച്ച്, കഴിഞ്ഞ ദിവസം ഡാറ്റ ഇരട്ടിയാവുക മാത്രമല്ല, അഞ്ചിരട്ടിയായി മാറുകയും ചെയ്യും. എന്നാൽ ഗുരുതരമായ പ്രശ്‌നമുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ClickHouse സെർവർ നിർത്താനും എല്ലാം ക്രമീകരിക്കാനും കഴിയും.
ഇത് എങ്ങനെ മാറ്റങ്ങളിൽ നിന്ന് സംരക്ഷിക്കുന്നു എന്നതാണ് ഇപ്പോൾ ചോദ്യം. ഇവിടെ കൂടുതൽ ആഴത്തിൽ നോക്കുന്നത് മൂല്യവത്താണ്, കാരണം ClickHouse-ന്റെ പഴയ പതിപ്പുകളിൽ, ആൾട്ടർ നേരിട്ട് ഭാഗങ്ങൾ മാറ്റുന്ന തരത്തിലാണ് പ്രവർത്തിച്ചത്. ചില ഫയലുകൾക്കൊപ്പം ഒരു കഷണം ഡാറ്റയുണ്ട്, ഞങ്ങൾ ചെയ്യുന്നു, ഉദാഹരണത്തിന്, ഡ്രോപ്പ് കോളം മാറ്റുക. അപ്പോൾ ഈ കോളം എല്ലാ കഷണങ്ങളിൽ നിന്നും ശാരീരികമായി നീക്കം ചെയ്യപ്പെടുന്നു.
എന്നാൽ പതിപ്പ് 20.3 മുതൽ, ആൾട്ടർ മെക്കാനിസം പൂർണ്ണമായും മാറ്റി, ഇപ്പോൾ ഡാറ്റയുടെ ഭാഗങ്ങൾ എല്ലായ്പ്പോഴും മാറ്റമില്ലാത്തതാണ്. അവ ഒട്ടും മാറുന്നില്ല - ഇപ്പോൾ ആൾട്ടറുകൾ ലയിപ്പിക്കുന്നത് പോലെ തന്നെ പ്രവർത്തിക്കുന്നു. ഒരു കഷണം പകരം വയ്ക്കുന്നതിനുപകരം, ഞങ്ങൾ പുതിയൊരെണ്ണം സൃഷ്ടിക്കുന്നു. പുതിയ ചങ്കിൽ, മാറാത്ത ഫയലുകൾ ഹാർഡ്‌ലിങ്കുകളായി മാറുന്നു, ഞങ്ങൾ ഒരു കോളം ഇല്ലാതാക്കുകയാണെങ്കിൽ, അത് പുതിയ ചങ്കിൽ കാണാതെ പോകും. എട്ട് മിനിറ്റിന് ശേഷം പഴയ ഭാഗം ഡിഫോൾട്ടായി ഇല്ലാതാക്കപ്പെടും, ഇവിടെ നിങ്ങൾക്ക് മുകളിൽ സൂചിപ്പിച്ച ക്രമീകരണങ്ങൾ മാറ്റാനാകും.
മ്യൂട്ടേഷനുകൾ പോലുള്ള മാറ്റങ്ങൾക്കും ഇത് ബാധകമാണ്. നിങ്ങൾ ചെയ്യുമ്പോൾ ഇല്ലാതാക്കുക മാറ്റുക അഥവാ അപ്ഡേറ്റ് മാറ്റുക, അത് കഷണം മാറ്റില്ല, പക്ഷേ പുതിയൊരെണ്ണം സൃഷ്ടിക്കുന്നു. എന്നിട്ട് പഴയത് ഇല്ലാതാക്കുന്നു.
പട്ടികയുടെ ഘടന മാറിയാലോ?
പഴയ സ്കീം ഉപയോഗിച്ച് നിർമ്മിച്ച ഒരു ബാക്കപ്പ് എങ്ങനെ പുനഃസ്ഥാപിക്കാം? രണ്ടാമത്തെ ചോദ്യം സ്നാപ്പ്ഷോട്ടുകളുടെയും ഫയൽ സിസ്റ്റം ടൂളുകളുടെയും കാര്യത്തെക്കുറിച്ചാണ്. Linux LVM-ൽ ZFS-ന് പകരം Btrfs ഇവിടെ നല്ലതാണോ?
നീ ചെയ്യുകയാണെങ്കില് പാർട്ടീഷൻ അറ്റാച്ചുചെയ്യുക മറ്റൊരു ഘടനയുള്ള പാർട്ടീഷനുകൾ, തുടർന്ന് ഇത് സാധ്യമല്ലെന്ന് ClickHouse നിങ്ങളോട് പറയും. ഇതാണ് പരിഹാരം. ആദ്യത്തേത്, പഴയ ഘടന ഉപയോഗിച്ച് MergeTree തരത്തിന്റെ ഒരു താൽക്കാലിക പട്ടിക സൃഷ്ടിക്കുക, അറ്റാച്ച് ഉപയോഗിച്ച് ഡാറ്റ അറ്റാച്ചുചെയ്യുക, കൂടാതെ ഒരു ആൾട്ടർ അന്വേഷണം നടത്തുക. തുടർന്ന് നിങ്ങൾക്ക് ഈ ഡാറ്റ പകർത്തുകയോ കൈമാറുകയോ ചെയ്ത് വീണ്ടും അറ്റാച്ചുചെയ്യാം അല്ലെങ്കിൽ ഒരു അഭ്യർത്ഥന ഉപയോഗിക്കുക ടേബിൾ മൂവ് പാർട്ടീഷൻ മാറ്റുക.
ഇനി രണ്ടാമത്തെ ചോദ്യം Btrfs ഉപയോഗിക്കാമോ എന്നതാണ്. ആരംഭിക്കുന്നതിന്, നിങ്ങൾക്ക് എൽവിഎം ഉണ്ടെങ്കിൽ, എൽവിഎം സ്നാപ്പ്ഷോട്ടുകൾ മതി, ഫയൽ സിസ്റ്റം ext4 ആകാം, അത് പ്രശ്നമല്ല. Btrts ഉപയോഗിച്ച്, എല്ലാം അത് ഉപയോഗിക്കുന്നതിലെ നിങ്ങളുടെ അനുഭവത്തെ ആശ്രയിച്ചിരിക്കുന്നു. ഇതൊരു മുതിർന്ന ഫയൽ സിസ്റ്റമാണ്, എന്നാൽ ഒരു പ്രത്യേക സാഹചര്യത്തിൽ എല്ലാം എങ്ങനെ പ്രായോഗികമായി പ്രവർത്തിക്കും എന്നതിനെക്കുറിച്ച് ഇപ്പോഴും ചില സംശയങ്ങളുണ്ട്. നിങ്ങൾക്ക് നിർമ്മാണത്തിൽ Btrfs ഇല്ലെങ്കിൽ ഇത് ഉപയോഗിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നില്ല.
ഡാറ്റ റീഷാർഡിംഗിലെ നിലവിലെ മികച്ച രീതികൾ ഏതൊക്കെയാണ്?
റീഷാർഡിംഗിന്റെ പ്രശ്നം സങ്കീർണ്ണവും ബഹുമുഖവുമാണ്. സാധ്യമായ നിരവധി ഉത്തരങ്ങൾ ഇവിടെയുണ്ട്. നിങ്ങൾക്ക് ഒരു വശത്ത് നിന്ന് പോയി ഇത് പറയാം: ClickHouse-ന് ഒരു ബിൽറ്റ്-ഇൻ റീഷാർഡിംഗ് ഫീച്ചർ ഇല്ല. എന്നാൽ ഈ ഉത്തരം ആർക്കും ചേരില്ല എന്ന് ഞാൻ ഭയപ്പെടുന്നു. അതിനാൽ, നിങ്ങൾക്ക് മറുവശത്ത് നിന്ന് പോയി, ക്ലിക്ക്ഹൗസിൽ ഡാറ്റ റീഷാർഡ് ചെയ്യാൻ നിരവധി മാർഗങ്ങളുണ്ടെന്ന് പറയാം.
ക്ലസ്റ്ററിന് സ്ഥലമില്ലാതാകുകയോ ലോഡിനെ നേരിടാൻ കഴിയാതിരിക്കുകയോ ചെയ്താൽ, നിങ്ങൾ പുതിയ സെർവറുകൾ ചേർക്കുക. എന്നാൽ ഈ സെർവറുകൾ സ്ഥിരസ്ഥിതിയായി ശൂന്യമാണ്, അവയിൽ ഡാറ്റയില്ല, ലോഡും ഇല്ല. നിങ്ങൾ ഡാറ്റ പുനഃക്രമീകരിക്കേണ്ടതുണ്ട്, അതിലൂടെ അത് പുതിയതും വലിയതുമായ ക്ലസ്റ്ററിലുടനീളം തുല്യമായി വ്യാപിക്കും.
ഒരു അഭ്യർത്ഥന ഉപയോഗിച്ച് പാർട്ടീഷനുകളുടെ ഒരു ഭാഗം പുതിയ സെർവറുകളിലേക്ക് പകർത്തുക എന്നതാണ് ഇത് ചെയ്യാവുന്ന ആദ്യ മാർഗം ടേബിൾ ലഭ്യമാക്കുന്ന പാർട്ടീഷൻ മാറ്റുക. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് മാസം തോറും പാർട്ടീഷനുകൾ ഉണ്ടായിരുന്നു, നിങ്ങൾ 2017 ലെ ആദ്യ മാസം എടുത്ത് ഒരു പുതിയ സെർവറിലേക്ക് പകർത്തുക, തുടർന്ന് മൂന്നാം മാസം മറ്റേതെങ്കിലും പുതിയ സെർവറിലേക്ക് പകർത്തുക. അത് കൂടുതലോ കുറവോ ആകുന്നതുവരെ നിങ്ങൾ ഇത് ചെയ്യുക.
റെക്കോർഡിംഗ് സമയത്ത് മാറാത്ത പാർട്ടീഷനുകൾക്ക് മാത്രമേ കൈമാറ്റം ചെയ്യാൻ കഴിയൂ. പുതിയ പാർട്ടീഷനുകൾക്ക്, റെക്കോർഡിംഗ് പ്രവർത്തനരഹിതമാക്കേണ്ടതുണ്ട്, കാരണം അവയുടെ കൈമാറ്റം ആറ്റോമികമല്ല. അല്ലെങ്കിൽ, നിങ്ങളുടെ ഡാറ്റയിലെ തനിപ്പകർപ്പുകളോ വിടവുകളോ നിങ്ങൾക്ക് ലഭിക്കും. എന്നിരുന്നാലും, ഈ രീതി പ്രായോഗികവും വളരെ ഫലപ്രദവുമാണ്. റെഡിമെയ്ഡ് കംപ്രസ് ചെയ്ത പാർട്ടീഷനുകൾ നെറ്റ്‌വർക്കിലൂടെ കൈമാറ്റം ചെയ്യപ്പെടുന്നു, അതായത്, ഡാറ്റ കംപ്രസ് ചെയ്യുകയോ വീണ്ടും എൻകോഡ് ചെയ്യുകയോ ചെയ്തിട്ടില്ല.
ഈ രീതിക്ക് ഒരു പോരായ്മയുണ്ട്, ഇത് ഷാർഡിംഗ് സ്കീമിനെ ആശ്രയിച്ചിരിക്കുന്നു, നിങ്ങൾ ഈ ഷാർഡിംഗ് സ്കീമിന് പണയം വെച്ചിട്ടുണ്ടോ, നിങ്ങൾക്ക് എന്ത് ഷാർഡിംഗ് കീ ഉണ്ടായിരുന്നു. മെട്രിക്സുമായി ബന്ധപ്പെട്ട നിങ്ങളുടെ ഉദാഹരണത്തിൽ, ഷാർഡിംഗ് കീ പാതയുടെ ഹാഷ് ആണ്. നിങ്ങൾ ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് ടേബിൾ തിരഞ്ഞെടുക്കുമ്പോൾ, അത് നേരിട്ട് ക്ലസ്റ്ററിലെ എല്ലാ ഷാർഡുകളിലേക്കും പോയി അവിടെ നിന്ന് ഡാറ്റ എടുക്കുന്നു.
ഇതിനർത്ഥം, വാസ്തവത്തിൽ, ഏത് ഷാർഡിൽ എന്ത് ഡാറ്റയാണ് അവസാനിച്ചത് എന്നത് നിങ്ങൾക്ക് പ്രശ്നമല്ല. പ്രധാന കാര്യം, ഒരു പാതയിലെ ഡാറ്റ ഒരു ഷാർഡിൽ അവസാനിക്കുന്നു, എന്നാൽ ഏതാണ് പ്രധാനമല്ല. ഈ സാഹചര്യത്തിൽ, റെഡിമെയ്ഡ് പാർട്ടീഷനുകൾ കൈമാറ്റം ചെയ്യുന്നത് മികച്ചതാണ്, കാരണം തിരഞ്ഞെടുത്ത അന്വേഷണങ്ങൾക്കൊപ്പം നിങ്ങൾക്ക് പൂർണ്ണമായ ഡാറ്റയും ലഭിക്കും, പുനഃസ്ഥാപിക്കുന്നതിന് മുമ്പോ ശേഷമോ, സ്കീം ശരിക്കും പ്രശ്നമല്ല.
എന്നാൽ കൂടുതൽ സങ്കീർണ്ണമായ കേസുകളുണ്ട്. ആപ്ലിക്കേഷൻ ലോജിക് തലത്തിൽ നിങ്ങൾ ഒരു പ്രത്യേക ഷാർഡിംഗ് സ്കീമിനെ ആശ്രയിക്കുന്നുവെങ്കിൽ, ഈ ക്ലയന്റ് അത്തരത്തിലുള്ള ഒരു ഷാർഡിലാണ് സ്ഥിതിചെയ്യുന്നത്, അഭ്യർത്ഥന നേരിട്ട് അവിടെ അയയ്‌ക്കാം, വിതരണം ചെയ്ത പട്ടികയിലേക്കല്ല. അല്ലെങ്കിൽ നിങ്ങൾ ClickHouse-ന്റെ ഏറ്റവും പുതിയ പതിപ്പാണ് ഉപയോഗിക്കുന്നത് കൂടാതെ ക്രമീകരണം പ്രവർത്തനക്ഷമമാക്കി ഉപയോഗിക്കാത്ത ഷാർഡുകൾ ഒപ്റ്റിമൈസ് ചെയ്യുക. ഈ സാഹചര്യത്തിൽ, തിരഞ്ഞെടുത്ത അന്വേഷണത്തിനിടയിൽ, എവിടെ എന്ന വിഭാഗത്തിലെ എക്സ്പ്രഷൻ വിശകലനം ചെയ്യുകയും ഷാർഡിംഗ് സ്കീം അനുസരിച്ച് ഏതൊക്കെ ഷാർഡുകൾ ഉപയോഗിക്കണമെന്ന് കണക്കാക്കുകയും ചെയ്യും. ഈ ഷാർഡിംഗ് സ്കീമിന് അനുസൃതമായി ഡാറ്റ കൃത്യമായി പാർട്ടീഷൻ ചെയ്തിട്ടുണ്ടെന്ന് ഇത് പ്രവർത്തിക്കുന്നു. നിങ്ങൾ അവ സ്വമേധയാ പുനഃക്രമീകരിച്ചാൽ, കത്തിടപാടുകൾ മാറിയേക്കാം.
അതിനാൽ ഇതാണ് രീതി നമ്പർ വൺ. നിങ്ങളുടെ ഉത്തരത്തിനായി ഞാൻ കാത്തിരിക്കുകയാണ്, രീതി അനുയോജ്യമാണോ, അല്ലെങ്കിൽ നമുക്ക് മുന്നോട്ട് പോകാം.
അവിറ്റോയിലെ ലീഡ് സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർ വ്‌ളാഡിമിർ കൊളോബേവ്: Alexey, വായനയുൾപ്പെടെയുള്ള ലോഡ് വ്യാപിപ്പിക്കേണ്ടിവരുമ്പോൾ നിങ്ങൾ സൂചിപ്പിച്ച രീതി നന്നായി പ്രവർത്തിക്കുന്നില്ല. നമുക്ക് പ്രതിമാസ പാർട്ടീഷൻ എടുക്കാം, കഴിഞ്ഞ മാസം മറ്റൊരു നോഡിലേക്ക് കൊണ്ടുപോകാം, എന്നാൽ ഈ ഡാറ്റയ്ക്കായി ഒരു അഭ്യർത്ഥന വരുമ്പോൾ, ഞങ്ങൾ അത് ലോഡ് ചെയ്യും. എന്നാൽ മുഴുവൻ ക്ലസ്റ്ററും ലോഡ് ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, അല്ലാത്തപക്ഷം, കുറച്ച് സമയത്തേക്ക് മുഴുവൻ റീഡിംഗ് ലോഡും രണ്ട് ഷാർഡുകൾ ഉപയോഗിച്ച് പ്രോസസ്സ് ചെയ്യും.
അലക്സി മിലോവിഡോവ്: ഇവിടെ ഉത്തരം വിചിത്രമാണ് - അതെ, ഇത് മോശമാണ്, പക്ഷേ ഇത് പ്രവർത്തിച്ചേക്കാം. എങ്ങനെയെന്ന് ഞാൻ കൃത്യമായി വിശദീകരിക്കും. നിങ്ങളുടെ ഡാറ്റയ്‌ക്കൊപ്പം വരുന്ന ലോഡ് സാഹചര്യം നോക്കുന്നത് മൂല്യവത്താണ്. ഇത് ഡാറ്റ മോണിറ്റർ ചെയ്യുകയാണെങ്കിൽ, ഭൂരിഭാഗം അഭ്യർത്ഥനകളും പുതിയ ഡാറ്റയ്‌ക്കായുള്ളതാണെന്ന് ഞങ്ങൾക്ക് ഉറപ്പായും പറയാൻ കഴിയും.
നിങ്ങൾ പുതിയ സെർവറുകൾ ഇൻസ്റ്റാൾ ചെയ്തു, പഴയ പാർട്ടീഷനുകൾ മൈഗ്രേറ്റ് ചെയ്തു, മാത്രമല്ല പുതിയ ഡാറ്റ റെക്കോർഡ് ചെയ്യുന്ന രീതിയും മാറ്റി. പുതിയ ഡാറ്റ മുഴുവൻ ക്ലസ്റ്ററിലുടനീളം വ്യാപിക്കും. അങ്ങനെ, വെറും അഞ്ച് മിനിറ്റിന് ശേഷം, അവസാന അഞ്ച് മിനിറ്റിനുള്ള അഭ്യർത്ഥനകൾ ക്ലസ്റ്ററിനെ തുല്യമായി ലോഡുചെയ്യും; ഒരു ദിവസത്തിന് ശേഷം, ഒരു ദിവസത്തേക്കുള്ള അഭ്യർത്ഥനകൾ ക്ലസ്റ്ററിനെ തുല്യമായി ലോഡുചെയ്യും. കഴിഞ്ഞ മാസത്തെ അഭ്യർത്ഥനകൾ, നിർഭാഗ്യവശാൽ, ക്ലസ്റ്റർ സെർവറുകളുടെ ഒരു ഭാഗത്തേക്ക് മാത്രമേ പോകൂ.
എന്നാൽ 2019 ഫെബ്രുവരിയിൽ നിങ്ങൾക്ക് പലപ്പോഴും അഭ്യർത്ഥനകൾ ഉണ്ടാകില്ല. മിക്കവാറും, അഭ്യർത്ഥനകൾ 2019-ലേക്ക് പോകുകയാണെങ്കിൽ, അവ 2019 മുഴുവനും ആയിരിക്കും - ഒരു വലിയ കാലയളവിലേക്കാണ്, അല്ലാതെ ചില ചെറിയ ശ്രേണിയിലല്ല. അത്തരം അഭ്യർത്ഥനകൾക്ക് ക്ലസ്റ്ററിനെ തുല്യമായി ലോഡുചെയ്യാനും കഴിയും. എന്നാൽ പൊതുവായി, ഇത് ഡാറ്റ പൂർണ്ണമായും തുല്യമായി പ്രചരിപ്പിക്കാത്ത ഒരു താൽക്കാലിക പരിഹാരമാണെന്ന നിങ്ങളുടെ പരാമർശം തികച്ചും ശരിയാണ്.
നിങ്ങളുടെ ചോദ്യത്തിന് ഉത്തരം നൽകാൻ എനിക്ക് കുറച്ച് പോയിന്റുകൾ കൂടിയുണ്ട്. അവയിലൊന്ന് തുടക്കത്തിൽ എങ്ങനെ ഒരു ഷാർഡിംഗ് സ്കീം ഉണ്ടാക്കാം എന്നതിനെക്കുറിച്ചാണ്, അങ്ങനെ വീണ്ടും ഷാർഡിംഗ് വേദന കുറയ്ക്കും. ഇത് എല്ലായ്പ്പോഴും സാധ്യമല്ല.
ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് നിരീക്ഷണ ഡാറ്റയുണ്ട്. മൂന്ന് കാരണങ്ങളാൽ മോണിറ്ററിംഗ് ഡാറ്റ വളരുന്നു. ആദ്യത്തേത് ചരിത്രപരമായ വിവരങ്ങളുടെ ശേഖരണമാണ്. രണ്ടാമത്തേത് ഗതാഗത വളർച്ചയാണ്. മൂന്നാമത്തേത് നിരീക്ഷണത്തിന് വിധേയമാകുന്ന കാര്യങ്ങളുടെ എണ്ണത്തിലുള്ള വർദ്ധനവാണ്. പുതിയ മൈക്രോസർവീസുകളും മെട്രിക്കുകളും സംരക്ഷിക്കേണ്ടതുണ്ട്.
ഇവയിൽ, ഏറ്റവും വലിയ വർദ്ധനവ് മൂന്നാമത്തെ കാരണവുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു - നിരീക്ഷണത്തിന്റെ ഉപയോഗത്തിലെ വർദ്ധനവ്. ഈ സാഹചര്യത്തിൽ, ലോഡിന്റെ സ്വഭാവം നോക്കുന്നത് മൂല്യവത്താണ്, തിരഞ്ഞെടുക്കുന്നതിനുള്ള പ്രധാന അഭ്യർത്ഥനകൾ എന്തൊക്കെയാണ്. അടിസ്ഥാന സെലക്ട് ക്വറികൾ മെട്രിക്കുകളുടെ ചില ഉപഗണങ്ങളെ അടിസ്ഥാനമാക്കിയായിരിക്കും.
ഉദാഹരണത്തിന്, ചില സേവനങ്ങൾ ചില സെർവറുകളിൽ CPU ഉപയോഗം. നിങ്ങൾക്ക് ഈ ഡാറ്റ ലഭിക്കുന്ന കീകളുടെ ഒരു പ്രത്യേക ഉപസെറ്റ് ഉണ്ടെന്ന് ഇത് മാറുന്നു. ഈ ഡാറ്റയ്‌ക്കായുള്ള അഭ്യർത്ഥന മിക്കവാറും വളരെ ലളിതവും പതിനായിരക്കണക്കിന് മില്ലിസെക്കൻഡിൽ പൂർത്തിയാകുന്നതുമാണ്. സേവനങ്ങളും ഡാഷ്‌ബോർഡുകളും നിരീക്ഷിക്കാൻ ഉപയോഗിക്കുന്നു. ഞാൻ ഇത് ശരിയായി മനസ്സിലാക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.
വ്ലാഡിമിർ കൊളോബേവ്: നിലവിലെ സാഹചര്യത്തെ ചരിത്രവുമായി തത്സമയം താരതമ്യം ചെയ്യുന്നതിനാൽ ഞങ്ങൾ പലപ്പോഴും ചരിത്രപരമായ ഡാറ്റയെ ആകർഷിക്കുന്നു എന്നതാണ് വസ്തുത. ഞങ്ങൾക്ക് വലിയ അളവിലുള്ള ഡാറ്റയിലേക്ക് പെട്ടെന്ന് ആക്സസ് ഉണ്ടായിരിക്കേണ്ടത് പ്രധാനമാണ്, കൂടാതെ ClickHouse ഇത് ഒരു മികച്ച ജോലി ചെയ്യുന്നു.
നിങ്ങൾ പറഞ്ഞത് തികച്ചും ശരിയാണ്, ഏതൊരു മോണിറ്ററിംഗ് സിസ്റ്റത്തെയും പോലെ, കഴിഞ്ഞ ദിവസമാണ് ഞങ്ങൾ മിക്ക വായനാ അഭ്യർത്ഥനകളും അനുഭവിക്കുന്നത്. എന്നാൽ അതേ സമയം, ചരിത്രപരമായ ഡാറ്റയുടെ ലോഡും വളരെ വലുതാണ്. ഇത് അടിസ്ഥാനപരമായി ഓരോ മുപ്പത് സെക്കൻഡിലും പോകുന്ന ഒരു അലേർട്ടിംഗ് സിസ്റ്റത്തിൽ നിന്നാണ്, ക്ലിക്ക്ഹൗസിനോട് ഇങ്ങനെ പറയുന്നു: “കഴിഞ്ഞ ആറാഴ്ചത്തെ ഡാറ്റ എനിക്ക് തരൂ. ഇപ്പോൾ എനിക്ക് അവയിൽ നിന്ന് ഒരുതരം ചലിക്കുന്ന ശരാശരി ഉണ്ടാക്കുക, നമുക്ക് നിലവിലെ മൂല്യത്തെ ചരിത്രവുമായി താരതമ്യം ചെയ്യാം.
അത്തരം സമീപകാല അഭ്യർത്ഥനകൾക്കായി ഞങ്ങൾക്ക് മറ്റൊരു ചെറിയ ടേബിൾ ഉണ്ടെന്ന് പറയാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, അതിൽ ഞങ്ങൾ രണ്ട് ദിവസത്തെ ഡാറ്റ മാത്രം സംഭരിക്കുന്നു, പ്രധാന അഭ്യർത്ഥനകൾ അതിലേക്ക് പറക്കുന്നു. വലിയ ചരിത്രപരമായ അന്വേഷണങ്ങൾ മാത്രമാണ് ഞങ്ങൾ വലിയ ഷാർഡ് ടേബിളിലേക്ക് അയയ്ക്കുന്നത്.
അലക്സി മിലോവിഡോവ്: നിർഭാഗ്യവശാൽ, നിങ്ങളുടെ സാഹചര്യത്തിന് ഇത് നന്നായി പ്രവർത്തിക്കില്ല, എന്നാൽ നിങ്ങൾ ഉപയോഗിക്കേണ്ടതില്ലാത്തതും എന്നാൽ എന്റെ സുഹൃത്തുക്കളുടെ സേവനത്തിൽ ഉപയോഗിക്കുന്നതുമായ രണ്ട് മോശവും സങ്കീർണ്ണവുമായ ഷാർഡിംഗ് സ്കീമുകൾ ഞാൻ വിവരിക്കും.
Yandex.Metrica ഇവന്റുകളുള്ള ഒരു പ്രധാന ക്ലസ്റ്റർ ഉണ്ട്. ഇവന്റുകൾ പേജ് കാഴ്ചകൾ, ക്ലിക്കുകൾ, പരിവർത്തനങ്ങൾ എന്നിവയാണ്. മിക്ക അഭ്യർത്ഥനകളും ഒരു നിർദ്ദിഷ്ട വെബ്‌സൈറ്റിലേക്കാണ് പോകുന്നത്. നിങ്ങൾ Yandex.Metrica സേവനം തുറക്കുന്നു, നിങ്ങൾക്ക് ഒരു വെബ്സൈറ്റ് ഉണ്ട് - avito.ru, റിപ്പോർട്ടിലേക്ക് പോകുക, നിങ്ങളുടെ വെബ്സൈറ്റിനായി ഒരു അഭ്യർത്ഥന നടത്തുന്നു.
എന്നാൽ മറ്റ് അഭ്യർത്ഥനകൾ ഉണ്ട് - വിശകലനപരവും ആഗോളവും - ആന്തരിക വിശകലന വിദഗ്ധർ. ഒരു സാഹചര്യത്തിലും, ആന്തരിക വിശകലന വിദഗ്ധർ Yandex സേവനങ്ങൾക്കായി മാത്രം അഭ്യർത്ഥനകൾ നടത്തുന്നുണ്ടെന്ന് ഞാൻ ശ്രദ്ധിക്കും. എന്നിരുന്നാലും, Yandex സേവനങ്ങൾ പോലും എല്ലാ ഡാറ്റയുടെയും ഒരു പ്രധാന പങ്ക് വഹിക്കുന്നു. ഇത് പ്രത്യേക കൗണ്ടറുകൾക്കായുള്ള അഭ്യർത്ഥനകളല്ല, മറിച്ച് വിശാലമായ ഫിൽട്ടറിംഗിനുള്ള അഭ്യർത്ഥനകളാണ്.
ആഗോള അന്വേഷണങ്ങൾ ഉൾപ്പെടെ ഒരു കൗണ്ടറിനായി എല്ലാം കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്ന തരത്തിൽ ഡാറ്റ എങ്ങനെ ഓർഗനൈസുചെയ്യാം? മെട്രിക്സ് ക്ലസ്റ്ററിനായുള്ള ക്ലിക്ക്ഹൗസിലെ അഭ്യർത്ഥനകളുടെ എണ്ണം സെക്കൻഡിൽ ആയിരക്കണക്കിന് ആണ് എന്നതാണ് മറ്റൊരു ബുദ്ധിമുട്ട്. അതേ സമയം, ഒരു ClickHouse സെർവറിന് നിസ്സാരമല്ലാത്ത അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ കഴിയില്ല, ഉദാഹരണത്തിന്, സെക്കൻഡിൽ ആയിരക്കണക്കിന്.
ക്ലസ്റ്റർ വലുപ്പം അറുനൂറോളം സെർവറുകളാണ്. നിങ്ങൾ ഈ ക്ലസ്റ്ററിന് മുകളിലൂടെ ഒരു ഡിസ്ട്രിബ്യൂട്ടഡ് ടേബിൾ വലിച്ചിട്ട് അവിടെ ആയിരക്കണക്കിന് അഭ്യർത്ഥനകൾ അയയ്ക്കുകയാണെങ്കിൽ, അത് ഒരു സെർവറിലേക്ക് അയയ്ക്കുന്നതിനേക്കാൾ മോശമായിരിക്കും. മറുവശത്ത്, ഡാറ്റ തുല്യമായി വ്യാപിക്കുകയും ഞങ്ങൾ പോയി എല്ലാ സെർവറുകളിൽ നിന്നും അഭ്യർത്ഥിക്കുകയും ചെയ്യുന്നു എന്ന ഓപ്ഷൻ ഉടനടി നിരാകരിക്കപ്പെടുന്നു.
തികച്ചും വിപരീതമായ ഒരു ഓപ്ഷൻ ഉണ്ട്. ഞങ്ങൾ സൈറ്റുകളിലുടനീളം ഡാറ്റ പങ്കിടുകയാണെങ്കിൽ, ഒരു സൈറ്റിനായുള്ള അഭ്യർത്ഥന ഒരു ഷാർഡിലേക്ക് പോകുകയാണെങ്കിൽ സങ്കൽപ്പിക്കുക. ഇപ്പോൾ ക്ലസ്റ്ററിന് സെക്കൻഡിൽ പതിനായിരം അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ കഴിയും, എന്നാൽ ഒരു ഷാർഡിൽ ഏതെങ്കിലും ഒരു അഭ്യർത്ഥന വളരെ സാവധാനത്തിൽ പ്രവർത്തിക്കും. ബാൻഡ്‌വിഡ്‌ത്തിന്റെ കാര്യത്തിൽ ഇത് മേലിൽ സ്കെയിൽ ചെയ്യില്ല. പ്രത്യേകിച്ചും ഇത് avito.ru എന്ന സൈറ്റാണെങ്കിൽ. RuNet-ൽ ഏറ്റവുമധികം ആളുകൾ സന്ദർശിക്കുന്ന സൈറ്റുകളിൽ ഒന്നാണ് Avito എന്ന് ഞാൻ പറഞ്ഞാൽ ഞാൻ രഹസ്യം വെളിപ്പെടുത്തില്ല. ഒരു ചില്ലിൽ ഇത് പ്രോസസ്സ് ചെയ്യുന്നത് ഭ്രാന്തായിരിക്കും.
അതിനാൽ, ഷാർഡിംഗ് സ്കീം കൂടുതൽ തന്ത്രപരമായ രീതിയിലാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. മുഴുവൻ ക്ലസ്റ്ററും നിരവധി ക്ലസ്റ്ററുകളായി തിരിച്ചിരിക്കുന്നു, അതിനെ ഞങ്ങൾ പാളികൾ എന്ന് വിളിക്കുന്നു. ഓരോ ക്ലസ്റ്ററിലും പത്ത് മുതൽ നിരവധി ഡസൻ വരെ കഷ്ണങ്ങൾ അടങ്ങിയിരിക്കുന്നു. മൊത്തത്തിൽ മുപ്പത്തിയൊമ്പത് ക്ലസ്റ്ററുകളുണ്ട്.
ഇതെല്ലാം എങ്ങനെയാണ് സ്കെയിൽ ചെയ്യുന്നത്? ക്ലസ്റ്ററുകളുടെ എണ്ണം മാറുന്നില്ല - കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ് ഇത് മുപ്പത്തിയൊമ്പത് ആയിരുന്നതിനാൽ, അത് അങ്ങനെ തന്നെ തുടരുന്നു. എന്നാൽ അവയിൽ ഓരോന്നിനും ഉള്ളിൽ, ഡാറ്റ കുമിഞ്ഞുകൂടുന്നതിനനുസരിച്ച് ഞങ്ങൾ ചില്ലുകളുടെ എണ്ണം ക്രമേണ വർദ്ധിപ്പിക്കുന്നു. പൊതുവെ ഷാർഡിംഗ് സ്കീം ഇതാണ്: ഈ ക്ലസ്റ്ററുകളിലേക്കുള്ള വിഭജനം വെബ്‌സൈറ്റുകളിലുടനീളം സംഭവിക്കുന്നു, ഏത് ക്ലസ്റ്ററിലാണ് സൈറ്റ് എന്ന് മനസിലാക്കാൻ, MySQL-ൽ ഒരു പ്രത്യേക മെറ്റാബേസ് ഉപയോഗിക്കുന്നു. ഒരു ക്ലസ്റ്ററിൽ ഒരു സൈറ്റ്. അതിനുള്ളിൽ, സന്ദർശക ഐഡികളെ അടിസ്ഥാനമാക്കിയാണ് ഷാർഡിംഗ് സംഭവിക്കുന്നത്.
റെക്കോർഡ് ചെയ്യുമ്പോൾ, സന്ദർശക ഐഡിയുടെ ഡിവിഷന്റെ ശേഷിക്കുന്ന ഭാഗം കൊണ്ട് ഞങ്ങൾ അവയെ വിഭജിക്കുന്നു. എന്നാൽ ഞങ്ങൾ ഒരു പുതിയ ഷാർഡ് ചേർക്കുമ്പോൾ, ഷാർഡിംഗ് സ്കീം മാറുന്നു, ഞങ്ങൾ വിഭജിക്കുന്നത് തുടരുന്നു, എന്നാൽ ഡിവിഷന്റെ ശേഷിക്കുന്ന ഭാഗം മറ്റൊരു സംഖ്യകൊണ്ട്. ഇതിനർത്ഥം ഒരു സന്ദർശകൻ ഇതിനകം നിരവധി സെർവറുകളിൽ സ്ഥിതിചെയ്യുന്നു, നിങ്ങൾക്ക് ഇതിൽ ആശ്രയിക്കാൻ കഴിയില്ല. ഡാറ്റ മികച്ച രീതിയിൽ കംപ്രസ്സുചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കാൻ മാത്രമാണ് ഇത് ചെയ്യുന്നത്. അന്വേഷണങ്ങൾ നടത്തുമ്പോൾ, ഞങ്ങൾ ഡിസ്ട്രിബ്യൂട്ടഡ് ടേബിളിലേക്ക് പോകുന്നു, അത് ക്ലസ്റ്ററിലേക്ക് നോക്കുകയും ഡസൻ കണക്കിന് സെർവറുകൾ ആക്സസ് ചെയ്യുകയും ചെയ്യുന്നു. ഇതൊരു മണ്ടത്തരമാണ്.
എന്നാൽ ഞങ്ങൾ ഈ പദ്ധതി ഉപേക്ഷിച്ചുവെന്ന് ഞാൻ പറഞ്ഞില്ലെങ്കിൽ എന്റെ കഥ അപൂർണ്ണമായിരിക്കും. പുതിയ സ്കീമിൽ, ക്ലിക്ക്ഹൗസ്-കോപ്പിയർ ഉപയോഗിച്ച് ഞങ്ങൾ എല്ലാം മാറ്റി എല്ലാ ഡാറ്റയും പകർത്തി.
പുതിയ സ്കീമിൽ, എല്ലാ സൈറ്റുകളും രണ്ട് വിഭാഗങ്ങളായി തിരിച്ചിരിക്കുന്നു - വലുതും ചെറുതുമായ. ത്രെഷോൾഡ് എങ്ങനെ തിരഞ്ഞെടുത്തുവെന്ന് എനിക്കറിയില്ല, പക്ഷേ വലിയ സൈറ്റുകൾ ഒരു ക്ലസ്റ്ററിൽ രേഖപ്പെടുത്തിയിട്ടുണ്ട്, അവിടെ മൂന്ന് പകർപ്പുകളുള്ള 120 ഷാർഡുകൾ ഉണ്ട് - അതായത് 360 സെർവറുകൾ. ഏത് അഭ്യർത്ഥനയും ഒരേസമയം എല്ലാ ഷാർഡുകളിലേക്കും പോകുന്ന തരത്തിലാണ് ഷാർഡിംഗ് സ്കീം. നിങ്ങൾ ഇപ്പോൾ Yandex.Metrica-യിൽ avito.ru-യ്‌ക്കായി ഏതെങ്കിലും റിപ്പോർട്ട് പേജ് തുറക്കുകയാണെങ്കിൽ, അഭ്യർത്ഥന 120 സെർവറുകളിലേക്ക് പോകും. RuNet-ൽ കുറച്ച് വലിയ സൈറ്റുകളുണ്ട്. അഭ്യർത്ഥനകൾ സെക്കൻഡിൽ ആയിരമല്ല, നൂറിൽ താഴെയാണ്. ഇവയെല്ലാം 120 സെർവറുകൾ ഉപയോഗിച്ച് പ്രോസസ്സ് ചെയ്യുന്ന ഡിസ്ട്രിബ്യൂട്ടഡ് ടേബിൾ നിശബ്ദമായി ചവച്ചരച്ചിരിക്കുന്നു.
രണ്ടാമത്തെ ക്ലസ്റ്റർ ചെറിയ സൈറ്റുകൾക്കുള്ളതാണ്. സൈറ്റ് ഐഡിയെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു ഷാർഡിംഗ് സ്കീം ഇതാ, ഓരോ അഭ്യർത്ഥനയും കൃത്യമായി ഒരു ഷാർഡിലേക്ക് പോകുന്നു.
ClickHouse-ന് ഒരു clickhouse-copier യൂട്ടിലിറ്റി ഉണ്ട്. അവളെ കുറിച്ച് പറയാമോ?
ഈ പരിഹാരം കൂടുതൽ ബുദ്ധിമുട്ടുള്ളതും കുറച്ച് ഉൽപ്പാദനക്ഷമതയുള്ളതുമാണെന്ന് ഞാൻ ഉടൻ പറയും. നിങ്ങൾ വ്യക്തമാക്കുന്ന പാറ്റേൺ അനുസരിച്ച് ഇത് ഡാറ്റയെ പൂർണ്ണമായും സ്മിയർ ചെയ്യുന്നു എന്നതാണ് നേട്ടം. എന്നാൽ യൂട്ടിലിറ്റിയുടെ പോരായ്മ അത് പുനർനിർമ്മിക്കുന്നില്ല എന്നതാണ്. ഇത് ഒരു ക്ലസ്റ്റർ സ്കീമയിൽ നിന്ന് മറ്റൊരു ക്ലസ്റ്റർ സ്കീമയിലേക്ക് ഡാറ്റ പകർത്തുന്നു.
ഇതിനർത്ഥം ഇത് പ്രവർത്തിക്കാൻ നിങ്ങൾക്ക് രണ്ട് ക്ലസ്റ്ററുകൾ ഉണ്ടായിരിക്കണം എന്നാണ്. അവ ഒരേ സെർവറുകളിൽ സ്ഥിതിചെയ്യാം, എന്നിരുന്നാലും, ഡാറ്റ ക്രമാനുഗതമായി നീക്കില്ല, പക്ഷേ പകർത്തപ്പെടും.
ഉദാഹരണത്തിന്, നാല് സെർവറുകൾ ഉണ്ടായിരുന്നു, ഇപ്പോൾ എട്ട് ഉണ്ട്. നിങ്ങൾ എല്ലാ സെർവറുകളിലും പുതിയ ലോക്കൽ ടേബിളുകളിലും ഒരു പുതിയ ഡിസ്ട്രിബ്യൂട്ടഡ് ടേബിൾ സൃഷ്ടിക്കുകയും ക്ലിക്ക്ഹൗസ്-കോപ്പിയർ സമാരംഭിക്കുകയും ചെയ്യുക, അതിൽ വർക്ക് സ്കീമിനെ സൂചിപ്പിക്കുന്നു, അത് അവിടെ നിന്ന് വായിക്കുകയും പുതിയ ഷാർഡിംഗ് സ്കീം അംഗീകരിക്കുകയും ഡാറ്റ അവിടെ കൈമാറുകയും വേണം. പഴയ സെർവറുകളിൽ നിങ്ങൾക്ക് ഇപ്പോൾ ഉള്ളതിനേക്കാൾ ഒന്നര മടങ്ങ് കൂടുതൽ സ്ഥലം ആവശ്യമാണ്, കാരണം പഴയ ഡാറ്റ അവയിൽ നിലനിൽക്കണം, അതേ പഴയ ഡാറ്റയുടെ പകുതി അവയ്ക്ക് മുകളിൽ എത്തും. ഡാറ്റ പുനഃക്രമീകരിക്കേണ്ടതുണ്ടെന്നും സ്ഥലമുണ്ടെന്നും നിങ്ങൾ മുൻകൂട്ടി കരുതിയിരുന്നെങ്കിൽ, ഈ രീതി അനുയോജ്യമാണ്.
ക്ലിക്ക്ഹൗസ്-കോപ്പിയർ എങ്ങനെയാണ് ഉള്ളിൽ പ്രവർത്തിക്കുന്നത്? ഒരു ടേബിളിന്റെ ഒരു പാർട്ടീഷൻ ഒരു ഷാർഡിൽ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള ഒരു കൂട്ടം ടാസ്‌ക്കുകളായി ഇത് എല്ലാ ജോലികളെയും വിഭജിക്കുന്നു. ഈ ടാസ്‌ക്കുകളെല്ലാം സമാന്തരമായി നിർവഹിക്കാൻ കഴിയും, കൂടാതെ ക്ലിക്ക്ഹൗസ്-കോപ്പിയർ വിവിധ മെഷീനുകളിൽ ഒന്നിലധികം സന്ദർഭങ്ങളിൽ പ്രവർത്തിപ്പിക്കാം, എന്നാൽ ഒരു ബാച്ചിനായി ഇത് ചെയ്യുന്നത് ഒരു തിരുകൽ തിരഞ്ഞെടുക്കലല്ലാതെ മറ്റൊന്നുമല്ല. ഡാറ്റ വായിക്കുകയും ഡീകംപ്രസ്സ് ചെയ്യുകയും വീണ്ടും പാർട്ടീഷൻ ചെയ്യുകയും വീണ്ടും കംപ്രസ് ചെയ്യുകയും എവിടെയെങ്കിലും എഴുതുകയും വീണ്ടും അടുക്കുകയും ചെയ്യുന്നു. ഇത് കൂടുതൽ കടുത്ത തീരുമാനമാണ്.
നിങ്ങൾക്ക് റീഷാർഡിംഗ് എന്ന ഒരു പൈലറ്റ് സംഗതി ഉണ്ടായിരുന്നു. അവൾക്ക് എന്ത് പറ്റി?
2017-ൽ, നിങ്ങൾക്ക് റീഷാർഡിംഗ് എന്ന ഒരു പൈലറ്റ് സംഗതി ഉണ്ടായിരുന്നു. ക്ലിക്ക്ഹൗസിൽ ഒരു ഓപ്ഷൻ പോലും ഉണ്ട്. ഞാൻ മനസ്സിലാക്കിയതുപോലെ, അത് എടുത്തില്ല. എന്തുകൊണ്ടാണ് ഇത് സംഭവിച്ചതെന്ന് എന്നോട് പറയാമോ? അത് വളരെ പ്രസക്തമാണെന്ന് തോന്നുന്നു.
ഡാറ്റ പുനഃക്രമീകരിക്കേണ്ടിവരുമ്പോൾ, ഇത് ആറ്റോമികമായി ചെയ്യുന്നതിന് വളരെ സങ്കീർണ്ണമായ സമന്വയം ആവശ്യമാണ് എന്നതാണ് മുഴുവൻ പ്രശ്‌നവും. ഈ സമന്വയം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നോക്കാൻ തുടങ്ങിയപ്പോൾ, അടിസ്ഥാനപരമായ പ്രശ്‌നങ്ങളുണ്ടെന്ന് വ്യക്തമായി. ഈ അടിസ്ഥാന പ്രശ്നങ്ങൾ സൈദ്ധാന്തികം മാത്രമല്ല, വളരെ ലളിതമായി വിശദീകരിക്കാൻ കഴിയുന്ന ഒന്നിന്റെ രൂപത്തിൽ ഉടൻ തന്നെ പ്രായോഗികമായി സ്വയം കാണിക്കാൻ തുടങ്ങി - ഒന്നും പ്രവർത്തിക്കുന്നില്ല.
സ്ലോ ഡിസ്കുകളിലേക്ക് നീക്കുന്നതിന് മുമ്പ് എല്ലാ ഡാറ്റയും ഒരുമിച്ച് ലയിപ്പിക്കാൻ കഴിയുമോ?
ലയനത്തിന്റെ പശ്ചാത്തലത്തിൽ സ്ലോ ഡിസ്ക് ഓപ്ഷനിലേക്കുള്ള നീക്കത്തോടുകൂടിയ TTL നെക്കുറിച്ചുള്ള ചോദ്യം. സ്ലോ ഡിസ്കുകളിലേക്ക് നീക്കുന്നതിന് മുമ്പ്, എല്ലാ ഭാഗങ്ങളും ഒന്നായി ലയിപ്പിക്കുന്നതിന്, ക്രോൺ ഉപയോഗിക്കാതെ മറ്റെന്തെങ്കിലും മാർഗമുണ്ടോ?
കൈമാറ്റം ചെയ്യുന്നതിനുമുമ്പ് എല്ലാ കഷണങ്ങളും സ്വപ്രേരിതമായി ഒട്ടിക്കാൻ കഴിയുമോ എന്ന ചോദ്യത്തിനുള്ള ഉത്തരം ഇല്ല. ഇത് ആവശ്യമില്ലെന്ന് എനിക്ക് തോന്നുന്നു. നിങ്ങൾ എല്ലാ ഭാഗങ്ങളും ഒന്നായി ലയിപ്പിക്കേണ്ടതില്ല, എന്നാൽ അവ യാന്ത്രികമായി സ്ലോ ഡിസ്കുകളിലേക്ക് മാറ്റുന്നത് കണക്കാക്കുക.
ട്രാൻസ്ഫർ നിയമങ്ങൾക്ക് ഞങ്ങൾക്ക് രണ്ട് മാനദണ്ഡങ്ങളുണ്ട്. ആദ്യത്തേത് പൂരിപ്പിക്കൽ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. നിലവിലെ സ്റ്റോറേജ് ലെവലിൽ ഒരു നിശ്ചിത ശതമാനത്തിൽ താഴെ സ്ഥലമുണ്ടെങ്കിൽ, ഞങ്ങൾ ഒരു കഷണം തിരഞ്ഞെടുത്ത് സ്ലോ സ്റ്റോറേജിലേക്ക് മാറ്റും. അല്ലെങ്കിൽ, മന്ദഗതിയിലല്ല, അടുത്തത്, നിങ്ങൾ കോൺഫിഗർ ചെയ്യുന്നതുപോലെ.
രണ്ടാമത്തെ മാനദണ്ഡം വലുപ്പമാണ്. ഇത് വലിയ കഷണങ്ങൾ ചുമക്കുന്നതിനെക്കുറിച്ചാണ്. ഫാസ്റ്റ് ഡിസ്കിലെ ശൂന്യമായ ഇടത്തെ അടിസ്ഥാനമാക്കി നിങ്ങൾക്ക് പരിധി ക്രമീകരിക്കാൻ കഴിയും, കൂടാതെ ഡാറ്റ യാന്ത്രികമായി കൈമാറ്റം ചെയ്യപ്പെടും.
മുൻകൂട്ടി അനുയോജ്യത പരിശോധിക്കാൻ ഒരു മാർഗവുമില്ലെങ്കിൽ, ClickHouse-ന്റെ പുതിയ പതിപ്പുകളിലേക്ക് എങ്ങനെ മൈഗ്രേറ്റ് ചെയ്യാം?
ഈ വിഷയം പതിവായി ചർച്ച ചെയ്യപ്പെടുന്നു വ്യത്യസ്ത പതിപ്പുകൾ കണക്കിലെടുക്കുന്നു, ഇപ്പോഴും. പതിപ്പ് 19.11 ൽ നിന്ന് 19.16 ലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുന്നത് എത്ര സുരക്ഷിതമാണ്, ഉദാഹരണത്തിന്, 19.16 ൽ നിന്ന് 20.3 ലേക്ക്. സാൻഡ്‌ബോക്‌സിലെ അനുയോജ്യത മുൻകൂട്ടി പരിശോധിക്കാൻ കഴിയാതെ പുതിയ പതിപ്പുകളിലേക്ക് നീങ്ങാനുള്ള ഏറ്റവും നല്ല മാർഗം ഏതാണ്?
ഇവിടെ നിരവധി "സുവർണ്ണ" നിയമങ്ങളുണ്ട്. ആദ്യം - . ഇത് വലുതാണ്, പക്ഷേ പിന്നിലേക്ക് പൊരുത്തപ്പെടാത്ത മാറ്റങ്ങളെക്കുറിച്ച് പ്രത്യേക ഖണ്ഡികകളുണ്ട്. ഈ പോയിന്റുകളെ ഒരു ചെങ്കൊടിയായി കണക്കാക്കരുത്. ഇവ സാധാരണയായി നിങ്ങൾ ഉപയോഗിക്കാത്ത ചില എഡ്ജ് പ്രവർത്തനങ്ങളുമായി ബന്ധപ്പെട്ട ചെറിയ പൊരുത്തക്കേടുകളാണ്.
രണ്ടാമതായി, സാൻഡ്‌ബോക്‌സിൽ അനുയോജ്യത പരിശോധിക്കാൻ ഒരു മാർഗവുമില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഉൽ‌പാദനത്തിൽ ഉടനടി അപ്ഡേറ്റ് ചെയ്യണമെങ്കിൽ, നിങ്ങൾ ഇത് ചെയ്യേണ്ടതില്ല എന്നതാണ് ശുപാർശ. ആദ്യം ഒരു സാൻഡ്ബോക്സ് ഉണ്ടാക്കി പരീക്ഷിക്കുക. ടെസ്റ്റ് പരിതസ്ഥിതി ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് മിക്കവാറും ഒരു വലിയ കമ്പനി ഇല്ല, അതിനർത്ഥം നിങ്ങളുടെ ലാപ്‌ടോപ്പിലേക്ക് കുറച്ച് ഡാറ്റ പകർത്താനും അതിൽ എല്ലാം ശരിയായി പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കാനും നിങ്ങൾക്ക് കഴിയും. നിങ്ങളുടെ മെഷീനിൽ പ്രാദേശികമായി നിരവധി പകർപ്പുകൾ ഉയർത്താനും കഴിയും. അല്ലെങ്കിൽ നിങ്ങൾക്ക് സമീപത്ത് എവിടെയെങ്കിലും ഒരു പുതിയ പതിപ്പ് എടുത്ത് അവിടെ കുറച്ച് ഡാറ്റ അപ്‌ലോഡ് ചെയ്യാം - അതായത്, ഒരു മെച്ചപ്പെടുത്തിയ പരീക്ഷണ അന്തരീക്ഷം സൃഷ്ടിക്കുക.
നിർമ്മാണത്തിലെ ബഗുകളും തുടർന്നുള്ള ദ്രുത പരിഹാരങ്ങളും കാരണം പതിപ്പ് പുറത്തിറങ്ങി ഒരാഴ്ചത്തേക്ക് അപ്ഡേറ്റ് ചെയ്യരുത് എന്നതാണ് മറ്റൊരു നിയമം. ആശയക്കുഴപ്പത്തിലാകാതിരിക്കാൻ ക്ലിക്ക്ഹൗസ് പതിപ്പുകളുടെ നമ്പറിംഗ് നമുക്ക് കണ്ടെത്താം.
20.3.4 പതിപ്പുണ്ട്. നമ്പർ 20 നിർമ്മാണ വർഷത്തെ സൂചിപ്പിക്കുന്നു - 2020. ഉള്ളിലുള്ളതിന്റെ വീക്ഷണകോണിൽ നിന്ന് ഇത് പ്രശ്നമല്ല, അതിനാൽ ഞങ്ങൾ ഇത് ശ്രദ്ധിക്കില്ല. അടുത്തത് 20.3 ആണ്. ഞങ്ങൾ രണ്ടാമത്തെ നമ്പർ വർദ്ധിപ്പിക്കുന്നു - ഈ സാഹചര്യത്തിൽ 3 - ഓരോ തവണയും ഞങ്ങൾ ചില പുതിയ പ്രവർത്തനങ്ങളോടെ ഒരു റിലീസ് റിലീസ് ചെയ്യുന്നു. ClickHouse-ൽ എന്തെങ്കിലും ഫീച്ചർ ചേർക്കണമെങ്കിൽ, ഈ എണ്ണം കൂട്ടണം. അതായത്, 20.4 പതിപ്പിൽ ക്ലിക്ക്ഹൗസ് കൂടുതൽ നന്നായി പ്രവർത്തിക്കും. മൂന്നാമത്തെ അക്കം 20.3.4 ആണ്. ഞങ്ങൾ പുതിയ ഫീച്ചറുകൾ ചേർക്കാതെ ചില ബഗുകൾ പരിഹരിച്ച പാച്ച് റിലീസുകളുടെ എണ്ണം ഇവിടെ 4 ആണ്. 4 എന്നതിനർത്ഥം ഞങ്ങൾ ഇത് നാല് തവണ ചെയ്തു എന്നാണ്.
ഇത് ഭയങ്കരമായ ഒന്നാണെന്ന് കരുതരുത്. സാധാരണഗതിയിൽ, ഒരു ഉപയോക്താവിന് ഏറ്റവും പുതിയ പതിപ്പ് ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും, കൂടാതെ ഇത് പ്രതിവർഷം പ്രവർത്തനസമയത്ത് പ്രശ്‌നങ്ങളൊന്നുമില്ലാതെ പ്രവർത്തിക്കും. എന്നാൽ നമ്മുടെ ചൈനീസ് സഖാക്കൾ ചേർത്ത ബിറ്റ്മാപ്പുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുള്ള ചില ഫംഗ്ഷനുകളിൽ, തെറ്റായ ആർഗ്യുമെന്റുകൾ നൽകുമ്പോൾ സെർവർ തകരാറിലാകുമെന്ന് സങ്കൽപ്പിക്കുക. ഇത് പരിഹരിക്കാനുള്ള ഉത്തരവാദിത്തം നമുക്കുണ്ട്. ഞങ്ങൾ ഒരു പുതിയ പാച്ച് പതിപ്പ് പുറത്തിറക്കുകയും ClickHouse കൂടുതൽ സ്ഥിരത കൈവരിക്കുകയും ചെയ്യും.
നിങ്ങൾക്ക് ClickHouse പ്രൊഡക്ഷനിൽ പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, കൂടുതൽ ഫീച്ചറുകളോടെ ClickHouse-ന്റെ ഒരു പുതിയ പതിപ്പ് പുറത്തുവരുന്നുവെങ്കിൽ - ഉദാഹരണത്തിന്, 20.4.1 ആദ്യത്തേതാണ്, ആദ്യ ദിവസം തന്നെ അത് നിർമ്മിക്കാൻ തിരക്കുകൂട്ടരുത്. എന്തുകൊണ്ടാണ് ഇത് പൂർണ്ണമായും ആവശ്യമായി വരുന്നത്? നിങ്ങൾ ഇതുവരെ ClickHouse ഉപയോഗിക്കുന്നില്ലെങ്കിൽ, നിങ്ങൾക്കത് ഇൻസ്റ്റാൾ ചെയ്യാം, മിക്കവാറും എല്ലാം ശരിയാകും. എന്നാൽ ClickHouse ഇതിനകം സുസ്ഥിരമായി പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, ഞങ്ങൾ എന്തൊക്കെ പ്രശ്‌നങ്ങളാണ് പരിഹരിക്കുന്നതെന്ന് കാണുന്നതിന് പാച്ചുകളിലും അപ്‌ഡേറ്റുകളിലും ശ്രദ്ധിക്കുക.
കിറിൽ ഷ്വാക്കോവ്: ടെസ്റ്റ് പരിതസ്ഥിതികളെക്കുറിച്ച് കുറച്ച് ചേർക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. എല്ലാവരും ടെസ്റ്റ് പരിതസ്ഥിതികളെ വളരെയധികം ഭയപ്പെടുന്നു, ചില കാരണങ്ങളാൽ നിങ്ങൾക്ക് വളരെ വലിയ ക്ലിക്ക്ഹൗസ് ക്ലസ്റ്റർ ഉണ്ടെങ്കിൽ, ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ കുറവോ പത്തിരട്ടിയെങ്കിലും ചെറുതോ ആയിരിക്കണമെന്ന് അവർ വിശ്വസിക്കുന്നു. അത് അങ്ങനെയല്ല.
എന്റെ സ്വന്തം ഉദാഹരണത്തിൽ നിന്ന് എനിക്ക് നിങ്ങളോട് പറയാൻ കഴിയും. എനിക്ക് ഒരു പ്രോജക്റ്റ് ഉണ്ട്, അവിടെ ClickHouse ഉണ്ട്. ഇരുപത് യൂറോയ്ക്ക് ഹെറ്റ്‌സ്‌നറിലെ ഒരു ചെറിയ വെർച്വൽ മെഷീനാണ് അവനുവേണ്ടിയുള്ള ഞങ്ങളുടെ പരീക്ഷണ അന്തരീക്ഷം, അവിടെ എല്ലാം വിന്യസിച്ചിരിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾക്ക് Ansible-ൽ പൂർണ്ണ ഓട്ടോമേഷൻ ഉണ്ട്, അതിനാൽ, തത്വത്തിൽ, എവിടെ പോകണം എന്നത് ഒരു വ്യത്യാസവുമില്ല - ഹാർഡ്‌വെയർ സെർവറുകളിലേക്ക് അല്ലെങ്കിൽ വെർച്വൽ മെഷീനുകളിൽ വിന്യസിക്കുക.
എന്ത് ചെയ്യാൻ കഴിയും? സ്വന്തമായി ഒരു ചെറിയ ക്ലസ്റ്റർ എങ്ങനെ വിന്യസിക്കാം എന്നതിന് ClickHouse ഡോക്യുമെന്റേഷനിൽ ഒരു ഉദാഹരണം നൽകുന്നത് നന്നായിരിക്കും - ഡോക്കറിൽ, LXC-യിൽ, ഒരുപക്ഷേ ഒരു Ansible പ്ലേബുക്ക് സൃഷ്ടിക്കുക, കാരണം വ്യത്യസ്ത ആളുകൾക്ക് വ്യത്യസ്ത വിന്യാസങ്ങളുണ്ട്. ഇത് വളരെയധികം ലളിതമാക്കും. നിങ്ങൾ അഞ്ച് മിനിറ്റിനുള്ളിൽ ഒരു ക്ലസ്റ്റർ എടുത്ത് വിന്യസിക്കുമ്പോൾ, എന്തെങ്കിലും കണ്ടുപിടിക്കാൻ ശ്രമിക്കുന്നത് വളരെ എളുപ്പമാണ്. ഇത് കൂടുതൽ സൗകര്യപ്രദമാണ്, കാരണം നിങ്ങൾ പരിശോധിച്ചിട്ടില്ലാത്ത ഒരു പ്രൊഡക്ഷൻ പതിപ്പിലേക്ക് ഉരുട്ടുന്നത് എങ്ങുമെത്താത്ത വഴിയാണ്. ചിലപ്പോൾ ഇത് പ്രവർത്തിക്കുന്നു, ചിലപ്പോൾ അത് പ്രവർത്തിക്കുന്നില്ല. അതിനാൽ, വിജയം പ്രതീക്ഷിക്കുന്നത് മോശമാണ്.
മാക്സിം കോട്ട്യാക്കോവ്, സീനിയർ ബാക്കെൻഡ് എഞ്ചിനീയർ അവിറ്റോ: വൻകിട കമ്പനികൾക്കുള്ള പ്രശ്‌നങ്ങളുടെ ഒരു പരമ്പരയിൽ നിന്ന് പരീക്ഷണ പരിതസ്ഥിതികളെക്കുറിച്ച് ഞാൻ കുറച്ച് ചേർക്കും. പ്രൊഡക്ഷനിലുള്ളതിന്റെ കൃത്യമായ പകർപ്പ് ഡാറ്റാ സ്‌കീമകളും ക്രമീകരണങ്ങളും സഹിതം ഞങ്ങൾക്ക് ഒരു സമ്പൂർണ്ണ ClickHouse സ്വീകാര്യത ക്ലസ്റ്റർ ഉണ്ട്. ഈ ക്ലസ്റ്റർ ഏറ്റവും കുറഞ്ഞ വിഭവങ്ങൾ ഉള്ള പകരം പഴകിയ പാത്രങ്ങളിലാണ് വിന്യസിച്ചിരിക്കുന്നത്. പ്രൊഡക്ഷൻ ഡാറ്റയുടെ ഒരു നിശ്ചിത ശതമാനം ഞങ്ങൾ അവിടെ എഴുതുന്നു, ഭാഗ്യവശാൽ കാഫ്കയിലെ സ്ട്രീം പകർത്താൻ സാധിക്കും. അവിടെയുള്ള എല്ലാം സമന്വയിപ്പിക്കുകയും സ്കെയിൽ ചെയ്യുകയും ചെയ്യുന്നു - ശക്തിയുടെ കാര്യത്തിലും ഒഴുക്കിന്റെ കാര്യത്തിലും, കൂടാതെ, സിദ്ധാന്തത്തിൽ, മറ്റെല്ലാ കാര്യങ്ങളും തുല്യമായതിനാൽ, അളവുകളുടെ കാര്യത്തിൽ അത് ഉൽപ്പാദനം പോലെ പ്രവർത്തിക്കണം. സ്ഫോടകശേഷിയുള്ള എല്ലാം ആദ്യം ഈ സ്റ്റാൻഡിലേക്ക് ഉരുട്ടി, അത് തയ്യാറാകുന്നതുവരെ ദിവസങ്ങളോളം അവിടെ വയ്ക്കുന്നു. എന്നാൽ സ്വാഭാവികമായും, ഈ പരിഹാരം ചെലവേറിയതും ബുദ്ധിമുട്ടുള്ളതും പൂജ്യമല്ലാത്ത പിന്തുണ ചെലവുകളുള്ളതുമാണ്.
അലക്സി മിലോവിഡോവ്: Yandex.Metrica-ൽ നിന്നുള്ള ഞങ്ങളുടെ സുഹൃത്തുക്കളുടെ പരീക്ഷണ അന്തരീക്ഷം എന്താണെന്ന് ഞാൻ നിങ്ങളോട് പറയും. ഒരു ക്ലസ്റ്ററിന് 600-ഓളം സെർവറുകൾ ഉണ്ടായിരുന്നു, മറ്റൊന്നിന് 360 ഉണ്ടായിരുന്നു, മൂന്നാമത്തേതും നിരവധി ക്ലസ്റ്ററുകളും ഉണ്ട്. അവയിലൊന്നിന്റെ പരീക്ഷണ പരിതസ്ഥിതി രണ്ട് പകർപ്പുകൾ വീതമുള്ള രണ്ട് കഷ്ണങ്ങളാണ്. എന്തുകൊണ്ടാണ് രണ്ട് കഷണങ്ങൾ? അതിനാൽ നിങ്ങൾ തനിച്ചല്ല. ഒപ്പം പകർപ്പുകളും ഉണ്ടായിരിക്കണം. നിങ്ങൾക്ക് താങ്ങാനാകുന്ന ഒരു നിശ്ചിത മിനിമം തുക മാത്രം.
നിങ്ങളുടെ അന്വേഷണങ്ങൾ പ്രവർത്തിക്കുന്നുണ്ടോയെന്നും പ്രധാനപ്പെട്ട എന്തെങ്കിലും തകർന്നിട്ടുണ്ടോയെന്നും പരിശോധിക്കാൻ ഈ ടെസ്റ്റ് എൻവയോൺമെന്റ് നിങ്ങളെ അനുവദിക്കുന്നു. എന്നാൽ പലപ്പോഴും പ്രശ്നങ്ങൾ തികച്ചും വ്യത്യസ്തമായ സ്വഭാവത്തിൽ ഉയർന്നുവരുന്നു, എല്ലാം പ്രവർത്തിക്കുമ്പോൾ, എന്നാൽ ലോഡിനൊപ്പം ചില ചെറിയ മാറ്റങ്ങളുണ്ട്.
ഞാനൊരു ഉദാഹരണം പറയാം. ClickHouse-ന്റെ ഒരു പുതിയ പതിപ്പ് ഇൻസ്റ്റാൾ ചെയ്യാൻ ഞങ്ങൾ തീരുമാനിച്ചു. ഇത് ഒരു ടെസ്റ്റ് എൻവയോൺമെന്റിൽ പോസ്റ്റുചെയ്‌തു, യാൻഡെക്‌സ്.മെട്രിക്കയിൽ തന്നെ ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ പൂർത്തിയായി, ഇത് മുഴുവൻ പൈപ്പ്‌ലൈനിലും പ്രവർത്തിക്കുന്ന പഴയ പതിപ്പിന്റെയും പുതിയതിന്റെയും ഡാറ്റ താരതമ്യം ചെയ്യുന്നു. തീർച്ചയായും, ഞങ്ങളുടെ സിഐയുടെ ഗ്രീൻ ടെസ്റ്റുകൾ. അല്ലെങ്കിൽ ഞങ്ങൾ ഈ പതിപ്പ് നിർദ്ദേശിക്കില്ല.
എല്ലാം നന്നായിട്ടുണ്ട്. ഞങ്ങൾ ഉൽപാദനത്തിലേക്ക് നീങ്ങാൻ തുടങ്ങുന്നു. ഗ്രാഫുകളിലെ ലോഡ് നിരവധി തവണ വർദ്ധിച്ചതായി എനിക്ക് ഒരു സന്ദേശം ലഭിക്കുന്നു. ഞങ്ങൾ പതിപ്പ് പിൻവലിക്കുകയാണ്. ഞാൻ ഗ്രാഫ് നോക്കുകയും കാണുക: റോൾഔട്ട് സമയത്ത് ലോഡ് യഥാർത്ഥത്തിൽ നിരവധി തവണ വർദ്ധിച്ചു, അത് ഉരുട്ടിയപ്പോൾ വീണ്ടും കുറഞ്ഞു. തുടർന്ന് ഞങ്ങൾ പതിപ്പ് തിരികെ കൊണ്ടുവരാൻ തുടങ്ങി. ലോഡ് അതേ രീതിയിൽ വർദ്ധിക്കുകയും അതേ രീതിയിൽ വീണ്ടും വീഴുകയും ചെയ്തു. അതിനാൽ നിഗമനം ഇതാണ്: ലേഔട്ട് കാരണം ലോഡ് വർദ്ധിച്ചു, അതിശയിക്കാനൊന്നുമില്ല.
അപ്പോൾ പുതിയ പതിപ്പ് ഇൻസ്റ്റാൾ ചെയ്യാൻ സഹപ്രവർത്തകരെ ബോധ്യപ്പെടുത്താൻ ബുദ്ധിമുട്ടായിരുന്നു. ഞാൻ പറയുന്നു: “കുഴപ്പമില്ല, ഉരുട്ടുക. നിങ്ങളുടെ വിരലുകൾ ക്രോസ് ചെയ്യുക, എല്ലാം പ്രവർത്തിക്കും. ഇപ്പോൾ ഗ്രാഫുകളിൽ ലോഡ് വർദ്ധിച്ചു, പക്ഷേ എല്ലാം ശരിയാണ്. അവിടെ നിൽക്കൂ." പൊതുവേ, ഞങ്ങൾ ഇത് ചെയ്തു, അത്രമാത്രം - പതിപ്പ് പ്രൊഡക്ഷൻ സൈറ്റിൽ പോസ്റ്റ് ചെയ്തു. എന്നാൽ മിക്കവാറും എല്ലാ ലേഔട്ടിലും സമാനമായ പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നു.
കിൽ ക്വറി ചോദ്യങ്ങളെ കൊല്ലണം, പക്ഷേ അത് അങ്ങനെയല്ല. എന്തുകൊണ്ട്?
ഒരു ഉപയോക്താവ്, ഒരുതരം അനലിസ്റ്റ്, എന്റെ അടുത്ത് വന്ന് എന്റെ ക്ലിക്ക്ഹൗസ് ക്ലസ്റ്റർ ഇട്ട ഒരു അഭ്യർത്ഥന സൃഷ്ടിച്ചു. അഭ്യർത്ഥന ഏത് പകർപ്പിലേക്കോ ഷാർഡിലേക്കോ പോയി എന്നതിനെ ആശ്രയിച്ച് ചില നോഡ് അല്ലെങ്കിൽ മുഴുവൻ ക്ലസ്റ്ററും. ഈ സെർവറിലെ എല്ലാ സിപിയു ഉറവിടങ്ങളും ഒരു ഷെൽഫിൽ ഉണ്ടെന്ന് ഞാൻ കാണുന്നു, എല്ലാം ചുവപ്പാണ്. അതേ സമയം, ക്ലിക്ക്ഹൗസ് തന്നെ അഭ്യർത്ഥനകളോട് പ്രതികരിക്കുന്നു. ഞാൻ എഴുതുന്നു: "ദയവായി എന്നെ കാണിക്കൂ, പ്രോസസ് ലിസ്റ്റ്, എന്ത് അഭ്യർത്ഥനയാണ് ഈ ഭ്രാന്ത് സൃഷ്ടിച്ചത്."
ഞാൻ ഈ അഭ്യർത്ഥന കണ്ടെത്തി അതിന് കൊല്ലുക എന്ന് എഴുതുന്നു. ഒന്നും സംഭവിക്കുന്നില്ലെന്ന് ഞാൻ കാണുന്നു. എന്റെ സെർവർ ഒരു ഷെൽഫിലാണ്, ക്ലിക്ക്ഹൗസ് എനിക്ക് ചില കമാൻഡുകൾ നൽകുന്നു, സെർവർ സജീവമാണെന്ന് കാണിക്കുന്നു, എല്ലാം മികച്ചതാണ്. എന്നാൽ എല്ലാ ഉപയോക്തൃ അഭ്യർത്ഥനകളിലും എനിക്ക് ഡീഗ്രേഡേഷൻ ഉണ്ട്, ക്ലിക്ക്ഹൗസിലെ റെക്കോർഡുകളിൽ ഡീഗ്രേഡേഷൻ ആരംഭിക്കുന്നു, കൂടാതെ എന്റെ കിൽ ക്വറി പ്രവർത്തിക്കുന്നില്ല. എന്തുകൊണ്ട്? കിൽ ക്വറി അന്വേഷണങ്ങളെ നശിപ്പിക്കുമെന്ന് ഞാൻ കരുതി, പക്ഷേ അത് അങ്ങനെയല്ല.
ഇപ്പോൾ ഒരു വിചിത്രമായ ഉത്തരം ഉണ്ടാകും. ചോദ്യം കൊല്ലുന്നത് ചോദ്യങ്ങളെ കൊല്ലുന്നില്ല എന്നതാണ് കാര്യം.
"എനിക്ക് ഈ ചോദ്യം കൊല്ലപ്പെടണം" എന്ന പേരിലുള്ള ഒരു ചെറിയ ബോക്സ് കിൽ ക്വറി പരിശോധിക്കുന്നു. ഓരോ ബ്ലോക്കും പ്രോസസ്സ് ചെയ്യുമ്പോൾ അഭ്യർത്ഥന തന്നെ ഈ ഫ്ലാഗിലേക്ക് നോക്കുന്നു. ഇത് സജ്ജമാക്കിയാൽ, അഭ്യർത്ഥന പ്രവർത്തിക്കുന്നത് നിർത്തുന്നു. ആരും അഭ്യർത്ഥനയെ കൊല്ലുന്നില്ലെന്ന് മാറുന്നു, അവൻ തന്നെ എല്ലാം പരിശോധിച്ച് നിർത്തണം. അഭ്യർത്ഥന ഡാറ്റയുടെ പ്രോസസ്സിംഗ് ബ്ലോക്കുകളിൽ ഉള്ള എല്ലാ സാഹചര്യങ്ങളിലും ഇത് പ്രവർത്തിക്കണം. ഇത് ഡാറ്റയുടെ അടുത്ത ബ്ലോക്ക് പ്രോസസ്സ് ചെയ്യുകയും ഫ്ലാഗ് പരിശോധിക്കുകയും നിർത്തുകയും ചെയ്യും.
ചില പ്രവർത്തനങ്ങളിൽ അഭ്യർത്ഥന തടഞ്ഞ സന്ദർഭങ്ങളിൽ ഇത് പ്രവർത്തിക്കില്ല. ശരിയാണ്, മിക്കവാറും ഇത് നിങ്ങളുടെ കാര്യമല്ല, കാരണം, നിങ്ങളുടെ അഭിപ്രായത്തിൽ, ഇത് ഒരു ടൺ സെർവർ ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്നു. ബാഹ്യ സോർട്ടിംഗിന്റെ കാര്യത്തിലും മറ്റ് ചില വിശദാംശങ്ങളിലും ഇത് പ്രവർത്തിക്കാതിരിക്കാൻ സാധ്യതയുണ്ട്. എന്നാൽ പൊതുവേ ഇത് സംഭവിക്കാൻ പാടില്ല, ഇതൊരു ബഗ് ആണ്. എനിക്ക് ശുപാർശ ചെയ്യാൻ കഴിയുന്ന ഒരേയൊരു കാര്യം ClickHouse അപ്ഡേറ്റ് ചെയ്യുക എന്നതാണ്.
വായനാ ലോഡിന് കീഴിലുള്ള പ്രതികരണ സമയം എങ്ങനെ കണക്കാക്കാം?
ഇനം അനുസരിച്ച് സംഭരിച്ചിരിക്കുന്ന ഒരു പട്ടികയുണ്ട് - വിവിധ കൗണ്ടറുകൾ. വരികളുടെ എണ്ണം ഏകദേശം നൂറ് ദശലക്ഷമാണ്. നിങ്ങൾ 1K ഇനങ്ങളിൽ 1K RPS പകരുകയാണെങ്കിൽ പ്രവചനാതീതമായ പ്രതികരണ സമയം കണക്കാക്കാൻ കഴിയുമോ?
സന്ദർഭം അനുസരിച്ച്, ഞങ്ങൾ വായനാ ലോഡിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നത്, കാരണം എഴുതുന്നതിൽ പ്രശ്നങ്ങളൊന്നുമില്ല - ആയിരം, ഒരു ലക്ഷം പോലും, ചിലപ്പോൾ നിരവധി ദശലക്ഷം വരികൾ തിരുകാൻ കഴിയും.
വായനാ അഭ്യർത്ഥനകൾ വളരെ വ്യത്യസ്തമാണ്. തിരഞ്ഞെടുത്ത 1-ൽ, ClickHouse-ന് സെക്കൻഡിൽ പതിനായിരക്കണക്കിന് അഭ്യർത്ഥനകൾ നടത്താൻ കഴിയും, അതിനാൽ ഒരു കീയ്ക്കുള്ള അഭ്യർത്ഥനകൾക്ക് പോലും ചില ഉറവിടങ്ങൾ ആവശ്യമായി വരും. ചില കീ-മൂല്യം ഡാറ്റാബേസുകളേക്കാൾ അത്തരം പോയിന്റ് അന്വേഷണങ്ങൾ കൂടുതൽ ബുദ്ധിമുട്ടായിരിക്കും, കാരണം ഓരോ വായനയ്ക്കും സൂചിക പ്രകാരം ഡാറ്റയുടെ ഒരു ബ്ലോക്ക് വായിക്കേണ്ടത് ആവശ്യമാണ്. ഞങ്ങളുടെ സൂചിക ഓരോ റെക്കോർഡ് അല്ല, ഓരോ ശ്രേണിയും അഭിസംബോധന ചെയ്യുന്നു. അതായത്, നിങ്ങൾ മുഴുവൻ ശ്രേണിയും വായിക്കേണ്ടിവരും - ഇത് സ്ഥിരസ്ഥിതിയായി 8192 വരികളാണ്. 64 കെബിയിൽ നിന്ന് 1 എംബിയിലേക്ക് കംപ്രസ് ചെയ്ത ഡാറ്റ ബ്ലോക്ക് നിങ്ങൾ ഡീകംപ്രസ് ചെയ്യണം. സാധാരണഗതിയിൽ, അത്തരം പോയിന്റ് അഭ്യർത്ഥനകൾക്ക് കുറച്ച് മില്ലിസെക്കൻഡ് എടുക്കും. എന്നാൽ ഇത് ഏറ്റവും ലളിതമായ ഓപ്ഷനാണ്.
നമുക്ക് ചില ലളിതമായ ഗണിതങ്ങൾ പരീക്ഷിക്കാം. നിങ്ങൾ കുറച്ച് മില്ലിസെക്കൻഡുകളെ ആയിരം കൊണ്ട് ഗുണിച്ചാൽ, നിങ്ങൾക്ക് കുറച്ച് സെക്കൻഡ് ലഭിക്കും. സെക്കൻഡിൽ ആയിരം അഭ്യർത്ഥനകൾ സൂക്ഷിക്കുന്നത് അസാധ്യമാണ്, പക്ഷേ വാസ്തവത്തിൽ ഇത് സാധ്യമാണ്, കാരണം ഞങ്ങൾക്ക് നിരവധി പ്രോസസർ കോറുകൾ ഉണ്ട്. അതിനാൽ, തത്വത്തിൽ, ClickHouse ചിലപ്പോൾ 1000 RPS കൈവശം വയ്ക്കാം, എന്നാൽ ഹ്രസ്വ അഭ്യർത്ഥനകൾക്ക്, പ്രത്യേകമായി ടാർഗെറ്റുചെയ്‌തവ.
ലളിതമായ അഭ്യർത്ഥനകളുടെ എണ്ണം അനുസരിച്ച് നിങ്ങൾക്ക് ഒരു ClickHouse ക്ലസ്റ്റർ സ്കെയിൽ ചെയ്യണമെങ്കിൽ, ഏറ്റവും ലളിതമായ കാര്യം ഞാൻ ശുപാർശ ചെയ്യുന്നു - പകർപ്പുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുകയും ക്രമരഹിതമായ ഒരു പകർപ്പിലേക്ക് അഭ്യർത്ഥനകൾ അയയ്ക്കുകയും ചെയ്യുക. ഒരു പകർപ്പ് സെക്കൻഡിൽ അഞ്ഞൂറ് അഭ്യർത്ഥനകൾ കൈവശം വച്ചാൽ, അത് തികച്ചും യാഥാർത്ഥ്യമാണ്, മൂന്ന് പകർപ്പുകൾ ഒന്നര ആയിരം ഉൾക്കൊള്ളും.
ചിലപ്പോൾ, തീർച്ചയായും, നിങ്ങൾക്ക് പരമാവധി പോയിന്റ് റീഡിംഗുകൾക്കായി ClickHouse കോൺഫിഗർ ചെയ്യാം. ഇതിന് എന്താണ് വേണ്ടത്? ആദ്യത്തേത് സൂചികയുടെ ഗ്രാനുലാരിറ്റി കുറയ്ക്കുക എന്നതാണ്. ഈ സാഹചര്യത്തിൽ, ഇത് ഒന്നായി കുറയ്ക്കരുത്, പക്ഷേ സൂചികയിലെ റെക്കോർഡുകളുടെ എണ്ണം ഒരു സെർവറിന് നിരവധി ദശലക്ഷമോ ദശലക്ഷമോ ആകുമെന്ന കണക്കുകൂട്ടലിന്റെ അടിസ്ഥാനത്തിൽ. ഒരു പട്ടികയിൽ നൂറ് ദശലക്ഷം വരികൾ ഉണ്ടെങ്കിൽ, ഗ്രാനുലാരിറ്റി 64 ആയി സജ്ജീകരിക്കാം.
നിങ്ങൾക്ക് കംപ്രസ് ചെയ്ത ബ്ലോക്കിന്റെ വലുപ്പം കുറയ്ക്കാൻ കഴിയും. ഇതിനുള്ള ക്രമീകരണങ്ങളുണ്ട് മിനിറ്റ് കംപ്രസ് ബ്ലോക്ക് വലിപ്പം, പരമാവധി കംപ്രസ് ബ്ലോക്ക് വലിപ്പം. അവ കുറയ്ക്കാനും ഡാറ്റ ഉപയോഗിച്ച് വീണ്ടും പൂരിപ്പിക്കാനും കഴിയും, തുടർന്ന് ടാർഗെറ്റുചെയ്‌ത അന്വേഷണങ്ങൾ വേഗത്തിലാകും. എന്നിട്ടും, ClickHouse ഒരു പ്രധാന മൂല്യ ഡാറ്റാബേസ് അല്ല. ധാരാളം ചെറിയ അഭ്യർത്ഥനകൾ ഒരു ലോഡ് ആന്റിപാറ്റേൺ ആണ്.
കിറിൽ ഷ്വാക്കോവ്: അവിടെ സാധാരണ അക്കൗണ്ടുകൾ ഉണ്ടെങ്കിൽ ഞാൻ ഉപദേശം നൽകും. ClickHouse-ൽ ഏതെങ്കിലും തരത്തിലുള്ള കൗണ്ടർ സംഭരിച്ചിരിക്കുമ്പോൾ ഇത് തികച്ചും സ്റ്റാൻഡേർഡ് സാഹചര്യമാണ്. എനിക്ക് ഒരു ഉപയോക്താവുണ്ട്, അവൻ അത്തരമൊരു രാജ്യത്ത് നിന്നുള്ളയാളാണ്, ഏതോ മൂന്നാം ഫീൽഡ്, എനിക്ക് വർധിച്ചുവരുന്ന എന്തെങ്കിലും വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്. MySQL എടുക്കുക, ഒരു അദ്വിതീയ കീ ഉണ്ടാക്കുക - MySQL-ൽ ഇതൊരു ഡ്യൂപ്ലിക്കേറ്റ് കീയാണ്, PostgreSQL-ൽ ഇതൊരു വൈരുദ്ധ്യമാണ് - കൂടാതെ ഒരു പ്ലസ് ചിഹ്നം ചേർക്കുക. ഇത് കൂടുതൽ നന്നായി പ്രവർത്തിക്കും.
നിങ്ങൾക്ക് കൂടുതൽ ഡാറ്റ ഇല്ലെങ്കിൽ, ClickHouse ഉപയോഗിക്കുന്നതിൽ കാര്യമില്ല. പതിവ് ഡാറ്റാബേസുകൾ ഉണ്ട്, അവർ ഇത് നന്നായി ചെയ്യുന്നു.
കൂടുതൽ ഡാറ്റ കാഷെയിലാകാൻ എനിക്ക് ക്ലിക്ക്ഹൗസിൽ എന്തൊക്കെ മാറ്റങ്ങൾ വരുത്താനാകും?
നമുക്ക് ഒരു സാഹചര്യം സങ്കൽപ്പിക്കാം - സെർവറുകൾക്ക് 256 GB റാം ഉണ്ട്, ദിനചര്യയിൽ ClickHouse ഏകദേശം 60-80 GB എടുക്കും, ഏറ്റവും ഉയർന്ന സമയത്ത് - 130 വരെ. കൂടുതൽ ഡാറ്റ കാഷെയിലാകുന്ന തരത്തിൽ എന്തൊക്കെ പ്രവർത്തനക്ഷമമാക്കാനും ട്വീക്ക് ചെയ്യാനും കഴിയും. ഡിസ്കിലേക്കുള്ള യാത്രകൾ കുറവാണോ?
സാധാരണഗതിയിൽ, ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ പേജ് കാഷെ ഈ ടാസ്ക്കിന്റെ നല്ല ജോലി ചെയ്യുന്നു. നിങ്ങൾ മുകളിലെ പേജ് തുറന്നാൽ, അവിടെ കാഷെ ചെയ്‌തോ ഫ്രീയോ നോക്കുക - എത്ര കാഷെ ചെയ്‌തിരിക്കുന്നുവെന്നും അതിൽ പറയുന്നുണ്ട് - അപ്പോൾ എല്ലാ സൗജന്യ മെമ്മറിയും കാഷെയ്‌ക്കായി ഉപയോഗിക്കുന്നത് നിങ്ങൾ ശ്രദ്ധിക്കും. ഈ ഡാറ്റ, വായിക്കുമ്പോൾ, ഡിസ്കിൽ നിന്നല്ല, റാമിൽ നിന്നാണ് വായിക്കുന്നത്. അതേ സമയം, കാഷെയിൽ കംപ്രസ് ചെയ്ത ഡാറ്റയാണ് കാഷെ ഫലപ്രദമായി ഉപയോഗിക്കുന്നത് എന്ന് എനിക്ക് പറയാൻ കഴിയും.
എന്നിരുന്നാലും, ചില ലളിതമായ അന്വേഷണങ്ങൾ കൂടുതൽ വേഗത്തിലാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഡീകംപ്രസ്സ് ചെയ്ത ഡാറ്റയിൽ ClickHouse-നുള്ളിൽ ഒരു കാഷെ പ്രവർത്തനക്ഷമമാക്കാനുള്ള ഒരു ഓപ്ഷൻ ഉണ്ട്. ഇത് വിളിക്കപ്പെടുന്നത് കംപ്രസ് ചെയ്യാത്ത കാഷെ. config.xml കോൺഫിഗറേഷൻ ഫയലിൽ, നിങ്ങൾക്ക് ആവശ്യമുള്ള മൂല്യത്തിലേക്ക് കംപ്രസ് ചെയ്യാത്ത കാഷെ വലുപ്പം സജ്ജമാക്കുക - സൗജന്യ റാമിന്റെ പകുതിയിൽ കൂടുതൽ നൽകരുതെന്ന് ഞാൻ ശുപാർശ ചെയ്യുന്നു, കാരണം ബാക്കിയുള്ളവ പേജ് കാഷെയ്ക്ക് കീഴിലായിരിക്കും.
കൂടാതെ, രണ്ട് അഭ്യർത്ഥന ലെവൽ ക്രമീകരണങ്ങൾ ഉണ്ട്. ആദ്യ ക്രമീകരണം - കംപ്രസ് ചെയ്യാത്ത കാഷെ ഉപയോഗിക്കുക - അതിന്റെ ഉപയോഗം ഉൾപ്പെടുന്നു. എല്ലാ ഡാറ്റയും വായിക്കാനും കാഷെ ഫ്ലഷ് ചെയ്യാനും കഴിയുന്ന കനത്തവ ഒഴികെയുള്ള എല്ലാ അഭ്യർത്ഥനകൾക്കും ഇത് പ്രവർത്തനക്ഷമമാക്കാൻ ശുപാർശ ചെയ്യുന്നു. കാഷെ ഉപയോഗത്തിനുള്ള പരമാവധി വരികളുടെ എണ്ണം പോലെയാണ് രണ്ടാമത്തെ ക്രമീകരണം. വലിയ ചോദ്യങ്ങളെ ഇത് യാന്ത്രികമായി പരിമിതപ്പെടുത്തുന്നു, അങ്ങനെ അവ കാഷെ മറികടക്കുന്നു.
റാമിൽ സംഭരണത്തിനായി സ്റ്റോറേജ്_കോൺഫിഗറേഷൻ എങ്ങനെ ക്രമീകരിക്കാം?
പുതിയ ClickHouse ഡോക്യുമെന്റേഷനിൽ ഞാൻ ബന്ധപ്പെട്ട വിഭാഗം വായിച്ചു . വിവരണത്തിൽ വേഗതയേറിയ SSD ഉള്ള ഒരു ഉദാഹരണം അടങ്ങിയിരിക്കുന്നു.
വോളിയം ഹോട്ട് മെമ്മറി ഉപയോഗിച്ച് ഇത് എങ്ങനെ ക്രമീകരിക്കാമെന്ന് ഞാൻ അത്ഭുതപ്പെടുന്നു. ഒപ്പം ഒരു ചോദ്യം കൂടി. ഈ ഡാറ്റാ ഓർഗനൈസേഷനുമായി തിരഞ്ഞെടുത്തത് എങ്ങനെ പ്രവർത്തിക്കും, അത് മുഴുവൻ സെറ്റും അല്ലെങ്കിൽ ഡിസ്കിലുള്ളത് മാത്രം വായിക്കുമോ, കൂടാതെ ഈ ഡാറ്റ മെമ്മറിയിൽ കംപ്രസ് ചെയ്തിട്ടുണ്ടോ? അത്തരം ഒരു ഡാറ്റാ ഓർഗനൈസേഷനുമായി പ്രിവെർ വിഭാഗം എങ്ങനെ പ്രവർത്തിക്കും?
ഈ ക്രമീകരണം ഡാറ്റാ ചങ്കുകളുടെ സംഭരണത്തെ ബാധിക്കുന്നു, അവയുടെ ഫോർമാറ്റ് ഒരു തരത്തിലും മാറില്ല.
നമുക്ക് സൂക്ഷ്മമായി നോക്കാം.
നിങ്ങൾക്ക് റാമിൽ ഡാറ്റ സംഭരണം ക്രമീകരിക്കാം. ഒരു ഡിസ്കിനായി ക്രമീകരിച്ചിരിക്കുന്നതെല്ലാം അതിന്റെ പാതയാണ്. നിങ്ങൾ ഒരു tmpfs പാർട്ടീഷൻ ഉണ്ടാക്കുന്നു, അത് ഫയൽ സിസ്റ്റത്തിലെ ഏതെങ്കിലും പാതയിലേക്ക് മൌണ്ട് ചെയ്തിരിക്കുന്നു. ഏറ്റവും ചൂടേറിയ പാർട്ടീഷനുള്ള ഡാറ്റ സംഭരിക്കുന്നതിനുള്ള പാതയായി നിങ്ങൾ ഈ പാത വ്യക്തമാക്കുന്നു, ഡാറ്റയുടെ കഷണങ്ങൾ എത്തി അവിടെ എഴുതാൻ തുടങ്ങുന്നു, എല്ലാം ശരിയാണ്.
കുറഞ്ഞ വിശ്വാസ്യത കാരണം ഇത് ചെയ്യാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നില്ല, എന്നിരുന്നാലും നിങ്ങൾക്ക് വ്യത്യസ്ത ഡാറ്റാ സെന്ററുകളിൽ കുറഞ്ഞത് മൂന്ന് പകർപ്പുകളെങ്കിലും ഉണ്ടെങ്കിൽ, അത് സാധ്യമാണ്. എന്തെങ്കിലും സംഭവിച്ചാൽ, ഡാറ്റ പുനഃസ്ഥാപിക്കും. സെർവർ പെട്ടെന്ന് ഓഫാക്കി വീണ്ടും ഓണാക്കിയതായി സങ്കൽപ്പിക്കുക. പാർട്ടീഷൻ വീണ്ടും മൌണ്ട് ചെയ്തു, പക്ഷേ അവിടെ ഒന്നുമില്ല. ClickHouse സെർവർ ആരംഭിക്കുമ്പോൾ, അതിൽ ഈ ഭാഗങ്ങൾ ഇല്ലെന്ന് അത് കാണുന്നു, എന്നിരുന്നാലും, ZooKeeper മെറ്റാഡാറ്റ അനുസരിച്ച്, അവ അവിടെ ഉണ്ടായിരിക്കണം. ഏതൊക്കെ പകർപ്പുകളാണ് ഉള്ളതെന്ന് അവൻ നോക്കുകയും അവ ആവശ്യപ്പെടുകയും ഡൗൺലോഡ് ചെയ്യുകയും ചെയ്യുന്നു. ഈ രീതിയിൽ ഡാറ്റ പുനഃസ്ഥാപിക്കപ്പെടും.
ഈ അർത്ഥത്തിൽ, RAM-ൽ ഡാറ്റ സംഭരിക്കുന്നത് അത് ഡിസ്കിൽ സംഭരിക്കുന്നതിൽ നിന്ന് അടിസ്ഥാനപരമായി വ്യത്യസ്തമല്ല, കാരണം ഡാറ്റ ഡിസ്കിലേക്ക് എഴുതുമ്പോൾ, അത് ആദ്യം പേജ് കാഷെയിൽ അവസാനിക്കുകയും പിന്നീട് ഭൗതികമായി എഴുതുകയും ചെയ്യുന്നു. ഇത് ഫയൽ സിസ്റ്റം മൌണ്ട് ഓപ്ഷനെ ആശ്രയിച്ചിരിക്കുന്നു. പക്ഷേ, ഇൻസേർട്ട് ചെയ്യുമ്പോൾ ClickHouse fsync ചെയ്യില്ലെന്ന് ഞാൻ പറയാം.
ഈ സാഹചര്യത്തിൽ, റാമിലെ ഡാറ്റ ഡിസ്കിലെ അതേ ഫോർമാറ്റിൽ സംഭരിച്ചിരിക്കുന്നു. സെലക്ട് ക്വറി അതേ രീതിയിൽ വായിക്കേണ്ട കഷണങ്ങൾ തിരഞ്ഞെടുത്ത്, കഷണങ്ങളിൽ ആവശ്യമായ ഡാറ്റ ശ്രേണികൾ തിരഞ്ഞെടുത്ത് അവ വായിക്കുന്നു. ഡാറ്റ റാമിലോ ഡിസ്കിലോ ആയിരുന്നാലും, പ്രിവെർ ഒരേപോലെ പ്രവർത്തിക്കുന്നു.
ലോ കാർഡിനാലിറ്റി എത്രത്തോളം അദ്വിതീയ മൂല്യങ്ങൾ വരെ ഫലപ്രദമാണ്?
ലോ കാർഡിനാലിറ്റി സമർത്ഥമായി രൂപകൽപ്പന ചെയ്തതാണ്. ഇത് ഡാറ്റ നിഘണ്ടുക്കൾ സമാഹരിക്കുന്നു, പക്ഷേ അവ പ്രാദേശികമാണ്. ഒന്നാമതായി, ഓരോ ഭാഗത്തിനും വ്യത്യസ്ത നിഘണ്ടുകളുണ്ട്, രണ്ടാമതായി, ഒരു കഷണത്തിനുള്ളിൽ പോലും അവ ഓരോ ശ്രേണിയിലും വ്യത്യസ്തമായിരിക്കും. അദ്വിതീയ മൂല്യങ്ങളുടെ എണ്ണം ഒരു പരിധിയിലെത്തുമ്പോൾ - ഒരു ദശലക്ഷത്തിൽ, ഞാൻ കരുതുന്നു - നിഘണ്ടു വെറുതെ വിടുകയും പുതിയൊരെണ്ണം സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.
ഉത്തരം പൊതുവായതാണ്: ഓരോ പ്രാദേശിക ശ്രേണിക്കും - പറയുക, ഓരോ ദിവസവും - ഒരു ദശലക്ഷം അദ്വിതീയ മൂല്യങ്ങൾ വരെ, ലോ കാർഡിനാലിറ്റി ഫലപ്രദമാണ്. പിന്നീട് ഒരു ഫാൾബാക്ക് ഉണ്ടാകും, അതിൽ ഒന്നല്ല, വ്യത്യസ്ത നിഘണ്ടുക്കൾ ഉപയോഗിക്കും. ഇത് ഒരു സാധാരണ സ്ട്രിംഗ് കോളം പോലെ തന്നെ പ്രവർത്തിക്കും, ഒരുപക്ഷേ കുറച്ച് കാര്യക്ഷമത കുറവായിരിക്കാം, പക്ഷേ കാര്യമായ പ്രകടന ശോഷണം ഉണ്ടാകില്ല.
അഞ്ച് ബില്യൺ വരികളുള്ള ഒരു ടേബിൾ ഫുൾ-ടെക്സ്റ്റ് തിരയുന്നതിനുള്ള മികച്ച സമ്പ്രദായങ്ങൾ ഏതാണ്?
വ്യത്യസ്ത ഉത്തരങ്ങളുണ്ട്. ക്ലിക്ക്ഹൗസ് ഒരു ഫുൾ-ടെക്സ്റ്റ് സെർച്ച് എഞ്ചിൻ അല്ലെന്നാണ് ആദ്യത്തേത്. ഇതിനായി പ്രത്യേക സംവിധാനങ്ങളുണ്ട്, ഉദാഹരണത്തിന്, и . എന്നിരുന്നാലും, ഇലാസ്റ്റിക് സെർച്ചിൽ നിന്ന് ക്ലിക്ക്ഹൗസിലേക്ക് മാറുകയാണെന്ന് പറയുന്ന ആളുകൾ ഞാൻ കൂടുതലായി കാണുന്നു.
എന്തുകൊണ്ടാണ് ഇത് സംഭവിക്കുന്നത്? സൂചികകളുടെ നിർമ്മാണം മുതൽ ചില വോള്യങ്ങളിലെ ലോഡിനെ നേരിടാൻ ഇലാസ്റ്റിക് സെർച്ച് അവസാനിക്കുന്നു എന്ന വസ്തുതയിലൂടെ അവർ ഇത് വിശദീകരിക്കുന്നു. സൂചികകൾ വളരെ ബുദ്ധിമുട്ടുള്ളതായിത്തീരുന്നു, കൂടാതെ നിങ്ങൾ ക്ലിക്ക്ഹൗസിലേക്ക് ഡാറ്റ കൈമാറുകയാണെങ്കിൽ, വോളിയത്തിന്റെ കാര്യത്തിൽ ഇത് നിരവധി തവണ കൂടുതൽ കാര്യക്ഷമമായി സംഭരിച്ചതായി മാറുന്നു. അതേ സമയം, തിരയൽ അന്വേഷണങ്ങൾ പലപ്പോഴും അത്തരത്തിലുള്ളതായിരുന്നില്ല, മൊർഫോളജി കണക്കിലെടുത്ത് ഡാറ്റയുടെ മുഴുവൻ വോള്യത്തിലും ചില വാക്യങ്ങൾ കണ്ടെത്തേണ്ടത് ആവശ്യമാണ്, പക്ഷേ തികച്ചും വ്യത്യസ്തമായവ. ഉദാഹരണത്തിന്, കഴിഞ്ഞ കുറച്ച് മണിക്കൂറുകളായി ലോഗുകളിൽ ബൈറ്റുകളുടെ ചില തുടർച്ചകൾ കണ്ടെത്തുക.
ഈ സാഹചര്യത്തിൽ, നിങ്ങൾ ClickHouse-ൽ ഒരു സൂചിക സൃഷ്ടിക്കുന്നു, അതിൽ ഒരു തീയതിയും സമയവും ആയിരിക്കും. ഏറ്റവും വലിയ ഡാറ്റ കട്ട് ഓഫ് തീയതി ശ്രേണിയെ അടിസ്ഥാനമാക്കിയുള്ളതായിരിക്കും. തിരഞ്ഞെടുത്ത തീയതി പരിധിക്കുള്ളിൽ, ഒരു ചട്ടം പോലെ, ലൈക്ക് ഉപയോഗിച്ച് ബ്രൂട്ട് ഫോഴ്‌സ് രീതി ഉപയോഗിച്ച് പോലും ഒരു പൂർണ്ണ-വാചക തിരയൽ നടത്താൻ ഇതിനകം സാധ്യമാണ്. ക്ലിക്ക്ഹൗസിലെ ലൈക്ക് ഓപ്പറേറ്റർ നിങ്ങൾക്ക് കണ്ടെത്താനാകുന്ന ഏറ്റവും കാര്യക്ഷമമായ ഓപ്പറേറ്ററാണ്. നിങ്ങൾക്ക് എന്തെങ്കിലും മികച്ചതായി കണ്ടെത്തിയാൽ, എന്നോട് പറയുക.
എന്നിട്ടും, ഒരു പൂർണ്ണ സ്കാൻ പോലെയാണ്. കൂടാതെ പൂർണ്ണ സ്കാൻ സിപിയുവിൽ മാത്രമല്ല, ഡിസ്കിലും മന്ദഗതിയിലാകും. പെട്ടെന്ന് നിങ്ങൾക്ക് പ്രതിദിനം ഒരു ടെറാബൈറ്റ് ഡാറ്റ ഉണ്ടെങ്കിൽ, നിങ്ങൾ പകൽ സമയത്ത് ഒരു വാക്ക് തിരയുകയാണെങ്കിൽ, നിങ്ങൾ ടെറാബൈറ്റ് സ്കാൻ ചെയ്യേണ്ടിവരും. ഇത് സാധാരണ ഹാർഡ് ഡ്രൈവുകളിലായിരിക്കാം, അവസാനം SSH വഴി നിങ്ങൾക്ക് ഈ സെർവർ ആക്സസ് ചെയ്യാൻ കഴിയാത്ത വിധത്തിൽ അവ ലോഡ് ചെയ്യപ്പെടും.
ഈ സാഹചര്യത്തിൽ, ഒരു ചെറിയ ട്രിക്ക് കൂടി വാഗ്ദാനം ചെയ്യാൻ ഞാൻ തയ്യാറാണ്. ഇത് പരീക്ഷണാത്മകമാണ് - ഇത് പ്രവർത്തിച്ചേക്കാം, ഇല്ലായിരിക്കാം. ClickHouse-ന് ട്രിഗ്രാം ബ്ലൂം ഫിൽട്ടറുകളുടെ രൂപത്തിൽ പൂർണ്ണ-വാചക സൂചികകൾ ഉണ്ട്. അരീനഡാറ്റയിലെ ഞങ്ങളുടെ സഹപ്രവർത്തകർ ഈ സൂചികകൾ ഇതിനകം പരീക്ഷിച്ചു, അവ പലപ്പോഴും ഉദ്ദേശിച്ചതുപോലെ പ്രവർത്തിക്കുന്നു.
അവ ശരിയായി ഉപയോഗിക്കുന്നതിന്, അവ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് നല്ല ധാരണ ഉണ്ടായിരിക്കണം: എന്താണ് ട്രിഗ്രാം ബ്ലൂം ഫിൽട്ടർ, അതിന്റെ വലുപ്പം എങ്ങനെ തിരഞ്ഞെടുക്കാം. ഡാറ്റയിൽ അപൂർവ്വമായി കാണപ്പെടുന്ന ചില അപൂർവ പദസമുച്ചയങ്ങളെക്കുറിച്ചുള്ള ചോദ്യങ്ങൾക്ക് അവ സഹായിക്കുമെന്ന് എനിക്ക് പറയാൻ കഴിയും. ഈ സാഹചര്യത്തിൽ, ഉപവിഭാഗങ്ങൾ സൂചികകൾ വഴി തിരഞ്ഞെടുക്കുകയും കുറച്ച് ഡാറ്റ വായിക്കുകയും ചെയ്യും.
ഈയിടെ, ഫുൾ-ടെക്സ്റ്റ് തിരയലിനായി ClickHouse കൂടുതൽ വിപുലമായ സവിശേഷതകൾ ചേർത്തു. ഇത് ഒന്നാമതായി, UTF-8-നുള്ള പിന്തുണയോടെ അല്ലെങ്കിൽ ASCII-ന് മാത്രമുള്ള, കേസ്-സെൻസിറ്റീവ്, കേസ്-ഇൻസെൻസിറ്റീവ് ഓപ്ഷനുകൾ ഉൾപ്പെടെ, ഒരു പാസിൽ ഒരേസമയം ഒരു കൂട്ടം സബ്സ്ട്രിംഗുകൾക്കായുള്ള തിരയലാണ്. നിങ്ങൾക്ക് ആവശ്യമുള്ള ഏറ്റവും ഫലപ്രദമായ ഒന്ന് തിരഞ്ഞെടുക്കുക.
ഒരു പാസിൽ ഒന്നിലധികം റെഗുലർ എക്‌സ്‌പ്രഷനുകൾക്കായുള്ള തിരയലും പ്രത്യക്ഷപ്പെട്ടു. ഒരു സബ്‌സ്‌ട്രിംഗ് പോലെ X എന്നോ മറ്റൊരു സബ്‌സ്‌ട്രിംഗ് പോലെ X എന്നോ എഴുതേണ്ടതില്ല. നിങ്ങൾ ഉടൻ എഴുതുക, എല്ലാം കഴിയുന്നത്ര കാര്യക്ഷമമായി ചെയ്തു.
മൂന്നാമതായി, ഇപ്പോൾ regexps-നുള്ള ഏകദേശ തിരയലും സബ്സ്ട്രിംഗുകൾക്കായുള്ള ഏകദേശ തിരയലുമുണ്ട്. ആരെങ്കിലും ഒരു വാക്ക് തെറ്റായി എഴുതിയാൽ, അത് പരമാവധി പൊരുത്തത്തിനായി തിരയും.
ധാരാളം ഉപയോക്താക്കൾക്കായി ClickHouse-ലേക്ക് ആക്സസ് സംഘടിപ്പിക്കുന്നതിനുള്ള ഏറ്റവും നല്ല മാർഗം ഏതാണ്?
ധാരാളം ഉപഭോക്താക്കൾക്കും വിശകലന വിദഗ്ധർക്കും ആക്സസ് എങ്ങനെ മികച്ച രീതിയിൽ സംഘടിപ്പിക്കാമെന്ന് ഞങ്ങളോട് പറയുക. എങ്ങനെ ഒരു ക്യൂ രൂപീകരിക്കാം, പരമാവധി കൺകറന്റ് അന്വേഷണങ്ങൾക്ക് മുൻഗണന നൽകാം, ഏതൊക്കെ ടൂളുകൾ ഉപയോഗിച്ച്?
ക്ലസ്റ്റർ ആവശ്യത്തിന് വലുതാണെങ്കിൽ, രണ്ട് സെർവറുകൾ കൂടി ഉയർത്തുക എന്നതാണ് ഒരു നല്ല പരിഹാരം, അത് വിശകലന വിദഗ്ധർക്ക് ഒരു എൻട്രി പോയിന്റായി മാറും. അതായത്, ക്ലസ്റ്ററിലെ നിർദ്ദിഷ്ട ശകലങ്ങൾ ആക്സസ് ചെയ്യാൻ അനലിസ്റ്റുകളെ അനുവദിക്കരുത്, പക്ഷേ ഡാറ്റയില്ലാതെ രണ്ട് ശൂന്യമായ സെർവറുകൾ സൃഷ്ടിക്കുകയും അവയിൽ ആക്സസ് അവകാശങ്ങൾ ക്രമീകരിക്കുകയും ചെയ്യുക. ഈ സാഹചര്യത്തിൽ, വിതരണം ചെയ്ത അഭ്യർത്ഥനകൾക്കായുള്ള ഉപയോക്തൃ ക്രമീകരണങ്ങൾ റിമോട്ട് സെർവറുകളിലേക്ക് മാറ്റുന്നു. അതായത്, ഈ രണ്ട് സെർവറുകളിലും നിങ്ങൾ എല്ലാം കോൺഫിഗർ ചെയ്യുന്നു, കൂടാതെ ക്രമീകരണങ്ങൾ മുഴുവൻ ക്ലസ്റ്ററിലും സ്വാധീനം ചെലുത്തുന്നു.
തത്വത്തിൽ, ഈ സെർവറുകൾക്ക് ഡാറ്റയില്ല, എന്നാൽ അഭ്യർത്ഥനകൾ നടപ്പിലാക്കുന്നതിന് അവയിലെ റാമിന്റെ അളവ് വളരെ പ്രധാനമാണ്. ബാഹ്യ അഗ്രഗേഷനോ ബാഹ്യ സോർട്ടിംഗോ പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ടെങ്കിൽ താൽക്കാലിക ഡാറ്റയ്ക്കും ഡിസ്ക് ഉപയോഗിക്കാനാകും.
സാധ്യമായ എല്ലാ പരിധികളുമായും ബന്ധപ്പെട്ടിരിക്കുന്ന ക്രമീകരണങ്ങൾ നോക്കേണ്ടത് പ്രധാനമാണ്. ഞാൻ ഇപ്പോൾ ഒരു അനലിസ്റ്റായി Yandex.Metrica ക്ലസ്റ്ററിൽ പോയി ഒരു അഭ്യർത്ഥന ചോദിക്കുകയാണെങ്കിൽ ഹിറ്റുകളിൽ നിന്ന് എണ്ണം തിരഞ്ഞെടുക്കുക, അപ്പോൾ എനിക്ക് അഭ്യർത്ഥന നടപ്പിലാക്കാൻ കഴിയില്ലെന്ന ഒരു ഒഴിവാക്കൽ ഉടൻ നൽകും. എനിക്ക് സ്കാൻ ചെയ്യാൻ അനുവദിച്ചിരിക്കുന്ന പരമാവധി വരികളുടെ എണ്ണം നൂറ് ബില്യൺ ആണ്, മൊത്തത്തിൽ അവയിൽ അമ്പത് ട്രില്യൺ ക്ലസ്റ്ററിലുള്ള ഒരു ടേബിളിൽ ഉണ്ട്. ഇതാണ് ആദ്യത്തെ പരിമിതി.
ഞാൻ വരികളുടെ എണ്ണത്തിലെ പരിധി നീക്കം ചെയ്ത് ചോദ്യം വീണ്ടും പ്രവർത്തിപ്പിക്കുകയാണെന്ന് പറയാം. അപ്പോൾ ഞാൻ ഇനിപ്പറയുന്ന ഒഴിവാക്കൽ കാണും - ക്രമീകരണം പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു തീയതി പ്രകാരം നിർബന്ധിത സൂചിക. ഞാൻ ഒരു തീയതി ശ്രേണി വ്യക്തമാക്കിയിട്ടില്ലെങ്കിൽ എനിക്ക് ചോദ്യം പൂർത്തിയാക്കാൻ കഴിയില്ല. ഇത് സ്വമേധയാ വ്യക്തമാക്കുന്നതിന് നിങ്ങൾ അനലിസ്റ്റുകളെ ആശ്രയിക്കേണ്ടതില്ല. ആഴ്‌ചയ്‌ക്കിടയിലുള്ള ഇവന്റ് തീയതി എഴുതിയ തീയതി ശ്രേണിയാണ് ഒരു സാധാരണ കേസ്. തുടർന്ന് അവർ തെറ്റായ സ്ഥലത്ത് ഒരു ബ്രാക്കറ്റ് നിർവചിച്ചു, പകരം അത് അല്ലെങ്കിൽ - അല്ലെങ്കിൽ URL പൊരുത്തമായി മാറി. പരിധി ഇല്ലെങ്കിൽ, അത് URL കോളം ക്രോൾ ചെയ്യുകയും ഒരു ടൺ വിഭവങ്ങൾ പാഴാക്കുകയും ചെയ്യും.
കൂടാതെ, ClickHouse-ന് രണ്ട് മുൻഗണനാ ക്രമീകരണങ്ങളുണ്ട്. നിർഭാഗ്യവശാൽ, അവ വളരെ പ്രാകൃതമാണ്. ഒന്ന് ലളിതമായി വിളിക്കപ്പെടുന്നു മുൻഗണന. മുൻഗണന ≠ 0, കൂടാതെ ചില മുൻ‌ഗണനകളുള്ള അഭ്യർത്ഥനകൾ എക്സിക്യൂട്ട് ചെയ്യുകയാണെങ്കിൽ, അതേ സമയം ഒരു അഭ്യർത്ഥന നടപ്പിലാക്കുന്നത് ഒരു മുൻഗണന മൂല്യം കുറവായ മൂല്യമുള്ളതാണ്, അതായത് ഉയർന്ന മുൻഗണന എന്നർത്ഥം, തുടർന്ന് മുൻഗണന മൂല്യം കൂടുതലുള്ള ഒരു അഭ്യർത്ഥന, ഇത് കുറഞ്ഞ മുൻഗണന എന്നർത്ഥം, താൽക്കാലികമായി നിർത്തിവച്ചിരിക്കുന്നു, ഈ സമയത്ത് പ്രവർത്തിക്കില്ല.
ഇത് വളരെ അസംസ്കൃത ക്രമീകരണമാണ്, ക്ലസ്റ്ററിന് സ്ഥിരമായ ലോഡ് ഉള്ള സന്ദർഭങ്ങളിൽ ഇത് അനുയോജ്യമല്ല. എന്നാൽ നിങ്ങൾക്ക് ചെറുതും പൊട്ടിത്തെറിക്കുന്നതുമായ അഭ്യർത്ഥനകൾ പ്രധാനമാണ്, കൂടാതെ ക്ലസ്റ്റർ മിക്കവാറും നിഷ്‌ക്രിയമാണെങ്കിൽ, ഈ സജ്ജീകരണം അനുയോജ്യമാണ്.
അടുത്ത മുൻഗണനാ ക്രമീകരണം വിളിക്കുന്നു OS ത്രെഡ് മുൻഗണന. ലിനക്സ് ഷെഡ്യൂളറിനായുള്ള എല്ലാ അഭ്യർത്ഥന എക്സിക്യൂഷൻ ത്രെഡുകൾക്കും ഇത് നല്ല മൂല്യം സജ്ജമാക്കുന്നു. ഇത് അങ്ങനെ പ്രവർത്തിക്കുന്നു, പക്ഷേ അത് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു. നിങ്ങൾ ഏറ്റവും കുറഞ്ഞ നല്ല മൂല്യം സജ്ജീകരിച്ചാൽ - അത് മൂല്യത്തിൽ ഏറ്റവും വലുതാണ്, ഏറ്റവും കുറഞ്ഞ മുൻഗണന എന്നാണ് അർത്ഥമാക്കുന്നത് - കൂടാതെ ഉയർന്ന മുൻഗണനയുള്ള അഭ്യർത്ഥനകൾക്ക് -19 എന്ന് സജ്ജീകരിക്കുകയാണെങ്കിൽ, ഉയർന്ന മുൻ‌ഗണനയുള്ളവയെക്കാൾ ഏകദേശം നാലിരട്ടി കുറഞ്ഞ മുൻഗണനയുള്ള അഭ്യർത്ഥനകൾ CPU ഉപയോഗിക്കും.
നിങ്ങൾ പരമാവധി അഭ്യർത്ഥന നിർവ്വഹണ സമയവും കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട് - പറയുക, അഞ്ച് മിനിറ്റ്. ഏറ്റവും കുറഞ്ഞ അന്വേഷണ വേഗതയാണ് ഏറ്റവും മികച്ച കാര്യം. ഈ ക്രമീകരണം വളരെക്കാലമായി നിലവിലുണ്ട്, മാത്രമല്ല ClickHouse മന്ദഗതിയിലല്ലെന്ന് ഉറപ്പിക്കാൻ മാത്രമല്ല, അത് നിർബന്ധിക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.
സങ്കൽപ്പിക്കുക, നിങ്ങൾ കോൺഫിഗർ ചെയ്യുന്നു: ചില അന്വേഷണം സെക്കൻഡിൽ ഒരു ദശലക്ഷത്തിൽ താഴെ വരികൾ പ്രോസസ്സ് ചെയ്യുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയില്ല. ഇത് നമ്മുടെ നല്ല പേരിനെയും നല്ല ഡാറ്റാബേസിനെയും അപകീർത്തിപ്പെടുത്തുന്നു. നമുക്ക് ഇത് നിരോധിക്കാം. യഥാർത്ഥത്തിൽ രണ്ട് ക്രമീകരണങ്ങളുണ്ട്. ഒന്ന് വിളിക്കപ്പെടുന്നു മിനിറ്റ് എക്സിക്യൂഷൻ വേഗത - ഒരു സെക്കൻഡിലെ വരികളിൽ, രണ്ടാമത്തേത് മിനിറ്റ് എക്സിക്യൂഷൻ വേഗത പരിശോധിക്കുന്നതിന് മുമ്പ് ടൈംഔട്ട് എന്ന് വിളിക്കുന്നു - സ്ഥിരസ്ഥിതിയായി പതിനഞ്ച് സെക്കൻഡ്. അതായത്, പതിനഞ്ച് സെക്കൻഡ് സാധ്യമാണ്, തുടർന്ന്, അത് മന്ദഗതിയിലാണെങ്കിൽ, ഒരു ഒഴിവാക്കൽ എറിഞ്ഞ് അഭ്യർത്ഥന നിർത്തലാക്കുക.
നിങ്ങൾ ക്വാട്ടകളും സജ്ജീകരിക്കേണ്ടതുണ്ട്. വിഭവ ഉപഭോഗം കണക്കാക്കുന്ന ഒരു ബിൽറ്റ്-ഇൻ ക്വാട്ട സവിശേഷത ClickHouse-ന് ഉണ്ട്. പക്ഷേ, നിർഭാഗ്യവശാൽ, സിപിയു, ഡിസ്കുകൾ പോലുള്ള ഹാർഡ്‌വെയർ ഉറവിടങ്ങളല്ല, ലോജിക്കൽ - പ്രോസസ്സ് ചെയ്ത അഭ്യർത്ഥനകളുടെ എണ്ണം, ലൈനുകൾ, ബൈറ്റുകൾ എന്നിവ വായിച്ചു. നിങ്ങൾക്ക് ക്രമീകരിക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, അഞ്ച് മിനിറ്റിനുള്ളിൽ പരമാവധി നൂറ് അഭ്യർത്ഥനകളും മണിക്കൂറിൽ ആയിരം അഭ്യർത്ഥനകളും.
എന്തുകൊണ്ട് അത് പ്രധാനമാണ്? കാരണം ചില അനലിറ്റിക്സ് അന്വേഷണങ്ങൾ ClickHouse ക്ലയന്റിൽ നിന്ന് നേരിട്ട് നേരിട്ട് നടപ്പിലാക്കും. കൂടാതെ എല്ലാം ശുഭമാകും. എന്നാൽ നിങ്ങളുടെ കമ്പനിയിൽ വിപുലമായ അനലിസ്റ്റുകൾ ഉണ്ടെങ്കിൽ, അവർ ഒരു സ്ക്രിപ്റ്റ് എഴുതും, കൂടാതെ സ്ക്രിപ്റ്റിൽ ഒരു പിശക് ഉണ്ടാകാം. ഈ പിശക് അഭ്യർത്ഥന അനന്തമായ ലൂപ്പിൽ നടപ്പിലാക്കാൻ ഇടയാക്കും. ഇതിൽ നിന്നാണ് നമ്മൾ സ്വയം സംരക്ഷിക്കേണ്ടത്.
പത്ത് ക്ലയന്റുകൾക്ക് ഒരു ചോദ്യത്തിന്റെ ഫലങ്ങൾ നൽകാൻ കഴിയുമോ?
ഒരേ സമയത്ത് വളരെ വലിയ അഭ്യർത്ഥനകളുമായി വരാൻ ഇഷ്ടപ്പെടുന്ന നിരവധി ഉപയോക്താക്കൾ ഞങ്ങൾക്കുണ്ട്. അഭ്യർത്ഥന വലുതാണ്, തത്വത്തിൽ ഇത് വേഗത്തിൽ നടപ്പിലാക്കുന്നു, എന്നാൽ ഒരേ സമയം അത്തരം നിരവധി അഭ്യർത്ഥനകൾ ഉള്ളതിനാൽ ഇത് വളരെ വേദനാജനകമാണ്. തുടർച്ചയായി പത്ത് തവണ വന്ന അതേ റിക്വസ്റ്റ് ഒരിക്കൽ എക്സിക്യൂട്ട് ചെയ്ത് പത്ത് ക്ലയന്റുകൾക്ക് ഫലം നൽകാനാകുമോ?
ഇന്റർമീഡിയറ്റ് ഡാറ്റയുടെ കാഷെ അല്ലെങ്കിൽ കാഷെയുടെ ഫലങ്ങൾ ഞങ്ങളുടെ പക്കലില്ല എന്നതാണ് പ്രശ്നം. ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ ഒരു പേജ് കാഷെ ഉണ്ട്, അത് ഡിസ്കിൽ നിന്നുള്ള ഡാറ്റ വീണ്ടും വായിക്കുന്നതിൽ നിന്ന് നിങ്ങളെ തടയും, പക്ഷേ, നിർഭാഗ്യവശാൽ, ഡാറ്റ ഇപ്പോഴും ഡീകംപ്രസ് ചെയ്യപ്പെടുകയും ഡീസിയലൈസ് ചെയ്യുകയും വീണ്ടും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യും.
ഇന്റർമീഡിയറ്റ് ഡാറ്റ കാഷെ ചെയ്യുന്നതിലൂടെയോ അല്ലെങ്കിൽ ഏതെങ്കിലും തരത്തിലുള്ള ക്യൂവിൽ സമാന ചോദ്യങ്ങൾ നിരത്തി ഫല കാഷെ ചേർത്തുകൊണ്ട് ഇത് എങ്ങനെയെങ്കിലും ഒഴിവാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. നിലവിൽ ഞങ്ങൾക്ക് വികസനത്തിൽ ഒരു അഭ്യർത്ഥന കാഷെ ചേർക്കുന്ന ഒരു പുൾ അഭ്യർത്ഥനയുണ്ട്, എന്നാൽ ഇൻ, ജോയിൻ വിഭാഗങ്ങളിലെ സബ്ക്വറികൾക്കായി മാത്രം - അതായത്, പരിഹാരം അപൂർണ്ണമാണ്.
എന്നിരുന്നാലും, ഞങ്ങളും ഈ സാഹചര്യത്തെ അഭിമുഖീകരിക്കുന്നു. ഒരു പ്രത്യേക കാനോനിക്കൽ ഉദാഹരണം പേജിനേഷൻ ഉള്ള അന്വേഷണങ്ങളാണ്. ഒരു റിപ്പോർട്ടുണ്ട്, ഇതിന് നിരവധി പേജുകളുണ്ട്, പരിധി 10-ന് ഒരു അഭ്യർത്ഥനയുണ്ട്. പിന്നെ അതേ കാര്യം, എന്നാൽ പരിമിതപ്പെടുത്തുക 10,10. പിന്നെ മറ്റൊരു അടുത്ത പേജ്. പിന്നെ ചോദ്യം, എന്തിനാണ് നമ്മൾ ഇതെല്ലാം ഓരോ തവണയും കണക്കാക്കുന്നത്? എന്നാൽ ഇപ്പോൾ പരിഹാരമില്ല, ഒഴിവാക്കാനും വഴിയില്ല.
ClickHouse-ന് അടുത്തായി സൈഡ്കാറായി സ്ഥാപിച്ചിരിക്കുന്ന ഒരു ബദൽ പരിഹാരമുണ്ട് - .
കിറിൽ ഷ്വാക്കോവ്: ClickHouse പ്രോക്സിക്ക് ഒരു ബിൽറ്റ്-ഇൻ റേറ്റ് ലിമിറ്ററും ഒരു ബിൽറ്റ്-ഇൻ ഫല കാഷെയും ഉണ്ട്. സമാനമായ ഒരു പ്രശ്നം പരിഹരിക്കപ്പെടുന്നതിനാൽ അവിടെ ധാരാളം ക്രമീകരണങ്ങൾ ചെയ്തു. അഭ്യർത്ഥനകൾ ക്യൂവിൽ നിർത്തി അവ പരിമിതപ്പെടുത്താനും അഭ്യർത്ഥന കാഷെ എത്രത്തോളം നിലനിൽക്കുമെന്ന് കോൺഫിഗർ ചെയ്യാനും പ്രോക്സി നിങ്ങളെ അനുവദിക്കുന്നു. അഭ്യർത്ഥനകൾ ശരിക്കും സമാനമാണെങ്കിൽ, പ്രോക്സി അവ പലതവണ അയയ്‌ക്കും, പക്ഷേ ഒരിക്കൽ മാത്രമേ ക്ലിക്ക്ഹൗസിലേക്ക് പോകൂ.
Nginx-ന് സൗജന്യ പതിപ്പിൽ ഒരു കാഷെ ഉണ്ട്, ഇതും പ്രവർത്തിക്കും. ഒരേ സമയം അഭ്യർത്ഥനകൾ വന്നാൽ, ഒന്ന് പൂർത്തിയാകുന്നത് വരെ അത് മന്ദഗതിയിലാക്കുന്ന ക്രമീകരണങ്ങൾ പോലും Nginx-നുണ്ട്. എന്നാൽ ക്ലിക്ക്ഹൗസ് പ്രോക്സിയിലാണ് സജ്ജീകരണം കൂടുതൽ മികച്ചത്. ഇത് ക്ലിക്ക്ഹൗസിനായി പ്രത്യേകമായി നിർമ്മിച്ചതാണ്, പ്രത്യേകിച്ച് ഈ അഭ്യർത്ഥനകൾക്കായി, അതിനാൽ ഇത് കൂടുതൽ അനുയോജ്യമാണ്. ശരി, ഇത് ഇൻസ്റ്റാൾ ചെയ്യാൻ എളുപ്പമാണ്.
അസിൻക്രണസ് ഓപ്പറേഷനുകളെക്കുറിച്ചും മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചകളെക്കുറിച്ചും എന്താണ്?
റീപ്ലേ എഞ്ചിനുമായുള്ള പ്രവർത്തനങ്ങൾ അസമന്വിതമാണെന്ന ഒരു പ്രശ്നമുണ്ട് - ആദ്യം ഡാറ്റ എഴുതിയിരിക്കുന്നു, തുടർന്ന് അത് തകരുന്നു. ചില അഗ്രഗേറ്റുകളുള്ള ഒരു മെറ്റീരിയലൈസ്ഡ് ടാബ്‌ലെറ്റ് ടാബ്‌ലെറ്റിന് കീഴിലാണെങ്കിൽ, ഡ്യൂപ്ലിക്കേറ്റുകൾ അതിൽ രേഖപ്പെടുത്തും. സങ്കീർണ്ണമായ യുക്തി ഇല്ലെങ്കിൽ, ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യപ്പെടും. ഇതിന് എന്ത് ചെയ്യാൻ കഴിയും?
ഒരു വ്യക്തമായ പരിഹാരമുണ്ട് - ഒരു അസിൻക്രണസ് തകർച്ച പ്രവർത്തന സമയത്ത് ഒരു പ്രത്യേക തരം മാറ്റ്വ്യൂകളിൽ ഒരു ട്രിഗർ നടപ്പിലാക്കാൻ. സമാനമായ പ്രവർത്തനം നടപ്പിലാക്കാൻ എന്തെങ്കിലും വെള്ളി ബുള്ളറ്റുകളോ പദ്ധതികളോ ഉണ്ടോ?
ഡ്യൂപ്ലിക്കേഷൻ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസ്സിലാക്കുന്നത് മൂല്യവത്താണ്. ഞാൻ ഇപ്പോൾ സംസാരിക്കാൻ പോകുന്നത് ചോദ്യവുമായി ബന്ധപ്പെട്ടതല്ല, പക്ഷേ അത് ഓർമ്മിക്കേണ്ടതാണ്.
ഒരു പകർപ്പെടുത്ത പട്ടികയിലേക്ക് തിരുകുമ്പോൾ, ചേർത്ത മുഴുവൻ ബ്ലോക്കുകളും ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യപ്പെടും. ഒരേ ക്രമത്തിൽ ഒരേ വരികളുടെ അതേ നമ്പർ അടങ്ങിയ അതേ ബ്ലോക്ക് നിങ്ങൾ വീണ്ടും ചേർത്തിട്ടുണ്ടെങ്കിൽ, ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യപ്പെടും. ഉൾപ്പെടുത്തലിനുള്ള പ്രതികരണമായി നിങ്ങൾക്ക് "ശരി" ലഭിക്കും, എന്നാൽ വാസ്തവത്തിൽ ഒരു പാക്കറ്റ് ഡാറ്റ എഴുതപ്പെടും, അത് ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യപ്പെടില്ല.
ഉറപ്പിന് ഇത് ആവശ്യമാണ്. ഇൻസേർഷൻ സമയത്ത് നിങ്ങൾക്ക് "ശരി" ലഭിക്കുകയാണെങ്കിൽ, നിങ്ങളുടെ ഡാറ്റ ചേർത്തു. ClickHouse-ൽ നിന്ന് നിങ്ങൾക്ക് ഒരു പിശക് ലഭിക്കുകയാണെങ്കിൽ, അതിനർത്ഥം അവ ചേർത്തിട്ടില്ലെന്നും നിങ്ങൾ ചേർക്കൽ ആവർത്തിക്കേണ്ടതുണ്ടെന്നും എന്നാണ്. എന്നാൽ ഇൻസേർഷൻ സമയത്ത് കണക്ഷൻ നഷ്ടപ്പെട്ടാൽ, ഡാറ്റ ചേർത്തിട്ടുണ്ടോ ഇല്ലയോ എന്ന് നിങ്ങൾക്ക് അറിയില്ല. തിരുകൽ വീണ്ടും ആവർത്തിക്കുക എന്നതാണ് ഏക പോംവഴി. യഥാർത്ഥത്തിൽ ഡാറ്റ തിരുകുകയും നിങ്ങൾ അത് വീണ്ടും ചേർക്കുകയും ചെയ്താൽ, ബ്ലോക്ക് ഡ്യൂപ്ലിക്കേഷൻ ഉണ്ട്. തനിപ്പകർപ്പുകൾ ഒഴിവാക്കാൻ ഇത് ആവശ്യമാണ്.
ഭൗതികമായ കാഴ്ചകൾക്കായി ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതും പ്രധാനമാണ്. പ്രധാന പട്ടികയിൽ ചേർക്കുമ്പോൾ ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്‌തിട്ടുണ്ടെങ്കിൽ, അത് മെറ്റീരിയലൈസ് ചെയ്ത കാഴ്‌ചയിലേക്ക് പോകില്ല.
ഇപ്പോൾ ചോദ്യത്തെക്കുറിച്ച്. നിങ്ങൾ വ്യക്തിഗത വരികളുടെ തനിപ്പകർപ്പുകൾ റെക്കോർഡുചെയ്യുന്നതിനാൽ നിങ്ങളുടെ സാഹചര്യം കൂടുതൽ സങ്കീർണ്ണമാണ്. അതായത്, മുഴുവൻ പായ്ക്കും തനിപ്പകർപ്പല്ല, മറിച്ച് നിർദ്ദിഷ്ട ലൈനുകളാണ്, അവ പശ്ചാത്തലത്തിൽ തകരുന്നു. വാസ്തവത്തിൽ, പ്രധാന പട്ടികയിൽ ഡാറ്റ ചുരുക്കപ്പെടും, എന്നാൽ ചുരുങ്ങാത്ത ഡാറ്റ മെറ്റീരിയലൈസ്ഡ് കാഴ്‌ചയിലേക്ക് പോകും, ഒപ്പം ലയിപ്പിക്കുമ്പോൾ മെറ്റീരിയൽ കാഴ്ചകൾക്ക് ഒന്നും സംഭവിക്കില്ല. കാരണം ഭൗതികവൽക്കരിച്ച കാഴ്ച ഒരു ഇൻസേർട്ട് ട്രിഗറല്ലാതെ മറ്റൊന്നുമല്ല. മറ്റ് പ്രവർത്തനങ്ങളിൽ, അധികമായി ഒന്നും സംഭവിക്കുന്നില്ല.
പിന്നെ നിന്നെ ഇവിടെ സന്തോഷിപ്പിക്കാൻ എനിക്കാവില്ല. ഈ കേസിൽ ഒരു പ്രത്യേക പരിഹാരം നിങ്ങൾ നോക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ഒരു സാധുവായ കാഴ്‌ചയിൽ ഇത് വീണ്ടും പ്ലേ ചെയ്യാൻ കഴിയുമോ, ഡ്യൂപ്ലിക്കേഷൻ രീതി അതേ രീതിയിൽ പ്രവർത്തിച്ചേക്കാം. എന്നാൽ നിർഭാഗ്യവശാൽ, എല്ലായ്പ്പോഴും അല്ല. ഇത് സമാഹരിച്ചാൽ, അത് പ്രവർത്തിക്കില്ല.
കിറിൽ ഷ്വാക്കോവ്: ഒരു കാലത്ത് ഊന്നുവടി നിർമാണവും ഞങ്ങൾക്കുണ്ടായിരുന്നു. പരസ്യ ഇംപ്രഷനുകൾ ഉള്ളതിൽ ഒരു പ്രശ്നമുണ്ട്, തത്സമയം കാണിക്കാൻ കഴിയുന്ന ചില ഡാറ്റയുണ്ട് - ഇവ വെറും ഇംപ്രഷനുകൾ മാത്രമാണ്. അവ വളരെ അപൂർവമായി മാത്രമേ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യപ്പെടുന്നുള്ളൂ, എന്നാൽ ഇത് സംഭവിക്കുകയാണെങ്കിൽ, എന്തായാലും പിന്നീട് ഞങ്ങൾ അവയെ തകർക്കും. ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യാൻ കഴിയാത്ത കാര്യങ്ങളും ഉണ്ടായിരുന്നു-ക്ലിക്കുകളും ആ മുഴുവൻ കഥയും. എന്നാൽ അവ ഉടൻ തന്നെ കാണിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു.
എങ്ങനെയാണ് വസ്തുനിഷ്ഠമായ കാഴ്ചപ്പാടുകൾ ഉണ്ടാക്കിയത്? അത് നേരിട്ട് എഴുതിയ കാഴ്ചകൾ ഉണ്ടായിരുന്നു - അത് അസംസ്കൃത ഡാറ്റയിലേക്ക് എഴുതിയതാണ്, കാഴ്ചകൾക്ക് എഴുതിയതാണ്. അവിടെ, ചില ഘട്ടങ്ങളിൽ, ഡാറ്റ വളരെ ശരിയല്ല, അത് തനിപ്പകർപ്പാണ്, മുതലായവ. പട്ടികയുടെ രണ്ടാം ഭാഗമുണ്ട്, അവിടെ അവ ഭൗതികമായ കാഴ്ചകൾക്ക് സമാനമാണ്, അതായത്, അവയുടെ ഘടനയുടെ കാര്യത്തിൽ അവ തികച്ചും സമാനമാണ്. ഇടയ്‌ക്കിടെ ഞങ്ങൾ ഡാറ്റ വീണ്ടും കണക്കാക്കുകയും ഡ്യൂപ്ലിക്കേറ്റുകളില്ലാതെ ഡാറ്റ കണക്കാക്കുകയും ആ പട്ടികകളിൽ എഴുതുകയും ചെയ്യുന്നു.
ഞങ്ങൾ API-യിലൂടെ കടന്നുപോയി - ഇത് ClickHouse-ൽ സ്വമേധയാ പ്രവർത്തിക്കില്ല. കൂടാതെ API നോക്കുന്നു: പട്ടികയിൽ അവസാനമായി ചേർത്ത തീയതി എന്റെ പക്കലുണ്ടെങ്കിൽ, ശരിയായ ഡാറ്റ ഇതിനകം കണക്കാക്കിയിട്ടുണ്ടെന്നും അത് ഒരു ടേബിളിലേക്കും മറ്റൊരു പട്ടികയിലേക്കും ഒരു അഭ്യർത്ഥന നടത്തുന്നു. ഒന്നിൽ നിന്ന്, അഭ്യർത്ഥന ഒരു നിശ്ചിത സമയം വരെ തിരഞ്ഞെടുക്കുന്നു, മറ്റൊന്നിൽ നിന്ന് ഇതുവരെ കണക്കാക്കാത്തത് ലഭിക്കുന്നു. ഇത് പ്രവർത്തിക്കുന്നു, പക്ഷേ ClickHouse വഴി മാത്രമല്ല.
നിങ്ങൾക്ക് ഏതെങ്കിലും തരത്തിലുള്ള API ഉണ്ടെങ്കിൽ - അനലിസ്റ്റുകൾക്കായി, ഉപയോക്താക്കൾക്കായി - പിന്നെ, തത്വത്തിൽ, ഇത് ഒരു ഓപ്ഷനാണ്. നിങ്ങൾ എല്ലായ്പ്പോഴും എണ്ണിക്കൊണ്ടിരിക്കുന്നു, എല്ലായ്പ്പോഴും എണ്ണുന്നു. ഇത് ഒരു ദിവസത്തിലൊരിക്കലോ മറ്റേതെങ്കിലും സമയത്തോ ചെയ്യാം. നിങ്ങൾക്ക് ആവശ്യമില്ലാത്തതും നിർണായകമല്ലാത്തതുമായ ഒരു ശ്രേണി നിങ്ങൾ സ്വയം തിരഞ്ഞെടുക്കുന്നു.
ClickHouse-ൽ ധാരാളം ലോഗുകൾ ഉണ്ട്. സെർവറിന് സംഭവിക്കുന്നതെല്ലാം ഒറ്റനോട്ടത്തിൽ എനിക്ക് എങ്ങനെ കാണാൻ കഴിയും?
ClickHouse ന് വ്യത്യസ്ത ലോഗുകളുടെ ഒരു വലിയ സംഖ്യയുണ്ട്, ഈ എണ്ണം വർദ്ധിച്ചുകൊണ്ടിരിക്കുന്നു. പുതിയ പതിപ്പുകളിൽ, അവയിൽ ചിലത് ഡിഫോൾട്ടായി പോലും പ്രവർത്തനക്ഷമമാക്കും; പഴയ പതിപ്പുകളിൽ അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ അവ പ്രവർത്തനക്ഷമമാക്കിയിരിക്കണം. എന്നിരുന്നാലും, അവയിൽ കൂടുതൽ കൂടുതൽ ഉണ്ട്. എന്റെ സെർവറിൽ ഇപ്പോൾ എന്താണ് സംഭവിക്കുന്നതെന്ന് അവസാനമായി കാണാൻ ഞാൻ ആഗ്രഹിക്കുന്നു, ഒരുപക്ഷേ ഏതെങ്കിലും തരത്തിലുള്ള സംഗ്രഹ ഡാഷ്‌ബോർഡിൽ.
ഈ ലോഗുകൾ ഒരു പൂർത്തിയായ ഉൽപ്പന്നമായി പ്രദർശിപ്പിക്കുന്ന റെഡിമെയ്ഡ് ഡാഷ്‌ബോർഡുകളുടെ ചില പ്രവർത്തനങ്ങളെ പിന്തുണയ്ക്കുന്ന നിങ്ങളുടെ ClickHouse ടീമിലോ സുഹൃത്തുക്കളുടെ ടീമുകളിലോ നിങ്ങൾക്കുണ്ടോ? ആത്യന്തികമായി, ക്ലിക്ക്ഹൗസിലെ ലോഗുകൾ നോക്കുന്നത് വളരെ മികച്ചതാണ്. എന്നാൽ ഇത് ഇതിനകം തന്നെ ഒരു ഡാഷ്ബോർഡ് രൂപത്തിൽ തയ്യാറാക്കിയിട്ടുണ്ടെങ്കിൽ അത് വളരെ കൂൾ ആയിരിക്കും. ഇതിൽ നിന്ന് ഞാൻ ഉയരത്തിൽ എത്തും.
സ്റ്റാൻഡേർഡ് അല്ലെങ്കിലും ഡാഷ്ബോർഡുകൾ ഉണ്ട്. ഞങ്ങളുടെ കമ്പനിയിൽ, ഏകദേശം 60 ടീമുകൾ ClickHouse ഉപയോഗിക്കുന്നു, ഏറ്റവും വിചിത്രമായ കാര്യം, അവരിൽ പലർക്കും അവർ സ്വയം നിർമ്മിച്ച ഡാഷ്‌ബോർഡുകളും അല്പം വ്യത്യസ്തമായവയുമാണ്. ചില ടീമുകൾ ഒരു ആന്തരിക Yandex.Cloud ഇൻസ്റ്റാളേഷൻ ഉപയോഗിക്കുന്നു. ആവശ്യമായ എല്ലാ റിപ്പോർട്ടുകളും ഇല്ലെങ്കിലും ചില റെഡിമെയ്ഡ് റിപ്പോർട്ടുകൾ ഉണ്ട്. മറ്റുള്ളവർക്ക് സ്വന്തമായുണ്ട്.
മെട്രിക്കയിൽ നിന്നുള്ള എന്റെ സഹപ്രവർത്തകർക്ക് ഗ്രാഫാനയിൽ അവരുടെ സ്വന്തം ഡാഷ്ബോർഡ് ഉണ്ട്, അവരുടെ സ്വന്തം ക്ലസ്റ്ററിനായി എനിക്ക് സ്വന്തമായി ഉണ്ട്. സെരിഫ് കാഷെക്കായി കാഷെ ഹിറ്റ് പോലെയുള്ള കാര്യങ്ങൾ ഞാൻ നോക്കുകയാണ്. ഞങ്ങൾ വ്യത്യസ്ത ഉപകരണങ്ങൾ ഉപയോഗിക്കുന്നു എന്നതാണ് അതിലും ബുദ്ധിമുട്ടുള്ളത്. ഗ്രാഫൈറ്റ്-വെബ് എന്ന പഴയ ടൂൾ ഉപയോഗിച്ചാണ് ഞാൻ എന്റെ ഡാഷ്ബോർഡ് സൃഷ്ടിച്ചത്. അവൻ തികച്ചും വിരൂപനാണ്. ഗ്രാഫാന കൂടുതൽ സൗകര്യപ്രദവും മനോഹരവുമാകുമെങ്കിലും ഞാൻ ഇപ്പോഴും അത് ഉപയോഗിക്കുന്നത് അങ്ങനെയാണ്.
ഡാഷ്‌ബോർഡുകളിലെ അടിസ്ഥാനകാര്യം ഒന്നുതന്നെയാണ്. ഇവയാണ് ക്ലസ്റ്ററിനുള്ള സിസ്റ്റം മെട്രിക്സ്: സിപിയു, മെമ്മറി, ഡിസ്ക്, നെറ്റ്വർക്ക്. മറ്റുള്ളവ, ഒരേസമയം അഭ്യർത്ഥനകളുടെ എണ്ണം, ഒരേസമയം ലയിപ്പിക്കലുകളുടെ എണ്ണം, സെക്കൻഡിലെ അഭ്യർത്ഥനകളുടെ എണ്ണം, മെർജ്‌ട്രീ ടേബിളുകളുടെ പാർട്ടീഷനുകൾക്കായുള്ള പരമാവധി എണ്ണം, റെപ്ലിക്കേഷൻ ലാഗ്, റെപ്ലിക്കേഷൻ ക്യൂ വലുപ്പം, സെക്കൻഡിൽ തിരുകിയ വരികളുടെ എണ്ണം, ചേർത്ത ബ്ലോക്കുകളുടെ എണ്ണം. ഓരോ സെക്കന്റിലും. ലോഗുകളിൽ നിന്നല്ല, മെട്രിക്സിൽ നിന്നാണ് ഇതെല്ലാം ലഭിക്കുന്നത്.
വ്ലാഡിമിർ കൊളോബേവ്: അലക്സി, ഇത് കുറച്ച് തിരുത്താൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഗ്രാഫാനയുണ്ട്. ഗ്രാഫാനയ്ക്ക് ഒരു ഡാറ്റാസോഴ്സ് ഉണ്ട്, അത് ClickHouse ആണ്. അതായത്, എനിക്ക് ഗ്രാഫാനയിൽ നിന്ന് നേരിട്ട് ക്ലിക്ക്ഹൗസിലേക്ക് അഭ്യർത്ഥനകൾ നടത്താം. ClickHouse-ൽ ലോഗുകളുള്ള ഒരു പട്ടികയുണ്ട്, ഇത് എല്ലാവർക്കും ഒരുപോലെയാണ്. തൽഫലമായി, ഗ്രാഫാനയിലെ ഈ ലോഗ് ടേബിൾ ആക്സസ് ചെയ്യാനും എന്റെ സെർവർ നടത്തുന്ന അഭ്യർത്ഥനകൾ കാണാനും ഞാൻ ആഗ്രഹിക്കുന്നു. ഇതുപോലൊരു ഡാഷ്ബോർഡ് ഉണ്ടെങ്കിൽ വളരെ നന്നായിരിക്കും.
ഞാൻ തന്നെ ബൈക്ക് ഓടിച്ചു. എന്നാൽ എനിക്ക് ഒരു ചോദ്യമുണ്ട്: ഇതെല്ലാം സ്റ്റാൻഡേർഡ് ആണെങ്കിൽ, ഗ്രാഫാന എല്ലാവരും ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ, എന്തുകൊണ്ടാണ് Yandex-ൽ അത്തരമൊരു ഔദ്യോഗിക ഡാഷ്ബോർഡ് ഇല്ലാത്തത്?
കിറിൽ ഷ്വാക്കോവ്: വാസ്തവത്തിൽ, ClickHouse-ലേക്ക് പോകുന്ന ഡാറ്റാ ഉറവിടം ഇപ്പോൾ Altinity-യെ പിന്തുണയ്ക്കുന്നു. എവിടെ കുഴിക്കണം, ആരെ തള്ളണം എന്നതിന്റെ ഒരു വെക്റ്റർ നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. നിങ്ങൾക്ക് അവരോട് ചോദിക്കാം, കാരണം Yandex ഇപ്പോഴും ClickHouse നിർമ്മിക്കുന്നു, അല്ലാതെ അതിനെ ചുറ്റിപ്പറ്റിയുള്ള കഥയല്ല. നിലവിൽ ClickHouse പ്രൊമോട്ട് ചെയ്യുന്ന പ്രധാന കമ്പനിയാണ് Altinity. അവർ അവനെ ഉപേക്ഷിക്കുകയില്ല, പക്ഷേ അവനെ പിന്തുണയ്ക്കും. കാരണം, തത്വത്തിൽ, ഗ്രാഫാന വെബ്‌സൈറ്റിലേക്ക് ഒരു ഡാഷ്ബോർഡ് അപ്‌ലോഡ് ചെയ്യുന്നതിന്, നിങ്ങൾ രജിസ്റ്റർ ചെയ്ത് അപ്‌ലോഡ് ചെയ്യേണ്ടതുണ്ട് - പ്രത്യേക പ്രശ്നങ്ങളൊന്നുമില്ല.
അലക്സി മിലോവിഡോവ്: കഴിഞ്ഞ ഒരു വർഷമായി, ClickHouse നിരവധി അന്വേഷണ പ്രൊഫൈലിംഗ് കഴിവുകൾ ചേർത്തിട്ടുണ്ട്. വിഭവങ്ങളുടെ ഉപയോഗവുമായി ബന്ധപ്പെട്ട് ഓരോ അഭ്യർത്ഥനയ്ക്കും അളവുകൾ ഉണ്ട്. അടുത്തിടെ, ഓരോ മില്ലിസെക്കൻഡും ഒരു ചോദ്യം എവിടെയാണ് ചെലവഴിക്കുന്നതെന്ന് കാണാൻ ഞങ്ങൾ ഒരു താഴ്ന്ന നിലയിലുള്ള ചോദ്യ പ്രൊഫൈലർ ചേർത്തു. എന്നാൽ ഈ പ്രവർത്തനം ഉപയോഗിക്കുന്നതിന്, ഞാൻ കൺസോൾ ക്ലയന്റ് തുറന്ന് ഒരു അഭ്യർത്ഥന ടൈപ്പ് ചെയ്യണം, അത് ഞാൻ എപ്പോഴും മറക്കുന്നു. ഞാൻ അത് എവിടെയോ സംരക്ഷിച്ചു, കൃത്യമായി എവിടെയാണെന്ന് മറക്കുന്നു.
ക്വറി ക്ലാസ് പ്രകാരം ഗ്രൂപ്പുചെയ്‌ത നിങ്ങളുടെ കനത്ത ചോദ്യങ്ങൾ ഇതാ, ലളിതമായി പറയുന്ന ഒരു ഉപകരണം ഉണ്ടായിരുന്നെങ്കിൽ എന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു. ഞാൻ ഒന്ന് അമർത്തി, അത് ഭാരമുള്ളതാണെന്ന് അവർ എന്നോട് പറയും. ഇപ്പോൾ അത്തരമൊരു പരിഹാരമില്ല. ആളുകൾ എന്നോട് ചോദിക്കുന്നത് വളരെ വിചിത്രമാണ്: “എന്നോട് പറയൂ, ഗ്രാഫാനയ്‌ക്കായി എന്തെങ്കിലും റെഡിമെയ്ഡ് ഡാഷ്ബോർഡുകൾ ഉണ്ടോ?”, ഞാൻ പറയുന്നു: “ഗ്രാഫാന വെബ്‌സൈറ്റിലേക്ക് പോകുക, അവിടെ ഒരു “ഡാഷ്ബോർഡ്” കമ്മ്യൂണിറ്റിയുണ്ട്, അവിടെ ഒരു ഡാഷ്‌ബോർഡും ഉണ്ട്. ഡിംകയിൽ നിന്ന്, കോസ്റ്റ്യാനിൽ നിന്ന് ഒരു ഡാഷ്ബോർഡ് ഉണ്ട്. അത് എന്താണെന്ന് എനിക്കറിയില്ല, ഞാൻ അത് സ്വയം ഉപയോഗിച്ചിട്ടില്ല.
സെർവർ OOM-ൽ ക്രാഷ് ചെയ്യാതിരിക്കാൻ ലയനങ്ങളെ എങ്ങനെ സ്വാധീനിക്കാം?
എനിക്ക് ഒരു ടേബിൾ ഉണ്ട്, പട്ടികയിൽ ഒരു പാർട്ടീഷൻ മാത്രമേയുള്ളൂ, അത് ReplacingMergeTree ആണ്. നാല് വർഷമായി ഞാൻ അതിൽ ഡാറ്റ എഴുതുന്നു. എനിക്ക് അതിൽ ഒരു മാറ്റം വരുത്തുകയും കുറച്ച് ഡാറ്റ ഇല്ലാതാക്കുകയും ചെയ്യേണ്ടതുണ്ട്.
ഞാൻ ഇത് ചെയ്തു, ഈ അഭ്യർത്ഥനയുടെ പ്രോസസ്സിംഗ് സമയത്ത്, ക്ലസ്റ്ററിലെ എല്ലാ സെർവറുകളിലെയും എല്ലാ മെമ്മറിയും ക്ഷയിച്ചു, കൂടാതെ ക്ലസ്റ്ററിലെ എല്ലാ സെർവറുകളും OOM-ലേക്ക് പോയി. തുടർന്ന് എല്ലാവരും ഒരുമിച്ച് എഴുന്നേറ്റു, ഇതേ പ്രവർത്തനം, ഈ ഡാറ്റ ബ്ലോക്ക് ലയിപ്പിക്കാൻ തുടങ്ങി, വീണ്ടും OOM-ലേക്ക് വീണു. അപ്പോൾ അവർ വീണ്ടും എഴുന്നേറ്റു വീണ്ടും വീണു. ഈ സംഗതി നിന്നില്ല.
ഇത് യഥാർത്ഥത്തിൽ ആൺകുട്ടികൾ പരിഹരിച്ച ഒരു ബഗ് ആണെന്ന് പിന്നീട് മനസ്സിലായി. ഇത് വളരെ രസകരമാണ്, വളരെ നന്ദി. പക്ഷേ ഒരു അവശിഷ്ടം അവശേഷിച്ചു. ഇപ്പോൾ, ഒരു പട്ടികയിൽ ഏതെങ്കിലും തരത്തിലുള്ള ലയനം ചെയ്യുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുമ്പോൾ, എനിക്ക് ഒരു ചോദ്യമുണ്ട്: എന്തുകൊണ്ടാണ് എനിക്ക് ഈ ലയനങ്ങളെ എങ്ങനെയെങ്കിലും സ്വാധീനിക്കാൻ കഴിയാത്തത്? ഉദാഹരണത്തിന്, ആവശ്യമുള്ള റാമിന്റെ അളവ് അല്ലെങ്കിൽ തത്വത്തിൽ, ഈ പ്രത്യേക പട്ടിക പ്രോസസ്സ് ചെയ്യുന്ന തുക ഉപയോഗിച്ച് അവയെ പരിമിതപ്പെടുത്തുക.
എനിക്ക് "മെട്രിക്സ്" എന്ന് പേരുള്ള ഒരു ടേബിൾ ഉണ്ട്, അത് എനിക്ക് രണ്ട് ത്രെഡുകളായി പ്രോസസ്സ് ചെയ്യുക. പത്തോ അഞ്ചോ ലയനങ്ങൾ സമാന്തരമായി നിർമ്മിക്കേണ്ട ആവശ്യമില്ല, അത് രണ്ടായി ചെയ്യുക. എനിക്ക് രണ്ട് പേർക്ക് മതിയായ മെമ്മറി ഉണ്ടെന്ന് ഞാൻ കരുതുന്നു, പക്ഷേ പത്ത് പ്രോസസ്സ് ചെയ്യാൻ ഇത് മതിയാകില്ല. എന്തുകൊണ്ടാണ് ഭയം നിലനിൽക്കുന്നത്? കാരണം പട്ടിക വളരുകയാണ്, എന്നെങ്കിലും ഒരു സാഹചര്യം ഞാൻ അഭിമുഖീകരിക്കും, തത്വത്തിൽ, ഇനി ഒരു ബഗ് മൂലമല്ല, പക്ഷേ ഡാറ്റ വളരെ വലിയ അളവിൽ മാറുന്നതിനാൽ എനിക്ക് സെർവറിൽ മതിയായ മെമ്മറി ഉണ്ടാകില്ല. . ലയിപ്പിക്കുമ്പോൾ സെർവർ OOM-ൽ വീഴും. മാത്രമല്ല, എനിക്ക് മ്യൂട്ടേഷൻ റദ്ദാക്കാം, പക്ഷേ മെർജി ഇപ്പോൾ അവിടെയില്ല.
നിങ്ങൾക്ക് അറിയാം, ലയിപ്പിക്കുമ്പോൾ, സെർവർ OOM-ൽ വീഴില്ല, കാരണം ലയിപ്പിക്കുമ്പോൾ, RAM-ന്റെ അളവ് ഒരു ചെറിയ ഡാറ്റാ ശ്രേണിക്ക് മാത്രമേ ഉപയോഗിക്കൂ. അതിനാൽ ഡാറ്റയുടെ അളവ് പരിഗണിക്കാതെ എല്ലാം ശരിയാകും.
വ്ലാഡിമിർ കൊളോബേവ്: നന്നായി. ബഗ് പരിഹരിച്ചതിന് ശേഷം, ഞാൻ എനിക്കായി ഒരു പുതിയ പതിപ്പ് ഡൗൺലോഡ് ചെയ്തു, മറ്റൊരു ടേബിളിൽ, നിരവധി പാർട്ടീഷനുകൾ ഉള്ളിടത്ത്, ഞാൻ സമാനമായ ഒരു പ്രവർത്തനം നടത്തി. ലയന സമയത്ത്, സെർവറിൽ ഏകദേശം 100 ജിബി റാം കത്തിച്ചു. എനിക്ക് 150 എണ്ണം ഉണ്ടായിരുന്നു, 100 എണ്ണം കഴിച്ചു, 50 GB വിൻഡോ അവശേഷിക്കുന്നു, അതിനാൽ ഞാൻ OOM-ൽ വീണില്ല.
യഥാർത്ഥത്തിൽ 100 GB RAM ഉപയോഗിക്കുകയാണെങ്കിൽ OOM-ൽ വീഴുന്നതിൽ നിന്ന് എന്നെ സംരക്ഷിക്കുന്നത് എന്താണ്? ലയനത്തിലെ റാം പെട്ടെന്ന് തീർന്നുപോയാൽ നിങ്ങൾ എന്തുചെയ്യണം?
അലക്സി മിലോവിഡോവ്: റാം ഉപഭോഗം ലയിപ്പിക്കുന്നതിൽ മാത്രം ഒതുങ്ങുന്നില്ല എന്നൊരു പ്രശ്നമുണ്ട്. രണ്ടാമത്തെ പ്രശ്നം, ഏതെങ്കിലും തരത്തിലുള്ള ലയനം നിയുക്തമാക്കിയിട്ടുണ്ടെങ്കിൽ, അത് റെപ്ലിക്കേഷൻ ലോഗിൽ രേഖപ്പെടുത്തിയിരിക്കുന്നതിനാൽ അത് എക്സിക്യൂട്ട് ചെയ്യണം. പകർപ്പ് സ്ഥിരതയുള്ള അവസ്ഥയിലേക്ക് കൊണ്ടുവരാൻ ആവശ്യമായ പ്രവർത്തനങ്ങളാണ് റെപ്ലിക്കേഷൻ ലോഗ്. ഈ റെപ്ലിക്കേഷൻ ലോഗ് പിൻവലിക്കുന്ന മാനുവൽ കൃത്രിമങ്ങൾ നിങ്ങൾ നടത്തുന്നില്ലെങ്കിൽ, ലയനം ഒരു തരത്തിലല്ലെങ്കിൽ മറ്റൊരു തരത്തിൽ നടത്തേണ്ടിവരും.
തീർച്ചയായും, OOM-ൽ നിന്ന് പരിരക്ഷിക്കുന്ന ഒരു റാം പരിമിതി ഉണ്ടായിരിക്കുന്നത് അമിതമായിരിക്കില്ല. ലയനം പൂർത്തിയാക്കാൻ ഇത് സഹായിക്കില്ല, അത് വീണ്ടും ആരംഭിക്കും, ചില പരിധിയിലെത്തും, ഒരു അപവാദം എറിയുക, തുടർന്ന് വീണ്ടും ആരംഭിക്കുക - ഇതിൽ നിന്ന് നല്ലതൊന്നും വരില്ല. എന്നാൽ തത്വത്തിൽ, ഈ നിയന്ത്രണം അവതരിപ്പിക്കുന്നത് ഉപയോഗപ്രദമാകും.
ClickHouse-നുള്ള Golang ഡ്രൈവർ എങ്ങനെ വികസിപ്പിക്കും?
കിറിൽ ഷ്വാക്കോവ് എഴുതിയ ഗോലാങ് ഡ്രൈവർ, ഇപ്പോൾ ക്ലിക്ക്ഹൗസ് ടീം ഔദ്യോഗികമായി പിന്തുണയ്ക്കുന്നു. അവൻ , അവൻ ഇപ്പോൾ വലിയവനും യഥാർത്ഥനുമാണ്.
ഒരു ചെറിയ കുറിപ്പ്. അനന്തമായ ക്രമത്തിന്റെ സാധാരണ രൂപങ്ങളുടെ അതിശയകരവും പ്രിയപ്പെട്ടതുമായ ഒരു ശേഖരം ഉണ്ട് - ഇതാണ് വെർട്ടിക്ക. വെർട്ടിക്ക ഡെവലപ്പർമാർ പിന്തുണയ്ക്കുന്ന അവരുടെ ഔദ്യോഗിക പൈത്തൺ ഡ്രൈവറും അവർക്കുണ്ട്. സ്റ്റോറേജ് പതിപ്പുകളും ഡ്രൈവർ പതിപ്പുകളും വളരെ നാടകീയമായി വ്യതിചലിച്ചു, ഡ്രൈവർ ചില ഘട്ടങ്ങളിൽ പ്രവർത്തിക്കുന്നത് നിർത്തി. ഒപ്പം രണ്ടാമത്തെ പോയിന്റും. ഈ ഒഫീഷ്യൽ ഡ്രൈവർക്കുള്ള പിന്തുണ, "മുലക്കണ്ണ്" സിസ്റ്റമാണ് നടപ്പിലാക്കുന്നതെന്ന് എനിക്ക് തോന്നുന്നു - നിങ്ങൾ അവർക്ക് ഒരു പ്രശ്നം എഴുതുന്നു, അത് എന്നെന്നേക്കുമായി തൂങ്ങിക്കിടക്കും.
എനിക്ക് രണ്ട് ചോദ്യങ്ങളുണ്ട്. ഇപ്പോൾ Kirill ന്റെ Golang ഡ്രൈവർ Golang-ൽ നിന്ന് ClickHouse-മായി ആശയവിനിമയം നടത്തുന്നതിനുള്ള മിക്കവാറും സ്ഥിരസ്ഥിതി മാർഗമാണ്. ആരെങ്കിലും ഇപ്പോഴും http ഇന്റർഫേസ് വഴി ആശയവിനിമയം നടത്തുന്നില്ലെങ്കിൽ, അയാൾ അത് ഇഷ്ടപ്പെടുന്നു. ഈ ഡ്രൈവറിന്റെ വികസനം എങ്ങനെ തുടരും? റിപ്പോസിറ്ററിയിൽ തന്നെ എന്തെങ്കിലും ബ്രേക്കിംഗ് മാറ്റങ്ങളുമായി ഇത് സമന്വയിപ്പിക്കപ്പെടുമോ? ഒരു പ്രശ്നം പരിഗണിക്കുന്നതിനുള്ള നടപടിക്രമം എന്താണ്?
കിറിൽ ഷ്വാക്കോവ്: ബ്യൂറോക്രാറ്റിക്ക് എങ്ങനെ എല്ലാം ക്രമീകരിച്ചിരിക്കുന്നു എന്നതാണ് ആദ്യത്തേത്. ഈ വിഷയം ചർച്ച ചെയ്തിട്ടില്ല, അതിനാൽ എനിക്ക് ഉത്തരം നൽകാൻ ഒന്നുമില്ല.
പ്രശ്നത്തെക്കുറിച്ചുള്ള ചോദ്യത്തിന് ഉത്തരം നൽകാൻ, ഡ്രൈവറുടെ ഒരു ചെറിയ ചരിത്രം ആവശ്യമാണ്. ധാരാളം ഡാറ്റയുള്ള ഒരു കമ്പനിയിൽ ഞാൻ ജോലി ചെയ്തു. എവിടെയെങ്കിലും സൂക്ഷിക്കേണ്ട ധാരാളം സംഭവങ്ങളുള്ള ഒരു പരസ്യ സ്പിന്നറായിരുന്നു അത്. ചില സമയങ്ങളിൽ ക്ലിക്ക്ഹൗസ് പ്രത്യക്ഷപ്പെട്ടു. ഞങ്ങൾ അത് ഡാറ്റ ഉപയോഗിച്ച് പൂരിപ്പിച്ചു, ആദ്യം എല്ലാം ശരിയായിരുന്നു, പക്ഷേ ക്ലിക്ക്ഹൗസ് തകർന്നു. ആ നിമിഷം ഞങ്ങൾ അത് ആവശ്യമില്ലെന്ന് തീരുമാനിച്ചു.
ഒരു വർഷത്തിനുശേഷം, ക്ലിക്ക്ഹൗസ് ഉപയോഗിക്കുന്നതിനുള്ള ആശയത്തിലേക്ക് ഞങ്ങൾ മടങ്ങി, എങ്ങനെയെങ്കിലും അവിടെ ഡാറ്റ എഴുതേണ്ടതുണ്ട്. ആമുഖ സന്ദേശം ഇതായിരുന്നു: ഹാർഡ്‌വെയർ വളരെ ദുർബലമാണ്, കുറച്ച് ഉറവിടങ്ങളുണ്ട്. എന്നാൽ ഞങ്ങൾ എല്ലായ്പ്പോഴും ഈ രീതിയിൽ പ്രവർത്തിച്ചിട്ടുണ്ട്, അതിനാൽ ഞങ്ങൾ നേറ്റീവ് പ്രോട്ടോക്കോളിലേക്ക് നോക്കി.
ഞങ്ങൾ ഗോയിൽ ജോലി ചെയ്യുന്നതിനാൽ, ഞങ്ങൾക്ക് ഒരു ഗോ ഡ്രൈവറെ ആവശ്യമാണെന്ന് വ്യക്തമായി. ഞാൻ അത് ഏതാണ്ട് മുഴുവൻ സമയവും ചെയ്തു - ഇത് എന്റെ ജോലിയാണ്. ഞങ്ങൾ അത് ഒരു നിശ്ചിത ഘട്ടത്തിലേക്ക് കൊണ്ടുവന്നു, തത്ത്വത്തിൽ ഞങ്ങളല്ലാതെ മറ്റാരും അത് ഉപയോഗിക്കുമെന്ന് ആരും കരുതിയില്ല. പിന്നീട് CloudFlare കൃത്യമായി ഇതേ പ്രശ്‌നവുമായി വന്നു, കുറച്ച് സമയത്തേക്ക് ഞങ്ങൾ അവരോടൊപ്പം വളരെ സുഗമമായി പ്രവർത്തിച്ചു, കാരണം അവർക്ക് ഒരേ ജോലികൾ ഉണ്ടായിരുന്നു. മാത്രമല്ല, ഞങ്ങൾ ഇത് ക്ലിക്ക്ഹൗസിലും ഡ്രൈവറിലും ചെയ്തു.
ചില സമയങ്ങളിൽ, ഞാൻ അത് ചെയ്യുന്നത് നിർത്തി, കാരണം ക്ലിക്ക്ഹൗസിന്റെ വീക്ഷണകോണിൽ നിന്നും എന്റെ ജോലിയിൽ നിന്നും എന്റെ പ്രവർത്തനം അല്പം മാറി. അതിനാൽ പ്രശ്നങ്ങൾ അവസാനിപ്പിക്കുന്നില്ല. ആനുകാലികമായി, സ്വയം എന്തെങ്കിലും ആവശ്യമുള്ള ആളുകൾ ശേഖരത്തിൽ പ്രതിജ്ഞാബദ്ധരാണ്. അപ്പോൾ ഞാൻ പുൾ അഭ്യർത്ഥന നോക്കുന്നു, ചിലപ്പോൾ ഞാൻ സ്വയം എന്തെങ്കിലും എഡിറ്റുചെയ്യുന്നു, പക്ഷേ ഇത് വളരെ അപൂർവമായി മാത്രമേ സംഭവിക്കൂ.
ഡ്രൈവറിലേക്ക് മടങ്ങാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. കുറച്ച് വർഷങ്ങൾക്ക് മുമ്പ്, ഈ മുഴുവൻ കാര്യവും ആരംഭിച്ചപ്പോൾ, ക്ലിക്ക്ഹൗസും വ്യത്യസ്തമായിരുന്നു, വ്യത്യസ്ത കഴിവുകളുണ്ടായിരുന്നു. ഡ്രൈവർ എങ്ങനെ റീമേക്ക് ചെയ്യാം എന്നതിനെക്കുറിച്ച് ഇപ്പോൾ ഞങ്ങൾക്ക് ഒരു ധാരണയുണ്ട്, അങ്ങനെ അത് നന്നായി പ്രവർത്തിക്കുന്നു. ഇത് സംഭവിക്കുകയാണെങ്കിൽ, അടിഞ്ഞുകൂടിയ ക്രച്ചുകൾ കാരണം പതിപ്പ് 2 ഏത് സാഹചര്യത്തിലും പൊരുത്തപ്പെടുന്നില്ല.
ഈ വിഷയം എങ്ങനെ സംഘടിപ്പിക്കണമെന്ന് എനിക്കറിയില്ല. എനിക്ക് തന്നെ അധികം സമയമില്ല. ചിലർ ഡ്രൈവറെ പൂർത്തിയാക്കിയാൽ, ഞാൻ അവരെ സഹായിക്കുകയും എന്തുചെയ്യണമെന്ന് അവരോട് പറയുകയും ചെയ്യാം. എന്നാൽ പദ്ധതിയുടെ വികസനത്തിൽ Yandex ന്റെ സജീവ പങ്കാളിത്തം ഇതുവരെ ചർച്ച ചെയ്തിട്ടില്ല.
അലക്സി മിലോവിഡോവ്: വാസ്തവത്തിൽ, ഈ ഡ്രൈവർമാരെ സംബന്ധിച്ച് ഇതുവരെ ഒരു ബ്യൂറോക്രസി ഇല്ല. ഒരേയൊരു കാര്യം അവർ ഒരു ഔദ്യോഗിക ഓർഗനൈസേഷന് സമർപ്പിക്കുന്നു എന്നതാണ്, അതായത്, ഈ ഡ്രൈവർ Go-യുടെ ഔദ്യോഗിക സ്ഥിരസ്ഥിതി പരിഹാരമായി അംഗീകരിക്കപ്പെട്ടിരിക്കുന്നു. വേറെയും ചില ഡ്രൈവർമാർ ഉണ്ടെങ്കിലും അവർ വെവ്വേറെയാണ് വരുന്നത്.
ഈ ഡ്രൈവർമാർക്കായി ഞങ്ങൾക്ക് ഒരു ആന്തരിക വികസനവും ഇല്ല. ഈ പ്രത്യേക ഡ്രൈവർക്ക് വേണ്ടിയല്ല, മറിച്ച് എല്ലാ കമ്മ്യൂണിറ്റി ഡ്രൈവർമാരുടെയും വികസനത്തിന് വേണ്ടി നമുക്ക് ഒരു വ്യക്തിയെ നിയമിക്കാൻ കഴിയുമോ, അതോ പുറത്ത് നിന്ന് ഒരാളെ കണ്ടെത്താൻ കഴിയുമോ എന്നതാണ് ചോദ്യം.
lazy_load ക്രമീകരണം പ്രവർത്തനക്ഷമമാക്കി ഒരു റീബൂട്ടിന് ശേഷം ബാഹ്യ നിഘണ്ടു എടുക്കുന്നില്ല. എന്തുചെയ്യും?
ഞങ്ങൾ lazy_load ക്രമീകരണം പ്രവർത്തനക്ഷമമാക്കിയിട്ടുണ്ട്, സെർവർ റീബൂട്ട് ചെയ്തതിനുശേഷം, നിഘണ്ടു സ്വന്തമായി ലോഡ് ചെയ്യുന്നില്ല. ഉപയോക്താവ് ഈ നിഘണ്ടു ആക്സസ് ചെയ്തതിനുശേഷം മാത്രമേ ഇത് ഉയർത്തുകയുള്ളൂ. ആദ്യ ആക്‌സസിൽ അത് ഒരു പിശക് നൽകുന്നു. ClickHouse ഉപയോഗിച്ച് നിഘണ്ടുക്കൾ എങ്ങനെയെങ്കിലും സ്വയമേവ ലോഡുചെയ്യാൻ കഴിയുമോ, അതോ ഉപയോക്താക്കൾക്ക് പിശകുകൾ ലഭിക്കാതിരിക്കാൻ അവരുടെ സന്നദ്ധത നിങ്ങൾ സ്വയം നിയന്ത്രിക്കേണ്ടതുണ്ടോ?
ഒരുപക്ഷേ ക്ലിക്ക്ഹൗസിന്റെ പഴയ പതിപ്പ് ഞങ്ങളുടെ പക്കലുണ്ടാകാം, അതിനാൽ നിഘണ്ടു സ്വയമേവ ലോഡ് ചെയ്തില്ല. ഇതായിരിക്കുമോ?
ഒന്നാമതായി, ഒരു ചോദ്യം ഉപയോഗിച്ച് നിഘണ്ടുക്കൾ നിർബന്ധിതമായി ലോഡ് ചെയ്യാൻ കഴിയും സിസ്റ്റം റീലോഡ് നിഘണ്ടുക്കൾ. രണ്ടാമതായി, പിശകിനെക്കുറിച്ച് - നിഘണ്ടു ഇതിനകം ലോഡുചെയ്‌തിട്ടുണ്ടെങ്കിൽ, ലോഡുചെയ്‌ത ഡാറ്റയെ അടിസ്ഥാനമാക്കി അന്വേഷണങ്ങൾ പ്രവർത്തിക്കും. നിഘണ്ടു ഇതുവരെ ലോഡ് ചെയ്തിട്ടില്ലെങ്കിൽ, അഭ്യർത്ഥന സമയത്ത് അത് നേരിട്ട് ലോഡ് ചെയ്യും.
കനത്ത നിഘണ്ടുക്കൾക്ക് ഇത് വളരെ സൗകര്യപ്രദമല്ല. ഉദാഹരണത്തിന്, നിങ്ങൾ MySQL-ൽ നിന്ന് ഒരു ദശലക്ഷം വരികൾ വലിക്കേണ്ടതുണ്ട്. ആരോ ഒരു ലളിതമായ തിരഞ്ഞെടുപ്പ് നടത്തുന്നു, എന്നാൽ ഈ തിരഞ്ഞെടുത്തത് അതേ ദശലക്ഷം വരികൾക്കായി കാത്തിരിക്കും. ഇവിടെ രണ്ട് പരിഹാരങ്ങളുണ്ട്. ആദ്യത്തേത് lazy_load ഓഫ് ചെയ്യുക എന്നതാണ്. രണ്ടാമതായി, സെർവർ പ്രവർത്തനക്ഷമമാകുമ്പോൾ, അതിൽ ലോഡ് ഇടുന്നതിന് മുമ്പ്, ചെയ്യുക സിസ്റ്റം റീലോഡ് നിഘണ്ടു അല്ലെങ്കിൽ ഒരു നിഘണ്ടു ഉപയോഗിക്കുന്ന ഒരു അന്വേഷണം നടത്തുക. അപ്പോൾ നിഘണ്ടു ലോഡ് ചെയ്യും. Lazy_load ക്രമീകരണം പ്രവർത്തനക്ഷമമാക്കിയ നിഘണ്ടുക്കളുടെ ലഭ്യത നിങ്ങൾ നിയന്ത്രിക്കേണ്ടതുണ്ട്, കാരണം ClickHouse അവ സ്വയമേവ ലോഡ് ചെയ്യുന്നില്ല.
അവസാന ചോദ്യത്തിനുള്ള ഉത്തരം ഒന്നുകിൽ പതിപ്പ് പഴയതാണോ അല്ലെങ്കിൽ അത് ഡീബഗ്ഗ് ചെയ്യേണ്ടതുണ്ട്.
സിസ്റ്റം റീലോഡ് നിഘണ്ടുക്കളിൽ ഒരെണ്ണമെങ്കിലും ഒരു പിശകിനാൽ പരാജയപ്പെടുകയാണെങ്കിൽ അവയിൽ ഒന്നിനെയും ലോഡ് ചെയ്യുന്നില്ല എന്ന വസ്തുത എന്തുചെയ്യണം?
സിസ്റ്റം റീലോഡ് നിഘണ്ടുകളെക്കുറിച്ച് മറ്റൊരു ചോദ്യമുണ്ട്. ഞങ്ങൾക്ക് രണ്ട് നിഘണ്ടുകളുണ്ട് - ഒന്ന് ലോഡ് ചെയ്തിട്ടില്ല, രണ്ടാമത്തേത് ലോഡ് ചെയ്തു. ഈ സാഹചര്യത്തിൽ, സിസ്റ്റം റീലോഡ് നിഘണ്ടുക്കൾ ഒരു നിഘണ്ടുവും ലോഡ് ചെയ്യുന്നില്ല, കൂടാതെ സിസ്റ്റം റീലോഡ് നിഘണ്ടു ഉപയോഗിച്ച് അതിന്റെ പേരിൽ ഒരു നിർദ്ദിഷ്ട ഒന്ന് പോയിന്റ്-ബൈ-പോയിന്റ് ലോഡ് ചെയ്യണം. ഇതും ClickHouse പതിപ്പുമായി ബന്ധപ്പെട്ടതാണോ?
എനിക്ക് നിന്നെ സന്തോഷിപ്പിക്കണം. ഈ സ്വഭാവം മാറുകയായിരുന്നു. അതായത് ClickHouse അപ്ഡേറ്റ് ചെയ്താൽ അതും മാറും. നിങ്ങളുടെ നിലവിലെ പെരുമാറ്റത്തിൽ നിങ്ങൾക്ക് സന്തോഷമില്ലെങ്കിൽ സിസ്റ്റം റീലോഡ് നിഘണ്ടുക്കൾ, സ്വയം അപ്ഡേറ്റ് ചെയ്യുക, അത് മികച്ച രീതിയിൽ മാറുമെന്ന് നമുക്ക് പ്രതീക്ഷിക്കാം.
ClickHouse കോൺഫിഗറിൽ വിശദാംശങ്ങൾ കോൺഫിഗർ ചെയ്യുന്നതിന് എന്തെങ്കിലും വഴിയുണ്ടോ, എന്നാൽ പിശകുകളുടെ കാര്യത്തിൽ അവ പ്രദർശിപ്പിക്കരുത്?
അടുത്ത ചോദ്യം നിഘണ്ടുവുമായി ബന്ധപ്പെട്ട പിശകുകളെക്കുറിച്ചാണ്, അതായത് വിശദാംശങ്ങൾ. നിഘണ്ടുവിനായുള്ള ClickHouse കോൺഫിഗറേഷനിൽ ഞങ്ങൾ കണക്ഷൻ വിശദാംശങ്ങൾ വ്യക്തമാക്കിയിട്ടുണ്ട്, ഒരു പിശക് ഉണ്ടെങ്കിൽ, പ്രതികരണമായി ഈ വിശദാംശങ്ങളും പാസ്‌വേഡും ഞങ്ങൾക്ക് ലഭിക്കും.
ODBC ഡ്രൈവർ കോൺഫിഗറിലേക്ക് വിശദാംശങ്ങൾ ചേർത്തുകൊണ്ട് ഞങ്ങൾ ഈ പിശക് പരിഹരിച്ചു. ClickHouse കോൺഫിഗറിൽ വിശദാംശങ്ങൾ കോൺഫിഗർ ചെയ്യാൻ എന്തെങ്കിലും വഴിയുണ്ടോ, എന്നാൽ പിശകുകളുടെ കാര്യത്തിൽ ഈ വിശദാംശങ്ങൾ പ്രദർശിപ്പിക്കില്ലേ?
ഈ ക്രെഡൻഷ്യലുകൾ odbc.ini എന്നതിലും ക്ലിക്ക്ഹൗസിൽ തന്നെ ODBC ഡാറ്റാ ഉറവിട നാമം മാത്രം വ്യക്തമാക്കുക എന്നതാണ് ഇവിടെയുള്ള യഥാർത്ഥ പരിഹാരം. മറ്റ് നിഘണ്ടു സ്രോതസ്സുകൾക്ക് ഇത് സംഭവിക്കില്ല - MySQL ഉള്ള ഒരു നിഘണ്ടുവിനോ മറ്റുള്ളവർക്കോ, ഒരു പിശക് സന്ദേശം ലഭിക്കുമ്പോൾ നിങ്ങൾ പാസ്‌വേഡ് കാണരുത്. ODBC-യ്‌ക്കായി, ഞാനും നോക്കും - അത് നിലവിലുണ്ടെങ്കിൽ, നിങ്ങൾ അത് നീക്കം ചെയ്യേണ്ടതുണ്ട്.
ബോണസ്: ഒത്തുചേരലുകളിൽ നിന്നുള്ള പശ്ചാത്തലങ്ങൾ സൂം ചെയ്യുക
ചിത്രത്തിൽ ക്ലിക്കുചെയ്യുന്നതിലൂടെ, ഒത്തുചേരലുകളിൽ നിന്നുള്ള ബോണസ് പശ്ചാത്തലങ്ങൾ ഏറ്റവും സ്ഥിരതയുള്ള വായനക്കാർക്കായി തുറക്കും. Avito ടെക്നോളജി മാസ്കോട്ടുകൾക്കൊപ്പം ഞങ്ങൾ തീ അണച്ചു, സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്ററുടെ മുറിയിൽ നിന്നോ പഴയ സ്കൂൾ കമ്പ്യൂട്ടർ ക്ലബിൽ നിന്നോ സഹപ്രവർത്തകരുമായി ചർച്ച നടത്തുകയും ഗ്രാഫിറ്റിയുടെ പശ്ചാത്തലത്തിൽ പാലത്തിനടിയിൽ ദൈനംദിന മീറ്റിംഗുകൾ നടത്തുകയും ചെയ്യുന്നു.
അവലംബം: www.habr.com