ഉയർന്ന പ്രകടനവും നേറ്റീവ് പാർട്ടീഷനിംഗും: ടൈംസ്കെയിൽഡിബി പിന്തുണയുള്ള Zabbix

Zabbix ഒരു നിരീക്ഷണ സംവിധാനമാണ്. മറ്റേതൊരു സിസ്റ്റത്തെയും പോലെ, എല്ലാ മോണിറ്ററിംഗ് സിസ്റ്റങ്ങളുടെയും മൂന്ന് പ്രധാന പ്രശ്നങ്ങൾ ഇത് അഭിമുഖീകരിക്കുന്നു: ഡാറ്റ ശേഖരിക്കുകയും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുക, ചരിത്രം സംഭരിക്കുക, വൃത്തിയാക്കുക.

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

Zabbix-ലെ ശേഖരണത്തിലും സംഭരണത്തിലും കാലതാമസം നേരിടുന്ന പ്രശ്‌നങ്ങൾ കാഷെ ചെയ്യുന്നതിലൂടെ പരിഹരിക്കപ്പെടുന്നു: നിരവധി തരം കാഷെകൾ, ഡാറ്റാബേസിൽ കാഷെ ചെയ്യൽ. മൂന്നാമത്തെ പ്രശ്നം പരിഹരിക്കാൻ, കാഷിംഗ് അനുയോജ്യമല്ല, അതിനാൽ Zabbix TimescaleDB ഉപയോഗിച്ചു. അവൻ അതിനെക്കുറിച്ച് നിങ്ങളോട് പറയും ആന്ദ്രേ ഗുഷ്ചിൻ - സാങ്കേതിക പിന്തുണ എഞ്ചിനീയർ Zabbix SIA. ആൻഡ്രി 6 വർഷത്തിലേറെയായി Zabbix-നെ പിന്തുണയ്ക്കുന്നു കൂടാതെ പ്രകടനത്തിൽ നേരിട്ടുള്ള അനുഭവവുമുണ്ട്.

TimescaleDB എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്, സാധാരണ PostgreSQL നെ അപേക്ഷിച്ച് ഇതിന് എന്ത് പ്രകടനമാണ് നൽകാൻ കഴിയുക? TimescaleDB ഡാറ്റാബേസിനായി Zabbix എന്ത് പങ്കാണ് വഹിക്കുന്നത്? ആദ്യം മുതൽ എങ്ങനെ ആരംഭിക്കാം, PostgreSQL-ൽ നിന്ന് എങ്ങനെ മൈഗ്രേറ്റ് ചെയ്യാം, ഏത് കോൺഫിഗറേഷനാണ് മികച്ച പ്രകടനം ഉള്ളത്? കട്ട് കീഴിൽ എല്ലാ ഇതിനെക്കുറിച്ച്.

ഉൽപ്പാദനക്ഷമത വെല്ലുവിളികൾ

ഓരോ മോണിറ്ററിംഗ് സിസ്റ്റവും നിർദ്ദിഷ്ട പ്രകടന വെല്ലുവിളികൾ അഭിമുഖീകരിക്കുന്നു. അവയിൽ മൂന്നെണ്ണത്തെക്കുറിച്ച് ഞാൻ സംസാരിക്കും: ഡാറ്റ ശേഖരണവും പ്രോസസ്സിംഗും, സംഭരണവും, ചരിത്ര മായ്ക്കലും.

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

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

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

കാലഹരണപ്പെട്ട ഡാറ്റ വൃത്തിയാക്കുന്നത് ഡാറ്റാബേസ് പ്രകടനത്തെ വളരെയധികം ബാധിക്കുന്ന ഒരു നിർണായക പ്രശ്നമാണ്.

Zabbix-ൽ കാഷെ ചെയ്യുന്നു

Zabbix-ൽ, ആദ്യത്തെയും രണ്ടാമത്തെയും കോളുകൾ കാഷിംഗ് ഉപയോഗിച്ച് പരിഹരിക്കുന്നു. ഡാറ്റ ശേഖരിക്കാനും പ്രോസസ്സ് ചെയ്യാനും റാം ഉപയോഗിക്കുന്നു. സംഭരണത്തിനായി - ട്രിഗറുകൾ, ഗ്രാഫുകൾ, കണക്കാക്കിയ ഡാറ്റ ഘടകങ്ങൾ എന്നിവയിലെ ചരിത്രം. ഡാറ്റാബേസ് വശത്ത് അടിസ്ഥാന തിരഞ്ഞെടുപ്പുകൾക്കായി ചില കാഷിംഗ് ഉണ്ട്, ഉദാഹരണത്തിന്, ഗ്രാഫുകൾ.

Zabbix സെർവറിന്റെ വശത്ത് കാഷെ ചെയ്യുന്നത് ഇതാണ്:

• കോൺഫിഗറേഷൻ കാഷെ;
• ValueCache;
• ഹിസ്റ്ററി കാഷെ;
• ട്രെൻഡ് കാഷെ.

അവരെക്കുറിച്ച് കൂടുതൽ വിശദമായി ചിന്തിക്കുക.

കോൺഫിഗറേഷൻ കാഷെ

മെട്രിക്‌സ്, ഹോസ്റ്റുകൾ, ഡാറ്റാ ഇനങ്ങൾ, ട്രിഗറുകൾ - പ്രീപ്രോസസ്സിംഗിനും ഡാറ്റ ശേഖരണത്തിനും ആവശ്യമായ എല്ലാം ഞങ്ങൾ സംഭരിക്കുന്ന പ്രധാന കാഷെയാണിത്.

ഡാറ്റാബേസിൽ അനാവശ്യ ചോദ്യങ്ങൾ സൃഷ്ടിക്കാതിരിക്കാൻ ഇതെല്ലാം കോൺഫിഗറേഷൻ കാഷിൽ സംഭരിച്ചിരിക്കുന്നു. സെർവർ ആരംഭിച്ചതിന് ശേഷം, ഞങ്ങൾ ഈ കാഷെ അപ്ഡേറ്റ് ചെയ്യുകയും കോൺഫിഗറേഷനുകൾ സൃഷ്ടിക്കുകയും കാലാനുസൃതമായി അപ്ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു.

ഡാറ്റ ശേഖരണം

ഡയഗ്രം വളരെ വലുതാണ്, പക്ഷേ അതിലെ പ്രധാന കാര്യം പിക്കറുകൾ. ഇവ വിവിധ "പോളറുകൾ" ആണ് - അസംബ്ലി പ്രക്രിയകൾ. വ്യത്യസ്ത തരം അസംബ്ലികൾക്ക് അവർ ഉത്തരവാദികളാണ്: അവർ എസ്എൻഎംപി, ഐപിഎംഐ വഴി ഡാറ്റ ശേഖരിക്കുകയും പ്രീപ്രോസസിംഗിലേക്ക് എല്ലാം കൈമാറുകയും ചെയ്യുന്നു.

കളക്ടർമാർ ഓറഞ്ച് നിറത്തിലാണ് നൽകിയിരിക്കുന്നത്.

പരിശോധനകൾ സമാഹരിക്കാൻ ആവശ്യമായ അഗ്രഗേഷൻ ഇനങ്ങൾ Zabbix കണക്കാക്കിയിട്ടുണ്ട്. ഞങ്ങളുടെ പക്കൽ അവയുണ്ടെങ്കിൽ, ValueCache-ൽ നിന്ന് അവർക്കുള്ള ഡാറ്റ ഞങ്ങൾ നേരിട്ട് ലഭ്യമാക്കും.

ഹിസ്റ്ററി കാഷെ പ്രീപ്രോസസ് ചെയ്യുന്നു

ജോലികൾ ലഭിക്കുന്നതിന് എല്ലാ കളക്ടർമാരും കോൺഫിഗറേഷൻ കാഷെ ഉപയോഗിക്കുന്നു. തുടർന്ന് അവ പ്രീപ്രോസസിംഗിലേക്ക് മാറ്റുന്നു.

പ്രീപ്രോസസിംഗ് ഘട്ടങ്ങൾ സ്വീകരിക്കുന്നതിന്, പ്രീപ്രോസസിംഗ് കോൺഫിഗറേഷൻ കാഷെ ഉപയോഗിക്കുന്നു. ഇത് വിവിധ രീതികളിൽ ഈ ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നു.

പ്രീപ്രോസസിംഗ് ഉപയോഗിച്ച് ഡാറ്റ പ്രോസസ്സ് ചെയ്ത ശേഷം, പ്രോസസ്സിംഗിനായി ഞങ്ങൾ അത് ഹിസ്റ്ററികാഷിൽ സംരക്ഷിക്കുന്നു. ഇത് ഡാറ്റാ ശേഖരണം അവസാനിപ്പിക്കുന്നു, ഞങ്ങൾ Zabbix-ലെ പ്രധാന പ്രക്രിയയിലേക്ക് നീങ്ങുന്നു - ചരിത്ര സമന്വയം, ഇത് ഒരു ഏകശിലാ വാസ്തുവിദ്യയായതിനാൽ.

ശ്രദ്ധിക്കുക: പ്രീപ്രോസസിംഗ് വളരെ ബുദ്ധിമുട്ടുള്ള ഒരു പ്രവർത്തനമാണ്. വി 4.2 ഉപയോഗിച്ച് ഇത് പ്രോക്സിയിലേക്ക് നീക്കി. നിങ്ങൾക്ക് ധാരാളം ഡാറ്റ ഘടകങ്ങളും ശേഖരണ ആവൃത്തിയും ഉള്ള വളരെ വലിയ Zabbix ഉണ്ടെങ്കിൽ, ഇത് ജോലി വളരെ എളുപ്പമാക്കുന്നു.

ValueCache, ചരിത്രം & ട്രെൻഡ് കാഷെ

ഓരോ ഡാറ്റാ ഘടകവും, അതായത് ഓരോ മൂല്യവും അറ്റോമികമായി പ്രോസസ്സ് ചെയ്യുന്ന പ്രധാന പ്രക്രിയയാണ് ഹിസ്റ്ററി സിൻസർ.

ഹിസ്റ്ററി സിൻസർ ഹിസ്റ്ററികാഷിൽ നിന്ന് മൂല്യങ്ങൾ എടുക്കുകയും കണക്കുകൂട്ടലുകൾക്കായുള്ള ട്രിഗറുകളുടെ സാന്നിധ്യത്തിനായി കോൺഫിഗറേഷൻ പരിശോധിക്കുകയും ചെയ്യുന്നു. അവ നിലവിലുണ്ടെങ്കിൽ, അത് കണക്കാക്കുന്നു.

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

ഹിസ്റ്ററി സിൻസർ എല്ലാ ഡാറ്റയും ഡാറ്റാബേസിലേക്ക് എഴുതുന്നു, അത് ഡിസ്കിലേക്ക് എഴുതുന്നു. പ്രോസസ്സിംഗ് പ്രക്രിയ ഇവിടെ അവസാനിക്കുന്നു.

ഡാറ്റാബേസിൽ കാഷെ ചെയ്യുന്നു

ഇവന്റുകളെക്കുറിച്ചുള്ള ഗ്രാഫുകളോ റിപ്പോർട്ടുകളോ കാണണമെങ്കിൽ ഡാറ്റാബേസ് വശത്ത് വിവിധ കാഷെകൾ ഉണ്ട്:

• Innodb_buffer_pool MySQL വശത്ത്;
• shared_buffers PostgreSQL വശത്ത്;
• effective_cache_size ഒറാക്കിൾ ഭാഗത്ത്;
• shared_pool DB2 വശത്ത്.

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

ഡാറ്റാബേസ് പ്രകടനം നിർണായകമാണ്

Zabbix സെർവർ നിരന്തരം ഡാറ്റ ശേഖരിക്കുകയും അത് എഴുതുകയും ചെയ്യുന്നു. പുനരാരംഭിക്കുമ്പോൾ, ValueCache പൂരിപ്പിക്കുന്നതിന് അത് ചരിത്രത്തിൽ നിന്ന് വായിക്കുകയും ചെയ്യുന്നു. സ്ക്രിപ്റ്റുകളും റിപ്പോർട്ടുകളും ഉപയോഗിക്കുന്നു Zabbix API, ഇത് ഒരു വെബ് ഇന്റർഫേസിൽ നിർമ്മിച്ചതാണ്. Zabbix API ഡാറ്റാബേസ് ആക്സസ് ചെയ്യുകയും ഗ്രാഫുകൾ, റിപ്പോർട്ടുകൾ, ഇവന്റ് ലിസ്റ്റുകൾ, ഏറ്റവും പുതിയ പ്രശ്നങ്ങൾ എന്നിവയ്ക്ക് ആവശ്യമായ ഡാറ്റ വീണ്ടെടുക്കുകയും ചെയ്യുന്നു.

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

വീട്ടുജോലിക്കാരി

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

ഞങ്ങൾ TrendsCache കണക്കാക്കുന്നു. ഡാറ്റ വരുമ്പോൾ, ട്രെൻഡ് മാറ്റങ്ങളുടെ ചലനാത്മകതയ്ക്കായി ഞങ്ങൾ അത് ഒരു മണിക്കൂർ സമാഹരിച്ച് പട്ടികകളിൽ രേഖപ്പെടുത്തുന്നു.

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

ഹിസ്റ്ററി സിൻസർ നിരന്തരം തിരക്കിലാണെന്ന് ചുവന്ന ഗ്രാഫ് കാണിക്കുന്നു. മുകളിലെ ഓറഞ്ച് ഗ്രാഫ് ഹൗസ് കീപ്പർ ആണ്, അത് നിരന്തരം പ്രവർത്തിക്കുന്നു. അവൻ വ്യക്തമാക്കിയ എല്ലാ വരികളും ഇല്ലാതാക്കാൻ ഡാറ്റാബേസ് കാത്തിരിക്കുന്നു.

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

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

വീട്ടുജോലിക്കാരനെ ഓഫാക്കി, ഗ്രാഫുകൾ നിരത്തി - ഈ സാഹചര്യത്തിൽ എന്ത് പ്രശ്‌നങ്ങളുണ്ടാകാം, മൂന്നാമത്തെ പ്രകടന വെല്ലുവിളി പരിഹരിക്കാൻ എന്താണ് സഹായിക്കുക?

വിഭജനം - വിഭജനം അല്ലെങ്കിൽ വിഭജനം

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

സാധാരണയായി, പാർട്ടീഷനുകൾ ക്രമീകരിച്ചിരിക്കുന്നത് "സെറ്റപ്പ്" - ഒരു ദിവസത്തിൽ സൃഷ്ടിക്കുന്ന ഡാറ്റയുടെ അളവ് അനുസരിച്ച്. ചട്ടം പോലെ, പാർട്ടീഷനിംഗ് ഒരു ദിവസത്തിനുള്ളിൽ ഇഷ്യു ചെയ്യുന്നു, ഇതാണ് ഏറ്റവും കുറഞ്ഞത്. ഒരു പുതിയ ബാച്ചിന്റെ ട്രെൻഡുകൾക്കായി - 1 മാസം.

"സജ്ജീകരണം" വളരെ വലുതാണെങ്കിൽ മൂല്യങ്ങൾ മാറിയേക്കാം. ഒരു ചെറിയ "സെറ്റപ്പ്" 5 nvps (സെക്കൻഡിൽ പുതിയ മൂല്യങ്ങൾ) വരെ ആണെങ്കിൽ, ഇടത്തരം ഒന്ന് 000 മുതൽ 5 വരെയാണ്, പിന്നെ വലിയത് 000 nvps-ന് മുകളിലാണ്. ഡാറ്റാബേസിന്റെ ശ്രദ്ധാപൂർവ്വമായ കോൺഫിഗറേഷൻ ആവശ്യമുള്ള വലുതും വളരെ വലുതുമായ ഇൻസ്റ്റാളേഷനുകളാണിവ.

വളരെ വലിയ ഇൻസ്റ്റാളേഷനുകളിൽ, ഒരു ദിവസത്തെ കാലയളവ് അനുയോജ്യമല്ലായിരിക്കാം. പ്രതിദിനം 40 GB അല്ലെങ്കിൽ അതിൽ കൂടുതലുള്ള MySQL പാർട്ടീഷനുകൾ ഞാൻ കണ്ടിട്ടുണ്ട്. ഇത് വളരെ വലിയ അളവിലുള്ള ഡാറ്റയാണ്, അത് പ്രശ്‌നങ്ങൾ ഉണ്ടാക്കുകയും അത് കുറയ്ക്കുകയും വേണം.

വിഭജനം എന്താണ് നൽകുന്നത്?

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

ദ്രുത നീക്കം - DELETE. ഇല്ലാതാക്കുന്നതിനുള്ള വരികളുടെ തിരഞ്ഞെടുപ്പിന് പകരം ഒരു ഫയൽ/സബ്‌ടേബിൾ തിരഞ്ഞെടുത്തു.

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

പലപ്പോഴും പല ഡാറ്റാബേസുകളും ത്വരിതപ്പെടുത്തുന്നു INSERT - ചൈൽഡ് ടേബിളിൽ ഉൾപ്പെടുത്തലുകൾ.

ടൈംസ്‌കെയിൽഡിബി

വി 4.2-ന്, ഞങ്ങൾ ടൈംസ്കെയിൽഡിബിയിലേക്ക് ശ്രദ്ധ തിരിച്ചു. നേറ്റീവ് ഇന്റർഫേസുള്ള PostgreSQL-നുള്ള ഒരു വിപുലീകരണമാണിത്. റിലേഷണൽ ഡാറ്റാബേസുകളുടെ പ്രയോജനങ്ങൾ നഷ്‌ടപ്പെടാതെ, സമയ ശ്രേണി ഡാറ്റയ്‌ക്കൊപ്പം വിപുലീകരണം ഫലപ്രദമായി പ്രവർത്തിക്കുന്നു. TimescaleDB-യും സ്വയമേവ പാർട്ടീഷൻ ചെയ്യുന്നു.

TimescaleDB-ന് ഒരു ആശയമുണ്ട് ഹൈപ്പർടേബിൾ (ഹൈപ്പർടേബിൾ) നിങ്ങൾ സൃഷ്ടിക്കുന്നത്. അതിൽ അടങ്ങിയിരിക്കുന്നു കഷണങ്ങൾ - പാർട്ടീഷനുകൾ. മറ്റ് ശകലങ്ങളെ ബാധിക്കാത്ത ഹൈപ്പർടേബിൾ ശകലങ്ങളാണ് ചങ്കുകൾ സ്വയമേവ കൈകാര്യം ചെയ്യുന്നത്. ഓരോ ഭാഗത്തിനും അതിന്റേതായ സമയപരിധിയുണ്ട്.

TimescaleDB vs PostgreSQL

TimescaleDB ശരിക്കും കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നു. വിപുലീകരണത്തിന്റെ നിർമ്മാതാക്കൾ അവർ കൂടുതൽ ശരിയായ അന്വേഷണ പ്രോസസ്സിംഗ് അൽഗോരിതം ഉപയോഗിക്കുന്നതായി അവകാശപ്പെടുന്നു, പ്രത്യേകിച്ചും inserts . ഡാറ്റാസെറ്റ് ഉൾപ്പെടുത്തൽ വലുപ്പം വർദ്ധിക്കുന്നതിനനുസരിച്ച്, അൽഗോരിതം സ്ഥിരമായ പ്രകടനം നിലനിർത്തുന്നു.

200 ദശലക്ഷം വരികൾക്ക് ശേഷം, PostgreSQL സാധാരണയായി ഗണ്യമായി കുറയാൻ തുടങ്ങുകയും പ്രകടനം 0 ആയി കുറയുകയും ചെയ്യും. ടൈംസ്‌കെയിൽDB ഏത് ഡാറ്റയ്ക്കും "ഇൻസേർട്ടുകൾ" കാര്യക്ഷമമായി ചേർക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ഇൻസ്റ്റലേഷൻ

TimescaleDB ഇൻസ്റ്റാൾ ചെയ്യുന്നത് ഏത് പാക്കേജിനും വളരെ എളുപ്പമാണ്. IN പ്രമാണീകരണം എല്ലാം വിശദമായി വിവരിച്ചിരിക്കുന്നു - ഇത് ഔദ്യോഗിക PostgreSQL പാക്കേജുകളെ ആശ്രയിച്ചിരിക്കുന്നു. TimescaleDB സ്വമേധയാ നിർമ്മിക്കാനും സമാഹരിക്കാനും കഴിയും.

Zabbix ഡാറ്റാബേസിനായി ഞങ്ങൾ വിപുലീകരണം സജീവമാക്കുന്നു:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

നിങ്ങൾ സജീവമാക്കുക extension Zabbix ഡാറ്റാബേസിനായി ഇത് സൃഷ്ടിക്കുക. അവസാന ഘട്ടം ഒരു ഹൈപ്പർടേബിൾ ഉണ്ടാക്കുക എന്നതാണ്.

ചരിത്ര പട്ടികകൾ TimescaleDB-ലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നു

ഇതിനായി ഒരു പ്രത്യേക പ്രവർത്തനമുണ്ട് create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

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

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

അവസാന ഘട്ടം - UPDATE: at db_extension ഇട്ടു timescaledbഈ വിപുലീകരണം നിലവിലുണ്ടെന്ന് ഡാറ്റാബേസ് മനസ്സിലാക്കുന്നു. Zabbix അത് സജീവമാക്കുകയും ഡാറ്റാബേസിലേക്കുള്ള വാക്യഘടനയും അന്വേഷണങ്ങളും ശരിയായി ഉപയോഗിക്കുകയും ചെയ്യുന്നു - TimescaleDB-ന് ആവശ്യമായ സവിശേഷതകൾ.

ഹാർഡ്‌വെയർ കോൺഫിഗറേഷൻ

ഞാൻ രണ്ട് സെർവറുകൾ ഉപയോഗിച്ചു. ആദ്യം - വിഎംവെയർ മെഷീൻ. ഇത് വളരെ ചെറുതാണ്: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz പ്രൊസസറുകൾ, 16 GB റാമും 200 GB SSD-യും.

Debian 10.8-10.8.pgdg1+90 OS, xfs ഫയൽ സിസ്റ്റം എന്നിവയിൽ ഞാൻ PostgreSQL 1 ഇൻസ്റ്റാൾ ചെയ്തു. ഈ പ്രത്യേക ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നതിന് ഞാൻ എല്ലാം ചുരുങ്ങിയത് ക്രമീകരിച്ചു, Zabbix തന്നെ ഉപയോഗിക്കുന്നതിൽ നിന്ന് കുറവ്.

അതേ മെഷീനിൽ ഒരു Zabbix സെർവർ ഉണ്ടായിരുന്നു, PostgreSQL ഒപ്പം ലോഡ് ഏജന്റുകൾ. എനിക്ക് ഉപയോഗിക്കുന്ന 50 സജീവ ഏജന്റുമാരുണ്ടായിരുന്നു LoadableModuleവളരെ വേഗത്തിൽ വ്യത്യസ്ത ഫലങ്ങൾ സൃഷ്ടിക്കുന്നതിന്: അക്കങ്ങൾ, സ്ട്രിംഗുകൾ. ഞാൻ ധാരാളം ഡാറ്റ ഉപയോഗിച്ച് ഡാറ്റാബേസ് നിറച്ചു.

തുടക്കത്തിൽ കോൺഫിഗറേഷൻ അടങ്ങിയിരിക്കുന്നു 5 ഘടകങ്ങൾ ഓരോ ഹോസ്റ്റിനും ഡാറ്റ. മിക്കവാറും എല്ലാ ഘടകങ്ങളിലും യഥാർത്ഥ ഇൻസ്റ്റാളേഷനുകൾക്ക് സമാനമായ ഒരു ട്രിഗർ അടങ്ങിയിരിക്കുന്നു. ചില സന്ദർഭങ്ങളിൽ ഒന്നിലധികം ട്രിഗറുകൾ ഉണ്ടായിരുന്നു. ഒരു നെറ്റ്‌വർക്ക് നോഡിനായി ഉണ്ടായിരുന്നു 3-000 ട്രിഗറുകൾ.

ഡാറ്റ ഇനം അപ്ഡേറ്റ് ഇടവേള - 4-7 സെക്കൻഡ്. 50 ഏജന്റുമാരെ മാത്രമല്ല, കൂടുതൽ ചേർത്തുകൊണ്ട് ഞാൻ ലോഡ് തന്നെ നിയന്ത്രിച്ചു. കൂടാതെ, ഡാറ്റ ഘടകങ്ങൾ ഉപയോഗിച്ച്, ഞാൻ ചലനാത്മകമായി ലോഡ് ക്രമീകരിക്കുകയും അപ്‌ഡേറ്റ് ഇടവേള 4 സെക്കൻഡായി കുറയ്ക്കുകയും ചെയ്തു.

PostgreSQL. 35 എൻവിപിഎസ്

ഈ ഹാർഡ്‌വെയറിലെ എന്റെ ആദ്യ ഓട്ടം ശുദ്ധമായ PostgreSQL-ൽ ആയിരുന്നു - സെക്കൻഡിൽ 35 ആയിരം മൂല്യങ്ങൾ. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഡാറ്റ ചേർക്കുന്നത് ഒരു സെക്കൻഡിന്റെ ഭിന്നസംഖ്യകൾ എടുക്കും - എല്ലാം നല്ലതും വേഗതയുള്ളതുമാണ്. ഒരേയൊരു കാര്യം 200 ജിബി എസ്എസ്ഡി ഡിസ്ക് വേഗത്തിൽ നിറയുന്നു എന്നതാണ്.

ഇതൊരു സാധാരണ Zabbix സെർവർ പ്രകടന ഡാഷ്‌ബോർഡാണ്.

ആദ്യത്തെ നീല ഗ്രാഫ് സെക്കൻഡിലെ മൂല്യങ്ങളുടെ എണ്ണമാണ്. വലതുവശത്തുള്ള രണ്ടാമത്തെ ഗ്രാഫ് ബിൽഡ് പ്രോസസുകളുടെ ലോഡിംഗ് ആണ്. മൂന്നാമത്തേത് ഇന്റേണൽ ബിൽഡ് പ്രോസസുകൾ ലോഡ് ചെയ്യുന്നു: ഹിസ്റ്ററി സിൻസർ, ഹൗസ്‌കീപ്പർ, ഇത് കുറച്ച് കാലമായി ഇവിടെ പ്രവർത്തിക്കുന്നു.

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

PostgreSQL. 50 എൻവിപിഎസ്

അതേ ഹാർഡ്‌വെയറിൽ ഞാൻ ലോഡ് സെക്കൻഡിൽ 50 ആയിരം മൂല്യങ്ങളായി വർദ്ധിപ്പിച്ചു.

ഹൗസ്‌കീപ്പറിൽ നിന്ന് ലോഡുചെയ്യുമ്പോൾ, 10 ആയിരം മൂല്യങ്ങൾ ചേർക്കാൻ 2-3 സെക്കൻഡ് എടുത്തു.

വീട്ടുജോലിക്കാരൻ ഇതിനകം ജോലിയിൽ ഇടപെടാൻ തുടങ്ങിയിരിക്കുന്നു.

മൂന്നാമത്തെ ഗ്രാഫ് കാണിക്കുന്നത്, പൊതുവേ, ട്രാപ്പർമാരുടെയും ഹിസ്റ്ററി സിൻചറുകളുടെയും ലോഡ് ഇപ്പോഴും 60% ആണ്. നാലാമത്തെ ഗ്രാഫിൽ, ഹൗസ്‌കീപ്പർ ഓപ്പറേഷൻ സമയത്ത് ഹിസ്റ്ററി കാഷെ ഇതിനകം തന്നെ സജീവമായി പൂരിപ്പിക്കാൻ തുടങ്ങിയിരിക്കുന്നു. ഇത് 20% നിറഞ്ഞിരിക്കുന്നു, അതായത് ഏകദേശം 0,5 GB.

PostgreSQL. 80 എൻവിപിഎസ്

അപ്പോൾ ഞാൻ ലോഡ് സെക്കൻഡിൽ 80 ആയിരം മൂല്യങ്ങളായി വർദ്ധിപ്പിച്ചു. ഇത് ഏകദേശം 400 ആയിരം ഡാറ്റ ഘടകങ്ങളും 280 ആയിരം ട്രിഗറുകളും ആണ്.

മുപ്പത് ഹിസ്റ്ററി സിൻചറുകളുടെ ലോഡിംഗ് ചെലവ് ഇതിനകം തന്നെ വളരെ ഉയർന്നതാണ്.

ഞാൻ വിവിധ പാരാമീറ്ററുകളും വർദ്ധിപ്പിച്ചു: ചരിത്ര സമന്വയം, കാഷെകൾ.

എന്റെ ഹാർഡ്‌വെയറിൽ, ഹിസ്റ്ററി സിൻസർ ലോഡിംഗ് പരമാവധി വർദ്ധിച്ചു. ഹിസ്റ്ററികാഷിൽ ഡാറ്റ വേഗത്തിൽ നിറഞ്ഞു - പ്രോസസ്സിംഗിനുള്ള ഡാറ്റ ബഫറിൽ ശേഖരിച്ചു.

ഇക്കാലമത്രയും പ്രോസസർ, റാം, മറ്റ് സിസ്റ്റം പാരാമീറ്ററുകൾ എന്നിവ എങ്ങനെ ഉപയോഗിച്ചുവെന്ന് ഞാൻ നിരീക്ഷിച്ചു, കൂടാതെ ഡിസ്ക് ഉപയോഗം പരമാവധി ആണെന്ന് കണ്ടെത്തി.

ഞാൻ ഉപയോഗം കൈവരിച്ചു പരമാവധി ഡിസ്ക് കഴിവുകൾ ഈ ഹാർഡ്‌വെയറിലും ഈ വെർച്വൽ മെഷീനിലും. അത്തരം തീവ്രതയോടെ, PostgreSQL വളരെ സജീവമായി ഡാറ്റ ഫ്ലഷ് ചെയ്യാൻ തുടങ്ങി, കൂടാതെ ഡിസ്കിന് എഴുതാനും വായിക്കാനും സമയമില്ല.

രണ്ടാമത്തെ സെർവർ

ഞാൻ മറ്റൊരു സെർവർ എടുത്തു, അതിൽ ഇതിനകം 48 പ്രോസസറുകളും 128 ജിബി റാമും ഉണ്ടായിരുന്നു. ഞാൻ അത് ട്യൂൺ ചെയ്തു - 60 ഹിസ്റ്ററി സിൻസർ ആയി സജ്ജമാക്കി, സ്വീകാര്യമായ പ്രകടനം കൈവരിച്ചു.

വാസ്തവത്തിൽ, ഇത് ഇതിനകം എന്തെങ്കിലും ചെയ്യേണ്ട ഉൽപാദനക്ഷമതയുടെ പരിധിയാണ്.

ടൈംസ്കെയിൽDB. 80 എൻവിപിഎസ്

എന്റെ പ്രധാന ദൌത്യം Zabbix ലോഡിനെതിരെ TimescaleDB യുടെ കഴിവുകൾ പരീക്ഷിക്കുക എന്നതാണ്. സെക്കൻഡിൽ 80 ആയിരം മൂല്യങ്ങൾ ധാരാളം, അളവുകൾ ശേഖരിക്കുന്നതിന്റെ ആവൃത്തിയും (തീർച്ചയായും Yandex ഒഴികെ) ഒരു വലിയ "സജ്ജീകരണവും".

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

ടൈംസ്‌കെയിൽഡിബി നിങ്ങളെ ഏകദേശം 3 മടങ്ങ് വേഗത്തിൽ ഡാറ്റ ചേർക്കാനും കുറച്ച് ഹിസ്റ്ററി കാഷെ ഉപയോഗിക്കാനും അനുവദിക്കുന്നു.

അതനുസരിച്ച്, നിങ്ങൾക്ക് സമയബന്ധിതമായി ഡാറ്റ ലഭിക്കും.

ടൈംസ്കെയിൽDB. 120 എൻവിപിഎസ്

തുടർന്ന് ഞാൻ ഡാറ്റ ഘടകങ്ങളുടെ എണ്ണം 500 ആയിരമായി വർദ്ധിപ്പിച്ചു. ടൈംസ്‌കെയിൽ ഡിബിയുടെ കഴിവുകൾ പരീക്ഷിക്കുക എന്നതായിരുന്നു പ്രധാന ദൌത്യം - എനിക്ക് സെക്കൻഡിൽ 125 ആയിരം മൂല്യങ്ങൾ കണക്കാക്കിയ മൂല്യം ലഭിച്ചു.

ഇത് വളരെക്കാലം പ്രവർത്തിക്കാൻ കഴിയുന്ന ഒരു പ്രവർത്തിക്കുന്ന "സെറ്റപ്പ്" ആണ്. എന്നാൽ എന്റെ ഡിസ്ക് 1,5 TB മാത്രമായിരുന്നതിനാൽ, രണ്ടു ദിവസം കൊണ്ട് ഞാൻ അത് നിറച്ചു.

ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം, അതേ സമയം പുതിയ ടൈംസ്കെയിൽഡിബി പാർട്ടീഷനുകൾ സൃഷ്ടിക്കപ്പെട്ടു എന്നതാണ്.

പ്രകടനത്തിന് ഇത് പൂർണ്ണമായും അദൃശ്യമാണ്. MySQL-ൽ പാർട്ടീഷനുകൾ സൃഷ്ടിക്കുമ്പോൾ, ഉദാഹരണത്തിന്, എല്ലാം വ്യത്യസ്തമാണ്. ഇത് സാധാരണയായി രാത്രിയിൽ സംഭവിക്കുന്നു, കാരണം ഇത് പൊതുവായ ഉൾപ്പെടുത്തലിനെ തടയുന്നു, ടേബിളുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്നു, കൂടാതെ സേവന നിലവാരത്തകർച്ച സൃഷ്ടിക്കുകയും ചെയ്യും. ഇത് TimescaleDB യുടെ കാര്യമല്ല.

ഒരു ഉദാഹരണമായി, കമ്മ്യൂണിറ്റിയിലെ പലരിൽ നിന്നും ഒരു ഗ്രാഫ് ഞാൻ കാണിക്കും. ചിത്രത്തിൽ, TimescaleDB പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു, ഇതിന് നന്ദി, പ്രോസസറിൽ io.weight ഉപയോഗിക്കുന്നതിനുള്ള ലോഡ് കുറഞ്ഞു. ആന്തരിക പ്രക്രിയ ഘടകങ്ങളുടെ ഉപയോഗവും കുറഞ്ഞു. മാത്രമല്ല, ഇത് സാധാരണ പാൻകേക്ക് ഡിസ്കുകളിലെ ഒരു സാധാരണ വെർച്വൽ മെഷീനാണ്, ഒരു എസ്എസ്ഡി അല്ല.

കണ്ടെത്തലുകൾ

ചെറിയ "സജ്ജീകരണ"ത്തിനുള്ള നല്ലൊരു പരിഹാരമാണ് TimescaleDB, ഇത് ഡിസ്കിന്റെ പ്രകടനത്തെ ബാധിക്കുന്നു. ഡാറ്റാബേസ് കഴിയുന്നത്ര വേഗത്തിൽ ഹാർഡ്‌വെയറിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുന്നതുവരെ നന്നായി പ്രവർത്തിക്കുന്നത് തുടരാൻ ഇത് നിങ്ങളെ അനുവദിക്കും.

TimescaleDB കോൺഫിഗർ ചെയ്യാൻ എളുപ്പമാണ്, പ്രകടന നേട്ടങ്ങൾ നൽകുന്നു, Zabbix-നൊപ്പം നന്നായി പ്രവർത്തിക്കുന്നു PostgreSQL-നേക്കാൾ ഗുണങ്ങളുണ്ട്.

നിങ്ങൾ PostgreSQL ഉപയോഗിക്കുകയും അത് മാറ്റാൻ ഉദ്ദേശിക്കുന്നില്ലെങ്കിൽ, ഞാൻ ശുപാർശ ചെയ്യുന്നു Zabbix-നൊപ്പം TimescaleDB വിപുലീകരണത്തിനൊപ്പം PostgreSQL ഉപയോഗിക്കുക. ഈ പരിഹാരം ഒരു മീഡിയം "സെറ്റപ്പ്" വരെ ഫലപ്രദമായി പ്രവർത്തിക്കുന്നു.

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

ഞങ്ങളുടെ സബ്സ്ക്രൈബ് ചെയ്യുക лкуылку и ടെലഗ്രാം, വരാനിരിക്കുന്ന കോൺഫറൻസിന്റെ സവിശേഷതകൾ ഞങ്ങൾ വെളിപ്പെടുത്തുന്നു, അതിൽ നിന്ന് പരമാവധി പ്രയോജനപ്പെടുത്തുന്നത് എങ്ങനെയെന്ന് കണ്ടെത്തുക.

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