ഒന്നിലധികം സമയ ശ്രേണി ഡാറ്റാബേസുകൾ ഞങ്ങൾ എങ്ങനെയാണ് പരീക്ഷിച്ചത്

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

2019-ൽ TSDB ഉപയോഗിക്കേണ്ട ഒരു ലേഖനത്തിൽ ഒരു വാചകം മാത്രമേ ഉള്ളൂ എന്ന് തോന്നിയേക്കാം: "ക്ലിക്ക്ഹൗസ് ഉപയോഗിക്കുക." പക്ഷേ... സൂക്ഷ്മതകളുണ്ട്.

തീർച്ചയായും, ClickHouse സജീവമായി വികസിച്ചുകൊണ്ടിരിക്കുന്നു, ഉപയോക്തൃ അടിത്തറ വളരുകയാണ്, പിന്തുണ വളരെ സജീവമാണ്, എന്നാൽ മറ്റ്, ഒരുപക്ഷേ കൂടുതൽ ഫലപ്രദമായ/വിശ്വസനീയമായ പരിഹാരങ്ങളെ മറികടക്കുന്ന ClickHouse-ന്റെ പൊതു വിജയത്തിന് ഞങ്ങൾ ബന്ദികളാക്കിയോ?

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

പ്രശ്ന പ്രസ്താവന

ഒന്നാമതായി, അത്യാവശ്യമായ ഒരു മുഖവുര. എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഞങ്ങളുടെ സ്വന്തം മോണിറ്ററിംഗ് സിസ്റ്റം ആവശ്യമായി വരുന്നത്, അത് എങ്ങനെ രൂപകൽപ്പന ചെയ്‌തു?

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

ഞങ്ങളുടെ പ്രധാന ആവശ്യകതകൾ ഇവയായിരുന്നു:

• പിന്തുണ (അക്കാലത്ത് - ഡസൻ, ഭാവിയിൽ - നൂറുകണക്കിന്) ഒരു സിസ്റ്റത്തിനുള്ളിൽ ക്ലയന്റുകൾ, അതേ സമയം ഒരു കേന്ദ്രീകൃത അലേർട്ട് മാനേജ്മെന്റ് സിസ്റ്റത്തിന്റെ സാന്നിധ്യം;
• അലേർട്ട് സിസ്റ്റം കൈകാര്യം ചെയ്യുന്നതിനുള്ള വഴക്കം (ഡ്യൂട്ടി ഓഫീസർമാർ തമ്മിലുള്ള അലേർട്ടുകളുടെ വർദ്ധനവ്, ഷെഡ്യൂളിംഗ്, വിജ്ഞാന അടിത്തറ);
• ഗ്രാഫുകൾ ആഴത്തിൽ വിശദീകരിക്കാനുള്ള കഴിവ് (അക്കാലത്ത് Zabbix ചിത്രങ്ങളുടെ രൂപത്തിൽ ഗ്രാഫുകൾ റെൻഡർ ചെയ്തു);
• ഒരു വലിയ അളവിലുള്ള ഡാറ്റയുടെ ദീർഘകാല സംഭരണവും (ഒരു വർഷമോ അതിൽ കൂടുതലോ) അത് വേഗത്തിൽ വീണ്ടെടുക്കാനുള്ള കഴിവും.

ഈ ലേഖനത്തിൽ ഞങ്ങൾക്ക് അവസാന പോയിന്റിൽ താൽപ്പര്യമുണ്ട്.

സംഭരണത്തെക്കുറിച്ച് പറയുമ്പോൾ, ആവശ്യകതകൾ ഇപ്രകാരമായിരുന്നു:

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

വിചിത്രമെന്നു പറയട്ടെ, ആ സമയത്ത് MySQL ഞങ്ങൾക്ക് അനുയോജ്യമായ പരിഹാരമായി മാറി. ഞങ്ങളുടെ ഡാറ്റാ ഘടന വളരെ ലളിതമായിരുന്നു: സെർവർ ഐഡി, കൌണ്ടർ ഐഡി, ടൈംസ്റ്റാമ്പ്, മൂല്യം; ഹോട്ട് ഡാറ്റയുടെ വേഗത്തിലുള്ള സാമ്പിൾ ഒരു വലിയ ബഫർ പൂൾ ഉറപ്പാക്കി, കൂടാതെ ചരിത്രപരമായ ഡാറ്റയുടെ സാമ്പിൾ എസ്എസ്ഡി ഉറപ്പാക്കി.

അങ്ങനെ, ഡാറ്റ പൂർണ്ണമായും റെൻഡർ ചെയ്യപ്പെടുന്നതിന് മുമ്പ് ഒരു സെക്കന്റ് 200 ms വരെയുള്ള വിശദാംശങ്ങളോടെ ഞങ്ങൾ രണ്ടാഴ്ചത്തെ പുതിയ ഡാറ്റയുടെ ഒരു സാമ്പിൾ നേടി, ഈ സിസ്റ്റത്തിൽ വളരെക്കാലം ജീവിച്ചു.

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

ഈ സമയമായപ്പോഴേക്കും, കോളം ഡാറ്റാബേസുകൾ സജീവമായി വ്യാപകമായിരുന്നു, അത് ഞങ്ങൾ സജീവമായി ചിന്തിക്കാൻ തുടങ്ങി: കോളം ഡാറ്റാബേസുകളിൽ, നിങ്ങൾക്ക് മനസ്സിലാക്കാൻ കഴിയുന്നതുപോലെ, കോളങ്ങളിൽ ഡാറ്റ സംഭരിക്കുന്നു, ഞങ്ങളുടെ ഡാറ്റ നോക്കുകയാണെങ്കിൽ, വലിയൊരു ഭാഗം കാണാൻ എളുപ്പമാണ്. നിങ്ങൾ ഒരു കോളം ഡാറ്റാബേസ് ഉപയോഗിക്കുകയാണെങ്കിൽ, കംപ്രഷൻ ഉപയോഗിച്ച് കംപ്രസ് ചെയ്യാൻ കഴിയുന്ന ഡ്യൂപ്ലിക്കേറ്റുകളുടെ എണ്ണം.

എന്നിരുന്നാലും, കമ്പനിയുടെ പ്രധാന സംവിധാനം സ്ഥിരമായി പ്രവർത്തിക്കുന്നത് തുടർന്നു, മറ്റെന്തെങ്കിലും മാറുന്നത് പരീക്ഷിക്കാൻ ഞാൻ ആഗ്രഹിച്ചില്ല.

2017-ൽ, സാൻ ജോസിലെ പെർക്കോണ ലൈവ് കോൺഫറൻസിൽ, ക്ലിക്ക്ഹൗസ് ഡെവലപ്പർമാർ ഒരുപക്ഷേ ആദ്യമായി സ്വയം പ്രഖ്യാപിച്ചു. ഒറ്റനോട്ടത്തിൽ, സിസ്റ്റം ഉൽപ്പാദനത്തിന് തയ്യാറായിരുന്നു (നന്നായി, Yandex.Metrica ഒരു കഠിനമായ ഉൽപാദന സംവിധാനമാണ്), പിന്തുണ വേഗതയേറിയതും ലളിതവുമായിരുന്നു, ഏറ്റവും പ്രധാനമായി, പ്രവർത്തനം ലളിതമായിരുന്നു. 2018 മുതൽ, ഞങ്ങൾ പരിവർത്തന പ്രക്രിയ ആരംഭിച്ചു. എന്നാൽ അപ്പോഴേക്കും, ധാരാളം "മുതിർന്നവർക്കുള്ള", സമയം പരീക്ഷിച്ച TSDB സിസ്റ്റങ്ങൾ ഉണ്ടായിരുന്നു, ഞങ്ങളുടെ ആവശ്യകതകൾക്കനുസരിച്ച് ക്ലിക്ക്ഹൗസിന് ബദൽ പരിഹാരങ്ങളൊന്നുമില്ലെന്ന് ഉറപ്പാക്കുന്നതിന് ഗണ്യമായ സമയം ചെലവഴിക്കാനും ഇതരമാർഗങ്ങൾ താരതമ്യം ചെയ്യാനും ഞങ്ങൾ തീരുമാനിച്ചു.

ഇതിനകം വ്യക്തമാക്കിയ സ്റ്റോറേജ് ആവശ്യകതകൾക്ക് പുറമേ, പുതിയവ പ്രത്യക്ഷപ്പെട്ടു:

• ഒരേ അളവിലുള്ള ഹാർഡ്‌വെയറിൽ MySQL-ന്റെ അതേ പ്രകടനമെങ്കിലും പുതിയ സിസ്റ്റം നൽകണം;
• പുതിയ സിസ്റ്റത്തിന്റെ സംഭരണം ഗണ്യമായി കുറച്ച് സ്ഥലം എടുക്കണം;
• DBMS ഇപ്പോഴും കൈകാര്യം ചെയ്യാൻ എളുപ്പമായിരിക്കണം;
• ഡിബിഎംഎസ് മാറ്റുമ്പോൾ ആപ്ലിക്കേഷൻ ചുരുങ്ങിയത് മാറ്റാൻ ഞാൻ ആഗ്രഹിച്ചു.

ഏത് സംവിധാനങ്ങളാണ് ഞങ്ങൾ പരിഗണിക്കാൻ തുടങ്ങിയത്?

അപ്പാച്ചെ ഹൈവ്/അപ്പാച്ചെ ഇംപാല
ഒരു പഴയ, യുദ്ധത്തിൽ പരീക്ഷിച്ച ഹഡൂപ്പ് സ്റ്റാക്ക്. അടിസ്ഥാനപരമായി, ഇത് HDFS-ൽ നേറ്റീവ് ഫോർമാറ്റുകളിൽ ഡാറ്റ സംഭരിക്കുന്നതിന് മുകളിൽ നിർമ്മിച്ച ഒരു SQL ഇന്റർഫേസാണ്.

പ്രൊഫ.

• സ്ഥിരമായ പ്രവർത്തനത്തിലൂടെ, ഡാറ്റ സ്കെയിൽ ചെയ്യുന്നത് വളരെ എളുപ്പമാണ്.
• ഡാറ്റ സംഭരണത്തിനായി കോളം സൊല്യൂഷനുകൾ ഉണ്ട് (കുറവ് സ്ഥലം).
• വിഭവങ്ങൾ ലഭ്യമാണെങ്കിൽ സമാന്തര ജോലികൾ വളരെ വേഗത്തിൽ നടപ്പിലാക്കുന്നു.

ബാക്ക്ട്രെയിസ്.

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

എന്നിരുന്നാലും:

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

ഡ്രൂയിഡ്/പിനോട്ട്

ടി‌എസ്‌ഡി‌ബിയെക്കുറിച്ച് പ്രത്യേകമായി വളരെയധികം കാര്യങ്ങൾ ഉണ്ട്, എന്നാൽ വീണ്ടും, ഹഡൂപ്പ് സ്റ്റാക്ക്.

ഉണ്ട് ഡ്രൂയിഡിന്റെയും പിനോട്ടിന്റെയും ഗുണദോഷങ്ങൾ, ക്ലിക്ക്ഹൗസ് എന്നിവ താരതമ്യം ചെയ്യുന്ന മികച്ച ലേഖനം .

കുറച്ച് വാക്കുകളിൽ: ഡ്രൂയിഡ്/പിനോട്ട് ഇനിപ്പറയുന്ന സന്ദർഭങ്ങളിൽ ക്ലിക്ക്ഹൗസിനേക്കാൾ മികച്ചതായി കാണപ്പെടുന്നു:

• നിങ്ങൾക്ക് ഡാറ്റയുടെ വൈവിധ്യമാർന്ന സ്വഭാവമുണ്ട് (ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾ സെർവർ മെട്രിക്കുകളുടെ ടൈംസറികൾ മാത്രം രേഖപ്പെടുത്തുന്നു, വാസ്തവത്തിൽ ഇത് ഒരു പട്ടികയാണ്. എന്നാൽ മറ്റ് സാഹചര്യങ്ങൾ ഉണ്ടാകാം: ഉപകരണ സമയ ശ്രേണി, സാമ്പത്തിക സമയ ശ്രേണി മുതലായവ - ഓരോന്നിനും. അതിന്റെ സ്വന്തം ഘടന, അത് കൂട്ടിച്ചേർക്കുകയും പ്രോസസ്സ് ചെയ്യുകയും വേണം).
• കൂടാതെ, ഈ ഡാറ്റയിൽ ധാരാളം ഉണ്ട്.
• സമയ ശ്രേണിയിലുള്ള പട്ടികകളും ഡാറ്റയും പ്രത്യക്ഷപ്പെടുകയും അപ്രത്യക്ഷമാവുകയും ചെയ്യുന്നു (അതായത്, കുറച്ച് ഡാറ്റ എത്തി, വിശകലനം ചെയ്യുകയും ഇല്ലാതാക്കുകയും ചെയ്തു).
• ഡാറ്റ പാർട്ടീഷൻ ചെയ്യാൻ കഴിയുന്ന വ്യക്തമായ മാനദണ്ഡമില്ല.

വിപരീത സന്ദർഭങ്ങളിൽ, ClickHouse മികച്ച പ്രകടനം കാഴ്ചവയ്ക്കുന്നു, ഇതാണ് ഞങ്ങളുടെ കാര്യം.

ക്ലിക്ക്ഹ ouse സ്

• SQL പോലെ
• കൈകാര്യം ചെയ്യാൻ എളുപ്പമാണ്.
• ഇത് പ്രവർത്തിക്കുന്നുവെന്ന് ആളുകൾ പറയുന്നു.

പരിശോധനയ്ക്കായി ഷോർട്ട്‌ലിസ്റ്റ് ചെയ്യപ്പെടുന്നു.

InfluxDB

ClickHouse-ന് ഒരു വിദേശ ബദൽ. മൈനസുകളിൽ: ഉയർന്ന ലഭ്യത വാണിജ്യ പതിപ്പിൽ മാത്രമേ ഉള്ളൂ, പക്ഷേ അത് താരതമ്യം ചെയ്യേണ്ടതുണ്ട്.

പരിശോധനയ്ക്കായി ഷോർട്ട്‌ലിസ്റ്റ് ചെയ്യപ്പെടുന്നു.

ചേട്ടനാണു

ഒരു വശത്ത്, അത്തരം നിരീക്ഷണ സംവിധാനങ്ങൾ മെട്രിക് ടൈംസറികൾ സംഭരിക്കുന്നതിന് ഇത് ഉപയോഗിക്കുന്നുവെന്ന് ഞങ്ങൾക്കറിയാം, ഉദാഹരണത്തിന്, സിഗ്നൽഎഫ്എക്സ് അല്ലെങ്കിൽ OkMeter. എന്നിരുന്നാലും, പ്രത്യേകതകൾ ഉണ്ട്.

പരമ്പരാഗത അർത്ഥത്തിൽ കസാന്ദ്ര ഒരു കോളം ഡാറ്റാബേസ് അല്ല. ഇത് ഒരു വരി കാഴ്‌ച പോലെയാണ് കാണപ്പെടുന്നത്, എന്നാൽ ഓരോ വരിയിലും വ്യത്യസ്ത എണ്ണം നിരകൾ ഉണ്ടായിരിക്കാം, ഇത് ഒരു നിര വ്യൂ ഓർഗനൈസുചെയ്യുന്നത് എളുപ്പമാക്കുന്നു. ഈ അർത്ഥത്തിൽ, 2 ബില്യൺ കോളങ്ങളുടെ പരിധിയിൽ, ചില ഡാറ്റ കോളങ്ങളിൽ (അതേ സമയ ശ്രേണിയിൽ) സംഭരിക്കാൻ കഴിയുമെന്ന് വ്യക്തമാണ്. ഉദാഹരണത്തിന്, MySQL-ൽ 4096 നിരകളുടെ പരിധിയുണ്ട്, നിങ്ങൾ അത് ചെയ്യാൻ ശ്രമിച്ചാൽ കോഡ് 1117-ൽ ഒരു പിശക് സംഭവിക്കുന്നത് എളുപ്പമാണ്.

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

പ്രോമിത്തിയസ്

ശരി, ജിജ്ഞാസ നിമിത്തം, പ്രോമിത്യൂസ് സ്റ്റോറേജിന്റെ പ്രകടനം പരിശോധിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു - നിലവിലെ പരിഹാരങ്ങളേക്കാൾ ഞങ്ങൾ വേഗതയേറിയതാണോ അതോ മന്ദഗതിയിലാണോ എന്ന് മനസിലാക്കാൻ.

ടെസ്റ്റിംഗ് രീതിശാസ്ത്രവും ഫലങ്ങളും

അതിനാൽ, ഇനിപ്പറയുന്ന 5 കോൺഫിഗറേഷനുകളിൽ ഞങ്ങൾ 6 ഡാറ്റാബേസുകൾ പരീക്ഷിച്ചു: ClickHouse (1 നോഡ്), ClickHouse (3 നോഡുകൾക്കായി വിതരണം ചെയ്ത പട്ടിക), InfluxDB, Mysql 8, Cassandra (3 നോഡുകൾ), Prometheus. ടെസ്റ്റ് പ്ലാൻ ഇപ്രകാരമാണ്:

1. ഒരാഴ്‌ചത്തേക്കുള്ള ചരിത്രപരമായ ഡാറ്റ അപ്‌ലോഡ് ചെയ്യുക (പ്രതിദിനം 840 ദശലക്ഷം മൂല്യങ്ങൾ; 208 ആയിരം മെട്രിക്‌സ്);
2. ഞങ്ങൾ ഒരു റെക്കോർഡിംഗ് ലോഡ് സൃഷ്ടിക്കുന്നു (6 ലോഡ് മോഡുകൾ പരിഗണിച്ചു, താഴെ കാണുക);
3. റെക്കോർഡിംഗിന് സമാന്തരമായി, ചാർട്ടുകൾക്കൊപ്പം പ്രവർത്തിക്കുന്ന ഒരു ഉപയോക്താവിന്റെ അഭ്യർത്ഥനകൾ അനുകരിച്ചുകൊണ്ട് ഞങ്ങൾ ഇടയ്ക്കിടെ തിരഞ്ഞെടുക്കലുകൾ നടത്തുന്നു. കാര്യങ്ങൾ വളരെയധികം സങ്കീർണ്ണമാക്കാതിരിക്കാൻ, ഞങ്ങൾ ഒരാഴ്ചത്തേക്ക് 10 മെട്രിക്‌സ് (സിപിയു ഗ്രാഫിൽ എത്രയെണ്ണം ഉണ്ടെന്ന്) ഡാറ്റ തിരഞ്ഞെടുത്തു.

ഓരോ 15 സെക്കൻഡിലും ഒരിക്കൽ ഓരോ മെട്രിക്കിലേക്കും മൂല്യങ്ങൾ അയയ്ക്കുന്ന ഞങ്ങളുടെ മോണിറ്ററിംഗ് ഏജന്റിന്റെ പെരുമാറ്റം അനുകരിച്ചുകൊണ്ട് ഞങ്ങൾ ലോഡ് ചെയ്യുന്നു. അതേ സമയം, വ്യത്യസ്തമാക്കുന്നതിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്:

• ഡാറ്റ എഴുതിയിരിക്കുന്ന മെട്രിക്കുകളുടെ ആകെ എണ്ണം;
• ഒരു മെട്രിക്കിലേക്ക് മൂല്യങ്ങൾ അയയ്ക്കുന്നതിനുള്ള ഇടവേള;
• ബാച്ച് വലുപ്പം.

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

കൂടാതെ, ലഭിച്ച ഡാറ്റ എങ്ങനെ വ്യാഖ്യാനിക്കാമെന്ന് നന്നായി മനസിലാക്കാൻ, ഞങ്ങൾ ഒരു കൂട്ടം മെട്രിക്‌സ് അയയ്‌ക്കുക മാത്രമല്ല, മെട്രിക്‌സ് സെർവറുകളായി ക്രമീകരിച്ചിരിക്കുന്നു - ഒരു സെർവറിന് 125 മെട്രിക്‌സ് എന്ന് സങ്കൽപ്പിക്കുക. ഇവിടെ സെർവർ ഒരു വെർച്വൽ എന്റിറ്റിയാണ് - ഉദാഹരണത്തിന്, 10000 മെട്രിക്‌സ് ഏകദേശം 80 സെർവറുകളുമായി പൊരുത്തപ്പെടുന്നുവെന്ന് മനസിലാക്കാൻ.

ഇവിടെ, ഇതെല്ലാം കണക്കിലെടുക്കുമ്പോൾ, ഞങ്ങളുടെ 6 ഡാറ്റാബേസ് റൈറ്റ് ലോഡ് മോഡുകൾ ഉണ്ട്:

ഇവിടെ രണ്ട് പോയിന്റുകൾ ഉണ്ട്. ഒന്നാമതായി, കസാന്ദ്രയെ സംബന്ധിച്ചിടത്തോളം ഈ ബാച്ച് വലുപ്പങ്ങൾ വളരെ വലുതായി മാറി, അവിടെ ഞങ്ങൾ 50 അല്ലെങ്കിൽ 100 ​​മൂല്യങ്ങൾ ഉപയോഗിച്ചു. രണ്ടാമതായി, പ്രോമിത്യൂസ് കർശനമായി പുൾ മോഡിൽ പ്രവർത്തിക്കുന്നതിനാൽ, അതായത്. അത് തന്നെ പോയി മെട്രിക്സ് ഉറവിടങ്ങളിൽ നിന്ന് ഡാറ്റ ശേഖരിക്കുന്നു (കൂടാതെ പുഷ്‌ഗേറ്റ്‌വേ, പേര് ഉണ്ടായിരുന്നിട്ടും, അടിസ്ഥാനപരമായി സ്ഥിതി മാറ്റുന്നില്ല), സ്റ്റാറ്റിക് കോൺഫിഗറുകളുടെ സംയോജനം ഉപയോഗിച്ച് അനുബന്ധ ലോഡുകൾ നടപ്പിലാക്കി.

പരിശോധനാ ഫലങ്ങൾ ഇപ്രകാരമാണ്:

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

തത്ഫലമായി,: ClickHouse ഉം InfluxDB ഉം തങ്ങളെത്തന്നെ മികച്ചതാണെന്ന് കാണിച്ചു, എന്നാൽ Influx-ൽ നിന്നുള്ള ഒരു ക്ലസ്റ്റർ എന്റർപ്രൈസ് പതിപ്പിന്റെ അടിസ്ഥാനത്തിൽ മാത്രമേ നിർമ്മിക്കാൻ കഴിയൂ, അതിന് പണം ചിലവാകും, അതേസമയം ClickHouse ഒന്നും ചെലവാകാത്തതും റഷ്യയിൽ നിർമ്മിച്ചതുമാണ്. യു‌എസ്‌എയിൽ തിരഞ്ഞെടുപ്പ് ഒരുപക്ഷേ inInfluxDB-യ്‌ക്ക് അനുകൂലമാകുമെന്നത് യുക്തിസഹമാണ്, നമ്മുടെ രാജ്യത്ത് ഇത് ClickHouse-ന് അനുകൂലമാണ്.

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