HighLoad++, Andrey Gushchin (Zabbix): ഉയർന്ന പ്രകടനവും നേറ്റീവ് പാർട്ടീഷനിംഗും

ടൈംസ്‌കെയിൽ ഡിബി ഡാറ്റാബേസുമായി സബ്ബിക്‌സ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾ നോക്കും. ആദ്യം മുതൽ എങ്ങനെ ആരംഭിക്കാമെന്നും PostgreSQL-ൽ നിന്ന് എങ്ങനെ മൈഗ്രേറ്റ് ചെയ്യാമെന്നും ഞങ്ങൾ നിങ്ങളെ കാണിച്ചുതരാം. രണ്ട് കോൺഫിഗറേഷനുകളുടെയും താരതമ്യ പ്രകടന പരിശോധനകളും ഞങ്ങൾ നൽകും.

ഹൈലോഡ്++ സൈബീരിയ 2019. ടോംസ്ക് ഹാൾ. ജൂൺ 24, 16:00. തീസുകളും അവതരണം. അടുത്ത ഹൈലോഡ്++ കോൺഫറൻസ് 6 ഏപ്രിൽ 7, 2020 തീയതികളിൽ സെൻ്റ് പീറ്റേഴ്‌സ്ബർഗിൽ നടക്കും. വിശദാംശങ്ങളും ടിക്കറ്റുകളും ബന്ധം.

ആന്ദ്രേ ഗുഷ്ചിൻ (ഇനി മുതൽ - എജി): - ഞാൻ ഒരു ZABBIX സാങ്കേതിക പിന്തുണാ എഞ്ചിനീയറാണ് (ഇനി "Zabbix" എന്ന് വിളിക്കപ്പെടുന്നു), ഒരു പരിശീലകനാണ്. ഞാൻ 6 വർഷത്തിലേറെയായി സാങ്കേതിക പിന്തുണയിൽ ജോലി ചെയ്യുന്നു, പ്രകടനത്തിൽ നേരിട്ടുള്ള അനുഭവമുണ്ട്. സാധാരണ PostgreSQL 10-മായി താരതമ്യപ്പെടുത്തുമ്പോൾ TimescaleDB-ന് നൽകാൻ കഴിയുന്ന പ്രകടനത്തെ കുറിച്ച് ഇന്ന് ഞാൻ സംസാരിക്കും. കൂടാതെ, ഇത് പൊതുവെ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ചില ആമുഖ ഭാഗങ്ങളും.

പ്രധാന ഉൽപ്പാദനക്ഷമത വെല്ലുവിളികൾ: ഡാറ്റ ശേഖരണം മുതൽ ഡാറ്റ ശുദ്ധീകരണം വരെ

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

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

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

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

കാഷിംഗ് പ്രശ്നങ്ങൾ എങ്ങനെ പരിഹരിക്കാം?

ഞാൻ ഇപ്പോൾ സബ്ബിക്സിനെ കുറിച്ച് പ്രത്യേകം സംസാരിക്കും. Zabbix-ൽ, ആദ്യത്തെയും രണ്ടാമത്തെയും കോളുകൾ കാഷിംഗ് ഉപയോഗിച്ച് പരിഹരിക്കുന്നു.

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

ഡാറ്റാബേസ് വശത്ത് പ്രധാന തിരഞ്ഞെടുപ്പുകൾക്കായി ചില കാഷിംഗ് ഉണ്ട് - ഗ്രാഫുകൾക്കും മറ്റ് കാര്യങ്ങൾക്കുമായി.

Zabbix സെർവറിൻ്റെ വശത്ത് തന്നെ കാഷെ ചെയ്യുന്നു: ഞങ്ങൾക്ക് കോൺഫിഗറേഷൻ കാഷെ, മൂല്യ കാഷെ, ഹിസ്റ്ററി കാഷെ, ട്രെൻഡ് കാഷെ എന്നിവയുണ്ട്. അത് എന്താണ്?

ഞങ്ങൾ മെട്രിക്‌സ്, ഹോസ്റ്റുകൾ, ഡാറ്റ ഇനങ്ങൾ, ട്രിഗറുകൾ എന്നിവ സംഭരിക്കുന്ന പ്രധാന കാഷെയാണ് കോൺഫിഗറേഷൻ കാഷെ; പ്രീപ്രോസസിംഗ് പ്രോസസ്സ് ചെയ്യാനും ഡാറ്റ ശേഖരിക്കാനും ഏത് ഹോസ്റ്റുകളിൽ നിന്നാണ് ശേഖരിക്കേണ്ടത്, ഏത് ആവൃത്തിയിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ളതെല്ലാം. ഡാറ്റാബേസിലേക്ക് പോകാതിരിക്കാനും അനാവശ്യമായ ചോദ്യങ്ങൾ സൃഷ്ടിക്കാതിരിക്കാനും ഇതെല്ലാം കോൺഫിഗറേഷൻ കാഷെയിൽ സംഭരിച്ചിരിക്കുന്നു. സെർവർ ആരംഭിച്ചതിന് ശേഷം, ഞങ്ങൾ ഈ കാഷെ അപ്‌ഡേറ്റ് ചെയ്യുകയും (അത് സൃഷ്‌ടിക്കുകയും) ഇടയ്‌ക്കിടെ അപ്‌ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു (കോൺഫിഗറേഷൻ ക്രമീകരണങ്ങളെ ആശ്രയിച്ച്).

Zabbix-ൽ കാഷെ ചെയ്യുന്നു. ഡാറ്റ ശേഖരണം

ഇവിടെ ഡയഗ്രം വളരെ വലുതാണ്:

സ്കീമിലെ പ്രധാനവ ഈ കളക്ടർമാരാണ്:

ഇവയാണ് അസംബ്ലി പ്രക്രിയകൾ, വ്യത്യസ്ത തരം അസംബ്ലികൾക്ക് ഉത്തരവാദികളായ വിവിധ "പോളറുകൾ". അവർ icmp, ipmi, കൂടാതെ വിവിധ പ്രോട്ടോക്കോളുകൾ വഴി ഡാറ്റ ശേഖരിക്കുകയും അവയെല്ലാം പ്രീപ്രോസസിംഗിലേക്ക് മാറ്റുകയും ചെയ്യുന്നു.

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

കൂടാതെ, ഞങ്ങൾ ഡാറ്റാ ഘടകങ്ങൾ കണക്കാക്കിയിട്ടുണ്ടെങ്കിൽ (Zabbix-നെ പരിചയമുള്ളവർക്ക് അറിയാം), അതായത്, കണക്കാക്കിയ, അഗ്രഗേഷൻ ഡാറ്റ ഘടകങ്ങൾ, ഞങ്ങൾ അവയെ ValueCache-ൽ നിന്ന് നേരിട്ട് എടുക്കുന്നു. അത് എങ്ങനെ പൂരിപ്പിക്കുമെന്ന് ഞാൻ പിന്നീട് പറയാം. ഈ കളക്ടർമാരെല്ലാം അവരുടെ ജോലികൾ സ്വീകരിക്കുന്നതിന് കോൺഫിഗറേഷൻ കാഷെ ഉപയോഗിക്കുന്നു, തുടർന്ന് അവയെ പ്രീപ്രോസസിംഗിലേക്ക് മാറ്റുന്നു.

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

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

ഹിസ്റ്ററി സിൻസർ വർക്ക്

Zabbix-ലെ പ്രധാന പ്രക്രിയ (ഇത് ഒരു ഏകശിലാ വാസ്തുവിദ്യയായതിനാൽ) ഹിസ്റ്ററി സിൻസർ ആണ്. ഓരോ ഡാറ്റ ഘടകത്തിൻ്റെയും ആറ്റോമിക് പ്രോസസ്സിംഗുമായി പ്രത്യേകമായി ഇടപെടുന്ന പ്രധാന പ്രക്രിയയാണിത്, അതായത് ഓരോ മൂല്യവും:

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

ഡാറ്റാബേസ്. കാഷിംഗ്

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

MySQL-ന് Innodb_buffer_pool ഉണ്ട്, കൂടാതെ കോൺഫിഗർ ചെയ്യാവുന്ന ഒരു കൂട്ടം കാഷെകളും.
എന്നാൽ ഇവയാണ് പ്രധാനം:

• പങ്കിട്ട_ബഫറുകൾ;
• ഫലപ്രദമായ_കാഷെ_വലിപ്പം;
• പങ്കിട്ട_കുളം.

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

ഡാറ്റാബേസ് പ്രകടനത്തെക്കുറിച്ച്

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

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

ചരിത്രം മായ്‌ക്കുന്നു. സാബിക്സിന് ഹൗസ് കീപ്പർ ഉണ്ട്

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

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

അത് ഫലപ്രദമല്ലെന്ന് എങ്ങനെ മനസ്സിലാക്കാം? ആന്തരിക പ്രക്രിയകളുടെ പ്രകടന ഗ്രാഫുകളിൽ നിങ്ങൾക്ക് ഇനിപ്പറയുന്ന ചിത്രം കാണാൻ കഴിയും:

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

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

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

നിങ്ങൾക്ക് അടുത്തതായി എന്തുചെയ്യാൻ കഴിയും? നിങ്ങൾ അത് ഓഫാക്കി, നിങ്ങളുടെ ഗ്രാഫുകൾ സമനിലയിലായി... ഈ കേസിൽ കൂടുതൽ എന്ത് പ്രശ്നങ്ങൾ ഉണ്ടാകാം? എന്ത് സഹായിക്കും?

വിഭജനം (വിഭജനം)

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

നിങ്ങളുടെ സജ്ജീകരണത്തെ ആശ്രയിച്ച് (ഒരു ദിവസം നിങ്ങൾ എത്ര ഡാറ്റ സൃഷ്‌ടിക്കുന്നു), അവർ സാധാരണയായി ഏറ്റവും കുറഞ്ഞത് സജ്ജീകരിക്കുന്നു - ഇത് 1 ദിവസം / ബാച്ച്, കൂടാതെ "ട്രെൻഡുകൾ", മാറ്റങ്ങളുടെ ചലനാത്മകത - 1 മാസം / പുതിയ ബാച്ച്. നിങ്ങൾക്ക് വളരെ വലിയ സജ്ജീകരണമുണ്ടെങ്കിൽ ഇത് മാറിയേക്കാം.

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

വളരെ വലിയ ഇൻസ്റ്റാളേഷനുകളിൽ, 1 ദിവസം അനുയോജ്യമല്ലായിരിക്കാം. MySQL-ൽ പ്രതിദിനം 40 ജിഗാബൈറ്റുകളുടെ പാർട്ടീഷനുകൾ ഞാൻ വ്യക്തിപരമായി കണ്ടിട്ടുണ്ട് (കൂടുതൽ കൂടുതൽ ഉണ്ടാകാം). ഇത് വളരെ വലിയ അളവിലുള്ള ഡാറ്റയാണ്, ഇത് ചില പ്രശ്നങ്ങളിലേക്ക് നയിച്ചേക്കാം. അത് കുറയ്ക്കേണ്ടതുണ്ട്.

എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് വിഭജനം ആവശ്യമായി വരുന്നത്?

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

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

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

NoSQL-നുള്ള ഇലാസ്റ്റിക് തിരയൽ

അടുത്തിടെ, 3.4-ൽ, ഞങ്ങൾ ഒരു NoSQL പരിഹാരം നടപ്പിലാക്കി. ഇലാസ്റ്റിക് സെർച്ചിൽ എഴുതാനുള്ള കഴിവ് ചേർത്തു. നിങ്ങൾക്ക് ചില തരങ്ങൾ എഴുതാം: നിങ്ങൾ തിരഞ്ഞെടുക്കുക - ഒന്നുകിൽ അക്കങ്ങൾ അല്ലെങ്കിൽ ചില അടയാളങ്ങൾ എഴുതുക; ഞങ്ങൾക്ക് സ്ട്രിംഗ് ടെക്‌സ്‌റ്റ് ഉണ്ട്, നിങ്ങൾക്ക് ഇലാസ്റ്റിക് സെർച്ചിലേക്ക് ലോഗുകൾ എഴുതാം... അതനുസരിച്ച്, വെബ് ഇൻ്റർഫേസും ഇലാസ്റ്റിക് സെർച്ചിലേക്ക് പ്രവേശിക്കും. ചില സന്ദർഭങ്ങളിൽ ഇത് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു, എന്നാൽ ഇപ്പോൾ അത് ഉപയോഗിക്കാൻ കഴിയും.

ടൈംസ്കെയിൽDB. ഹൈപ്പർടേബിളുകൾ

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

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

TimescaleDB, PostgreSQL

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

TimescaleDB എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യാം? ഇത് ലളിതമാണ്!

ഇത് ഡോക്യുമെൻ്റേഷനിലുണ്ട്, അത് വിവരിച്ചിരിക്കുന്നു - നിങ്ങൾക്ക് ഏത് പാക്കേജുകളിൽ നിന്നും ഇത് ഇൻസ്റ്റാൾ ചെയ്യാം... ഇത് ഔദ്യോഗിക Postgres പാക്കേജുകളെ ആശ്രയിച്ചിരിക്കുന്നു. സ്വമേധയാ സമാഹരിക്കാൻ കഴിയും. ഡാറ്റാബേസിനായി എനിക്ക് കംപൈൽ ചെയ്യേണ്ടി വന്നു.

Zabbix-ൽ ഞങ്ങൾ എക്സ്റ്റൻഷൻ സജീവമാക്കുന്നു. Postgres-ൽ Extention ഉപയോഗിച്ചവർ... നിങ്ങൾ Extention സജീവമാക്കുക, നിങ്ങൾ ഉപയോഗിക്കുന്ന Zabbix ഡാറ്റാബേസിനായി ഇത് സൃഷ്ടിക്കുക.

ഒപ്പം അവസാന ഘട്ടവും...

ടൈംസ്കെയിൽDB. ചരിത്ര പട്ടികകളുടെ മൈഗ്രേഷൻ

നിങ്ങൾ ഒരു ഹൈപ്പർടേബിൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്. ഇതിനായി ഒരു പ്രത്യേക പ്രവർത്തനം ഉണ്ട് - ഹൈപ്പർടേബിൾ സൃഷ്ടിക്കുക. അതിൽ, ഈ ഡാറ്റാബേസിൽ ആവശ്യമായ പട്ടികയാണ് ആദ്യ പാരാമീറ്റർ (അതിനായി നിങ്ങൾ ഒരു ഹൈപ്പർടേബിൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്).

സൃഷ്ടിക്കേണ്ട ഫീൽഡ്, ഒപ്പം chunk_time_interval (ഇത് ചങ്കുകളുടെ ഇടവേളയാണ് (ഉപയോഗിക്കേണ്ട പാർട്ടീഷനുകൾ). 86 എന്നത് ഒരു ദിവസമാണ്.

Migrate_data പാരാമീറ്റർ: നിങ്ങൾ true എന്നതിലേക്ക് തിരുകുകയാണെങ്കിൽ, ഇത് നിലവിലുള്ള എല്ലാ ഡാറ്റയും മുൻകൂട്ടി സൃഷ്‌ടിച്ച ചങ്കുകളിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യും.

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

ഞങ്ങളുടെ db_extention-ൽ ഞങ്ങൾ അവസാനത്തെ അപ്‌ഡേറ്റ് ചെയ്യുന്നു: ഞങ്ങൾ ടൈംസ്‌കെലെഡ്‌ബി ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതുവഴി ഡാറ്റാബേസും പ്രത്യേകിച്ചും, db_extention ഉണ്ടെന്ന് ഞങ്ങളുടെ Zabbix മനസ്സിലാക്കുന്നു. ടൈംസ്‌കെയിൽ ഡിബിക്ക് ആവശ്യമായ “സവിശേഷതകൾ” ഉപയോഗിച്ച് അദ്ദേഹം അത് സജീവമാക്കുകയും ഡാറ്റാബേസിലേക്കുള്ള ശരിയായ വാക്യഘടനയും അന്വേഷണങ്ങളും ഉപയോഗിക്കുകയും ചെയ്യുന്നു.

സെർവർ കോൺഫിഗറേഷൻ

ഞാൻ രണ്ട് സെർവറുകൾ ഉപയോഗിച്ചു. ആദ്യത്തെ സെർവർ ഒരു ചെറിയ വെർച്വൽ മെഷീൻ, 20 പ്രോസസറുകൾ, 16 ജിഗാബൈറ്റ് റാം എന്നിവയാണ്. ഞാൻ അതിൽ Postgres 10.8 ക്രമീകരിച്ചു:

ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഡെബിയൻ ആയിരുന്നു, ഫയൽ സിസ്റ്റം xfs ആയിരുന്നു. ഈ പ്രത്യേക ഡാറ്റാബേസ് ഉപയോഗിക്കുന്നതിന് ഞാൻ ഏറ്റവും കുറഞ്ഞ ക്രമീകരണങ്ങൾ ഉണ്ടാക്കി, Zabbix തന്നെ ഉപയോഗിക്കും. അതേ മെഷീനിൽ ഒരു Zabbix സെർവർ, PostgreSQL, ലോഡ് ഏജൻ്റുകൾ എന്നിവ ഉണ്ടായിരുന്നു.

വ്യത്യസ്‌ത ഫലങ്ങൾ വേഗത്തിൽ സൃഷ്‌ടിക്കാൻ LoadableModule ഉപയോഗിക്കുന്ന 50 സജീവ ഏജൻ്റുകൾ ഞാൻ ഉപയോഗിച്ചു. അവരാണ് സ്ട്രിംഗുകളും നമ്പറുകളും മറ്റും സൃഷ്ടിച്ചത്. ഞാൻ ധാരാളം ഡാറ്റ ഉപയോഗിച്ച് ഡാറ്റാബേസ് നിറച്ചു. തുടക്കത്തിൽ, കോൺഫിഗറേഷനിൽ ഓരോ ഹോസ്റ്റിനും 5 ആയിരം ഡാറ്റ ഘടകങ്ങൾ അടങ്ങിയിരിക്കുന്നു, കൂടാതെ ഏകദേശം ഓരോ ഡാറ്റ ഘടകത്തിലും ഒരു ട്രിഗർ അടങ്ങിയിരിക്കുന്നു - ഇത് ഒരു യഥാർത്ഥ സജ്ജീകരണമാകാൻ. ചിലപ്പോൾ നിങ്ങൾക്ക് ഒന്നിൽ കൂടുതൽ ട്രിഗറുകൾ ഉപയോഗിക്കേണ്ടി വരും.

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

പ്രകടന പരിശോധന. PostgreSQL: 36 ആയിരം എൻവിപികൾ

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

ഭാവിയിൽ അത്തരം ഗ്രാഫുകൾ ധാരാളം ഉണ്ടാകും. ഇതൊരു സാധാരണ Zabbix സെർവർ പ്രകടന ഡാഷ്‌ബോർഡാണ്.

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

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

പ്രകടന പരിശോധന. PostgreSQL: 50 ആയിരം എൻവിപികൾ

അടുത്തതായി, അതേ ഹാർഡ്‌വെയറിൽ ഞാൻ ലോഡ് സെക്കൻഡിൽ 50 ആയിരം മൂല്യങ്ങളായി വർദ്ധിപ്പിച്ചു. വീട്ടുജോലിക്കാരൻ ലോഡ് ചെയ്യുമ്പോൾ, കണക്കുകൂട്ടലിനൊപ്പം 10-2 സെക്കൻഡിനുള്ളിൽ 3 ആയിരം മൂല്യങ്ങൾ രേഖപ്പെടുത്തി. എന്താണ്, വാസ്തവത്തിൽ, ഇനിപ്പറയുന്ന സ്ക്രീൻഷോട്ടിൽ കാണിച്ചിരിക്കുന്നത്:

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

പ്രകടന പരിശോധന. PostgreSQL: 80 ആയിരം എൻവിപികൾ

അപ്പോൾ ഞാൻ അത് സെക്കൻഡിൽ 80 ആയിരം മൂല്യങ്ങളായി വർദ്ധിപ്പിച്ചു:

ഇത് ഏകദേശം 400 ആയിരം ഡാറ്റ ഘടകങ്ങൾ, 280 ആയിരം ട്രിഗറുകൾ. ഇൻസേർട്ട്, നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഹിസ്റ്ററി സിങ്കറുകളുടെ ലോഡ് കണക്കിലെടുത്ത് (അവയിൽ 30 എണ്ണം ഉണ്ടായിരുന്നു) ഇതിനകം വളരെ ഉയർന്നതാണ്. തുടർന്ന് ഞാൻ വിവിധ പാരാമീറ്ററുകൾ വർദ്ധിപ്പിച്ചു: ഹിസ്റ്ററി സിങ്കറുകൾ, കാഷെ... ഈ ഹാർഡ്‌വെയറിൽ, ഹിസ്റ്ററി സിങ്കറുകളിലെ ലോഡ് പരമാവധി വർദ്ധിപ്പിക്കാൻ തുടങ്ങി, മിക്കവാറും “ഷെൽഫിൽ” - അതനുസരിച്ച്, ഹിസ്റ്ററി കാഷെ വളരെ ഉയർന്ന ലോഡിലേക്ക് പോയി:

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

ഇതിനകം 48 പ്രൊസസറുകളും 128 ജിഗാബൈറ്റ് റാമും ഉള്ള മറ്റൊരു സെർവർ ഞാൻ എടുത്തു:

ഞാൻ അത് "ട്യൂൺ" ചെയ്യുകയും ചെയ്തു - ഹിസ്റ്ററി സിൻസർ (60 കഷണങ്ങൾ) ഇൻസ്റ്റാൾ ചെയ്യുകയും സ്വീകാര്യമായ പ്രകടനം നേടുകയും ചെയ്തു. വാസ്തവത്തിൽ, ഞങ്ങൾ "ഷെൽഫിൽ" അല്ല, പക്ഷേ ഇത് ഒരുപക്ഷേ ഉൽപ്പാദനക്ഷമതയുടെ പരിധിയാണ്, അവിടെ അതിനെക്കുറിച്ച് എന്തെങ്കിലും ചെയ്യേണ്ടത് ഇതിനകം ആവശ്യമാണ്.

പ്രകടന പരിശോധന. ടൈംസ്കെയിൽഡിബി: 80 ആയിരം എൻവിപികൾ

ടൈംസ്‌കെയിൽ ഡിബി ഉപയോഗിക്കുകയായിരുന്നു എൻ്റെ പ്രധാന ജോലി. ഓരോ ഗ്രാഫും ഒരു ഇടിവ് കാണിക്കുന്നു:

ഈ പരാജയങ്ങൾ കൃത്യമായി ഡാറ്റ മൈഗ്രേഷൻ ആണ്. അതിനുശേഷം, Zabbix സെർവറിൽ, നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ഹിസ്റ്ററി സിങ്കറുകളുടെ ലോഡിംഗ് പ്രൊഫൈൽ വളരെയധികം മാറി. ഏകദേശം 3 മടങ്ങ് വേഗത്തിൽ ഡാറ്റ ചേർക്കാനും കുറച്ച് ഹിസ്റ്ററി കാഷെ ഉപയോഗിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു - അതനുസരിച്ച്, നിങ്ങൾക്ക് കൃത്യസമയത്ത് ഡാറ്റ ഡെലിവർ ചെയ്യപ്പെടും. വീണ്ടും, സെക്കൻഡിൽ 80 ആയിരം മൂല്യങ്ങൾ വളരെ ഉയർന്ന നിരക്കാണ് (തീർച്ചയായും, Yandex-നല്ല). മൊത്തത്തിൽ ഇത് ഒരു സെർവർ ഉള്ള ഒരു വലിയ സജ്ജീകരണമാണ്.

PostgreSQL പ്രകടന പരിശോധന: 120 ആയിരം NVP-കൾ

അടുത്തതായി, ഞാൻ ഡാറ്റ മൂലകങ്ങളുടെ എണ്ണത്തിൻ്റെ മൂല്യം അര ദശലക്ഷമായി ഉയർത്തുകയും സെക്കൻഡിൽ 125 ആയിരം കണക്കാക്കിയ മൂല്യം ലഭിക്കുകയും ചെയ്തു:

എനിക്ക് ഈ ഗ്രാഫുകൾ ലഭിച്ചു:

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

സാധാരണയായി, പാർട്ടീഷനുകൾ രാത്രിയിൽ സൃഷ്ടിക്കപ്പെടുന്നു, കാരണം ഇത് സാധാരണയായി തിരുകൽ തടയുകയും പട്ടികകൾക്കൊപ്പം പ്രവർത്തിക്കുകയും ചെയ്യുന്നു, ഇത് സേവനത്തിൻ്റെ അപചയത്തിലേക്ക് നയിച്ചേക്കാം. ഈ സാഹചര്യത്തിൽ ഇത് അങ്ങനെയല്ല! ടൈംസ്‌കെയിൽ ഡിബിയുടെ കഴിവുകൾ പരിശോധിക്കുകയായിരുന്നു പ്രധാന ദൗത്യം. ഫലം ഇനിപ്പറയുന്ന കണക്കായിരുന്നു: സെക്കൻഡിൽ 120 ആയിരം മൂല്യങ്ങൾ.

സമൂഹത്തിലും ഉദാഹരണങ്ങളുണ്ട്:

വ്യക്തി TimescaleDB ഓണാക്കി, io.weight ഉപയോഗിക്കുന്നതിനുള്ള ലോഡ് പ്രോസസറിൽ കുറഞ്ഞു; ടൈംസ്കെയിൽ ഡിബി ഉൾപ്പെടുത്തിയതിനാൽ ആന്തരിക പ്രക്രിയ ഘടകങ്ങളുടെ ഉപയോഗവും കുറഞ്ഞു. മാത്രമല്ല, ഇവ സാധാരണ പാൻകേക്ക് ഡിസ്കുകളാണ്, അതായത്, സാധാരണ ഡിസ്കുകളിലെ ഒരു സാധാരണ വെർച്വൽ മെഷീൻ (എസ്എസ്ഡികളല്ല)!

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

ഞങ്ങളുടെ ഇവൻ്റുകളിലേക്ക് ഞാൻ നിങ്ങളെ എല്ലാവരെയും ക്ഷണിക്കുന്നു: മോസ്കോയിലെ സമ്മേളനം, റിഗയിലെ ഉച്ചകോടി. ഞങ്ങളുടെ ചാനലുകൾ ഉപയോഗിക്കുക - ടെലിഗ്രാം, ഫോറം, IRC. നിങ്ങൾക്ക് എന്തെങ്കിലും ചോദ്യങ്ങളുണ്ടെങ്കിൽ, ഞങ്ങളുടെ മേശയിലേക്ക് വരൂ, നമുക്ക് എല്ലാം സംസാരിക്കാം.

പ്രേക്ഷകരുടെ ചോദ്യങ്ങൾ

പ്രേക്ഷകരിൽ നിന്നുള്ള ചോദ്യം (ഇനി മുതൽ - എ): - ടൈംസ്‌കെയിൽ ഡിബി കോൺഫിഗർ ചെയ്യാൻ വളരെ എളുപ്പമാണെങ്കിൽ, അത് അത്തരത്തിലുള്ള ഒരു പെർഫോമൻസ് ബൂസ്റ്റ് നൽകുന്നുവെങ്കിൽ, ഒരുപക്ഷേ പോസ്റ്റ്‌ഗ്രെസുമായി Zabbix കോൺഫിഗർ ചെയ്യുന്നതിനുള്ള മികച്ച പരിശീലനമായി ഇത് ഉപയോഗിക്കേണ്ടതുണ്ടോ? ഈ പരിഹാരത്തിന് എന്തെങ്കിലും കുഴപ്പങ്ങളും ദോഷങ്ങളുമുണ്ടോ, അല്ലെങ്കിൽ എല്ലാത്തിനുമുപരി, ഞാൻ എനിക്കായി Zabbix നിർമ്മിക്കാൻ തീരുമാനിച്ചാൽ, എനിക്ക് എളുപ്പത്തിൽ Postgres എടുക്കാം, അവിടെ ടൈംസ്‌കെയിൽ ഉടൻ ഇൻസ്റ്റാൾ ചെയ്യാം, അത് ഉപയോഗിക്കുക, പ്രശ്‌നങ്ങളെക്കുറിച്ച് ചിന്തിക്കാതിരിക്കുക ?

എജി: - അതെ, ഇതൊരു നല്ല ശുപാർശയാണെന്ന് ഞാൻ പറയും: TimescaleDB വിപുലീകരണത്തോടൊപ്പം പോസ്റ്റ്‌ഗ്രെസ് ഉടനടി ഉപയോഗിക്കുക. ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, ഈ "സവിശേഷത" പരീക്ഷണാത്മകമാണെങ്കിലും, ധാരാളം നല്ല അവലോകനങ്ങൾ. എന്നാൽ യഥാർത്ഥത്തിൽ ഇത് ഒരു മികച്ച പരിഹാരമാണെന്ന് പരിശോധനകൾ കാണിക്കുന്നു (ടൈംസ്കെയിൽ ഡിബി ഉപയോഗിച്ച്) ഇത് വികസിക്കുമെന്ന് ഞാൻ കരുതുന്നു! ഈ വിപുലീകരണം എങ്ങനെ വികസിക്കുന്നുവെന്നും ആവശ്യാനുസരണം മാറ്റങ്ങൾ വരുത്തുമെന്നും ഞങ്ങൾ നിരീക്ഷിക്കുന്നു.

വികസന സമയത്ത് പോലും, ഞങ്ങൾ അവരുടെ അറിയപ്പെടുന്ന "സവിശേഷതകളിൽ" ഒന്നിനെ ആശ്രയിച്ചു: കുറച്ച് വ്യത്യസ്തമായി കഷണങ്ങളുമായി പ്രവർത്തിക്കാൻ സാധിച്ചു. എന്നാൽ അടുത്ത പതിപ്പിൽ അവർ അത് വെട്ടിക്കുറച്ചു, ഈ കോഡിനെ ആശ്രയിക്കുന്നത് ഞങ്ങൾക്ക് നിർത്തേണ്ടി വന്നു. പല സജ്ജീകരണങ്ങളിലും ഈ പരിഹാരം ഉപയോഗിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു. നിങ്ങൾ MySQL ഉപയോഗിക്കുകയാണെങ്കിൽ... ശരാശരി സജ്ജീകരണങ്ങൾക്ക്, ഏത് പരിഹാരവും നന്നായി പ്രവർത്തിക്കുന്നു.

ഉത്തരം: - കമ്മ്യൂണിറ്റിയിൽ നിന്നുള്ള അവസാന ഗ്രാഫുകളിൽ, "ഹൗസ് കീപ്പർ" ഉള്ള ഒരു ഗ്രാഫ് ഉണ്ടായിരുന്നു:

അവൻ ജോലി തുടർന്നു. TimescaleDB ഉപയോഗിച്ച് വീട്ടുജോലിക്കാരൻ എന്താണ് ചെയ്യുന്നത്?

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

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

ടൈംസ്‌കെയിൽ ഇനി അങ്ങനെയൊരു ചങ്ക് നിലവിലില്ലെന്ന് മനസ്സിലാക്കുന്നു. കൂടാതെ ഇത് ക്വറി പ്ലാനറിലേക്ക് സംയോജിപ്പിച്ചിരിക്കുന്നതിനാൽ, തിരഞ്ഞെടുത്ത അല്ലെങ്കിൽ മറ്റ് പ്രവർത്തനങ്ങളിൽ നിങ്ങളുടെ അവസ്ഥകൾ പിടിക്കാൻ ഇത് കൊളുത്തുകൾ ഉപയോഗിക്കുന്നു, ഈ ഭാഗം മേലിൽ നിലവിലില്ലെന്ന് ഉടൻ മനസ്സിലാക്കുന്നു - "ഞാൻ ഇനി അവിടെ പോകില്ല!" (ഡാറ്റ ലഭ്യമല്ല). അത്രയേയുള്ളൂ! അതായത്, ഒരു ടേബിൾ സ്കാൻ പകരം ഒരു ബൈനറി ഫയൽ ഇല്ലാതാക്കുന്നു, അതിനാൽ ഇത് വേഗതയുള്ളതാണ്.

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

എജി: - അൺലോഡിംഗ് നടത്താം. പതിപ്പ് 3.4 മുതൽ ഞങ്ങൾക്ക് ഒരു പ്രത്യേക "സവിശേഷത" ഉണ്ട്: നിങ്ങൾക്ക് എല്ലാ ചരിത്രപരമായ ഫയലുകളും ഇവൻ്റുകളും മറ്റ് എല്ലാം ഫയലുകളിലേക്ക് എഴുതാം; തുടർന്ന് ഏതെങ്കിലും ഹാൻഡ്‌ലർ ഉപയോഗിച്ച് മറ്റേതെങ്കിലും ഡാറ്റാബേസിലേക്ക് അയക്കുക. വാസ്തവത്തിൽ, പലരും വീണ്ടും പ്രവർത്തിക്കുകയും ഡാറ്റാബേസിലേക്ക് നേരിട്ട് എഴുതുകയും ചെയ്യുന്നു. പറക്കുമ്പോൾ, ഹിസ്റ്ററി സിങ്കറുകൾ ഇതെല്ലാം ഫയലുകളിലേക്ക് എഴുതുകയും ഈ ഫയലുകൾ തിരിക്കുകയും മറ്റും ചെയ്യുക, നിങ്ങൾക്ക് ഇത് ക്ലിക്ക്ഹൗസിലേക്ക് മാറ്റാവുന്നതാണ്. പ്ലാനുകളെ കുറിച്ച് എനിക്ക് പറയാനാവില്ല, പക്ഷേ NoSQL സൊല്യൂഷനുകൾക്കുള്ള (ക്ലിക്ക്ഹൗസ് പോലുള്ളവ) കൂടുതൽ പിന്തുണ തുടരും.

ഉത്തരം: - പൊതുവേ, നിങ്ങൾക്ക് പോസ്റ്റ്‌ഗ്രെസിൽ നിന്ന് പൂർണ്ണമായും രക്ഷപ്പെടാൻ കഴിയുമെന്ന് മാറുന്നുണ്ടോ?

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

ഉത്തരം: - ഉദാഹരണത്തിന്, ക്ലിക്ക്ഹൗസിലേക്ക് മാറുകയാണെങ്കിൽ എല്ലാം എത്ര വേഗത്തിൽ പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾക്ക് കണക്കാക്കാമോ?

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

ഉത്തരം: - അപ്പോൾ നമ്മൾ സംസാരിക്കുന്നത് തുല്യ പോരാട്ടത്തെക്കുറിച്ചാണ്, അല്ലാതെ ഈ ഫാസ്റ്റ് ഡാറ്റാബേസുകളുടെ വലിയ നേട്ടത്തെക്കുറിച്ചല്ല?

എജി: - ഞങ്ങൾ സംയോജിപ്പിക്കുമ്പോൾ, കൂടുതൽ കൃത്യമായ പരിശോധനകൾ ഉണ്ടാകുമെന്ന് ഞാൻ കരുതുന്നു.

ഉത്തരം: – നല്ല പഴയ RRD എവിടെ പോയി? എന്താണ് നിങ്ങളെ SQL ഡാറ്റാബേസുകളിലേക്ക് മാറാൻ പ്രേരിപ്പിച്ചത്? തുടക്കത്തിൽ, എല്ലാ അളവുകളും RRD-യിൽ ശേഖരിച്ചു.

എജി: - സാബിക്സിന് RRD ഉണ്ടായിരുന്നു, ഒരുപക്ഷേ വളരെ പുരാതനമായ ഒരു പതിപ്പിൽ. എല്ലായ്‌പ്പോഴും SQL ഡാറ്റാബേസുകൾ ഉണ്ട് - ഒരു ക്ലാസിക് സമീപനം. ക്ലാസിക് സമീപനം MySQL, PostgreSQL (അവ വളരെക്കാലമായി നിലവിലുണ്ട്). SQL, RRD ഡാറ്റാബേസുകൾക്കായി ഞങ്ങൾ ഒരിക്കലും ഒരു പൊതു ഇൻ്റർഫേസ് ഉപയോഗിച്ചിട്ടില്ല.

ചില പരസ്യങ്ങൾ 🙂

ഞങ്ങളോടൊപ്പം താമസിച്ചതിന് നന്ദി. ഞങ്ങളുടെ ലേഖനങ്ങൾ നിങ്ങൾക്ക് ഇഷ്ടമാണോ? കൂടുതൽ രസകരമായ ഉള്ളടക്കം കാണാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? ഒരു ഓർഡർ നൽകി അല്ലെങ്കിൽ സുഹൃത്തുക്കൾക്ക് ശുപാർശ ചെയ്തുകൊണ്ട് ഞങ്ങളെ പിന്തുണയ്ക്കുക, $4.99 മുതൽ ഡെവലപ്പർമാർക്കുള്ള ക്ലൗഡ് VPS, എൻട്രി ലെവൽ സെർവറുകളുടെ ഒരു അദ്വിതീയ അനലോഗ്, നിങ്ങൾക്കായി ഞങ്ങൾ കണ്ടുപിടിച്ചതാണ്: VPS (KVM) E5-2697 v3 (6 കോറുകൾ) 10GB DDR4 480GB SSD 1Gbps-നെക്കുറിച്ചുള്ള മുഴുവൻ സത്യവും $19 മുതൽ അല്ലെങ്കിൽ എങ്ങനെ ഒരു സെർവർ പങ്കിടാം? (RAID1, RAID10 എന്നിവയ്‌ക്കൊപ്പം 24 കോറുകൾ വരെയും 40GB DDR4 വരെയും ലഭ്യമാണ്).

ആംസ്റ്റർഡാമിലെ Equinix Tier IV ഡാറ്റാ സെന്ററിൽ Dell R730xd 2 മടങ്ങ് വിലക്കുറവാണോ? ഇവിടെ മാത്രം 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 മുതൽ നെതർലാൻഡിൽ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 മുതൽ! കുറിച്ച് വായിക്കുക ഇൻഫ്രാസ്ട്രക്ചർ കോർപ്പറേഷൻ എങ്ങനെ നിർമ്മിക്കാം. ഒരു പൈസയ്ക്ക് 730 യൂറോ വിലയുള്ള Dell R5xd E2650-4 v9000 സെർവറുകൾ ഉപയോഗിക്കുന്ന ക്ലാസ്?

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