വിക്ടോറിയമെട്രിക്സിലെ ഒപ്റ്റിമൈസേഷനുകൾ പോകുക. അലക്സാണ്ടർ വല്യാൽകിൻ

2019-ലെ അവസാനത്തെ അലക്‌സാണ്ടർ വല്യാൽകിന്റെ “വിക്ടോറിയമെട്രിക്‌സിലെ ഒപ്റ്റിമൈസേഷനുകൾ” എന്ന റിപ്പോർട്ടിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് വായിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു.

വിക്ടോറിയമെട്രിക്സ് - ഒരു സമയ ശ്രേണിയുടെ രൂപത്തിൽ ഡാറ്റ സംഭരിക്കുന്നതിനും പ്രോസസ്സ് ചെയ്യുന്നതിനുമുള്ള വേഗതയേറിയതും അളക്കാവുന്നതുമായ DBMS (റെക്കോർഡ് ഈ സമയവുമായി ബന്ധപ്പെട്ട സമയവും മൂല്യങ്ങളുടെ ഒരു കൂട്ടവും രൂപപ്പെടുത്തുന്നു, ഉദാഹരണത്തിന്, സെൻസറുകളുടെ നിലയുടെ ആനുകാലിക വോട്ടെടുപ്പിലൂടെയോ ശേഖരണത്തിലൂടെയോ ലഭിക്കും. അളവുകൾ).

ഈ റിപ്പോർട്ടിന്റെ വീഡിയോയിലേക്കുള്ള ലിങ്ക് ഇതാ - https://youtu.be/MZ5P21j_HLE

സ്ലൈഡുകൾ

നിങ്ങളെക്കുറിച്ച് ഞങ്ങളോട് പറയുക. ഞാൻ അലക്സാണ്ടർ വല്യാൽകിൻ. ഇവിടെ എന്റെ GitHub അക്കൗണ്ട്. Go, പെർഫോമൻസ് ഒപ്റ്റിമൈസേഷൻ എന്നിവയിൽ എനിക്ക് താൽപ്പര്യമുണ്ട്. ഞാൻ ധാരാളം ഉപയോഗപ്രദവും വളരെ ഉപയോഗപ്രദമല്ലാത്തതുമായ ലൈബ്രറികൾ എഴുതി. അവ രണ്ടിൽ നിന്നും ആരംഭിക്കുന്നു fast, അല്ലെങ്കിൽ കൂടെ quick പ്രിഫിക്സ്.

ഞാൻ ഇപ്പോൾ വിക്ടോറിയമെട്രിക്സിൽ ജോലി ചെയ്യുന്നു. അതെന്താണ്, ഞാൻ അവിടെ എന്താണ് ചെയ്യുന്നത്? ഈ അവതരണത്തിൽ ഞാൻ ഇതിനെക്കുറിച്ച് സംസാരിക്കും.

റിപ്പോർട്ടിന്റെ രൂപരേഖ ഇപ്രകാരമാണ്:

• ആദ്യം, വിക്ടോറിയമെട്രിക്സ് എന്താണെന്ന് ഞാൻ നിങ്ങളോട് പറയും.
• അപ്പോൾ ടൈം സീരീസ് എന്താണെന്ന് ഞാൻ പറയാം.
• ഒരു ടൈം സീരീസ് ഡാറ്റാബേസ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഞാൻ നിങ്ങളോട് പറയും.
• അടുത്തതായി, ഡാറ്റാബേസ് ആർക്കിടെക്ചറിനെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് പറയും: അതിൽ എന്താണ് അടങ്ങിയിരിക്കുന്നത്.
• തുടർന്ന് നമുക്ക് വിക്ടോറിയമെട്രിക്സിന്റെ ഒപ്റ്റിമൈസേഷനുകളിലേക്ക് പോകാം. ഇത് വിപരീത സൂചികയ്ക്കുള്ള ഒപ്റ്റിമൈസേഷനും Go-യിലെ ബിറ്റ്സെറ്റ് നടപ്പിലാക്കുന്നതിനുള്ള ഒപ്റ്റിമൈസേഷനുമാണ്.

വിക്ടോറിയമെട്രിക്സ് എന്താണെന്ന് പ്രേക്ഷകരിൽ ആർക്കെങ്കിലും അറിയാമോ? കൊള്ളാം, പലർക്കും ഇതിനകം അറിയാം. അതൊരു നല്ല വാർത്തയാണ്. അറിയാത്തവർക്ക് ഇതൊരു ടൈം സീരീസ് ഡാറ്റാബേസ് ആണ്. ഇത് ClickHouse വാസ്തുവിദ്യയെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്, ClickHouse നടപ്പിലാക്കലിന്റെ ചില വിശദാംശങ്ങളിൽ. ഉദാഹരണത്തിന്, ഇനിപ്പറയുന്നവയിൽ: MergeTree, ലഭ്യമായ എല്ലാ പ്രോസസർ കോറുകളിലെയും സമാന്തര കണക്കുകൂട്ടൽ, പ്രോസസ്സർ കാഷെയിൽ സ്ഥാപിച്ചിരിക്കുന്ന ഡാറ്റ ബ്ലോക്കുകളിൽ പ്രവർത്തിച്ചുകൊണ്ട് പെർഫോമൻസ് ഒപ്റ്റിമൈസേഷൻ.

VictoriaMetrics മറ്റ് സമയ ശ്രേണി ഡാറ്റാബേസുകളേക്കാൾ മികച്ച ഡാറ്റ കംപ്രഷൻ നൽകുന്നു.

ഇത് ലംബമായി സ്കെയിൽ ചെയ്യുന്നു - അതായത്, നിങ്ങൾക്ക് ഒരു കമ്പ്യൂട്ടറിൽ കൂടുതൽ പ്രോസസ്സറുകൾ, കൂടുതൽ റാം ചേർക്കാൻ കഴിയും. VictoriaMetrics ഈ ലഭ്യമായ വിഭവങ്ങൾ വിജയകരമായി വിനിയോഗിക്കുകയും രേഖീയ ഉൽപ്പാദനക്ഷമത മെച്ചപ്പെടുത്തുകയും ചെയ്യും.

VictoriaMetrics തിരശ്ചീനമായും സ്കെയിലുചെയ്യുന്നു - അതായത്, നിങ്ങൾക്ക് VictoriaMetrics ക്ലസ്റ്ററിലേക്ക് അധിക നോഡുകൾ ചേർക്കാൻ കഴിയും, അതിന്റെ പ്രകടനം ഏതാണ്ട് രേഖീയമായി വർദ്ധിക്കും.

നിങ്ങൾ ഊഹിച്ചതുപോലെ, VictoriaMetrics ഒരു വേഗതയേറിയ ഡാറ്റാബേസാണ്, കാരണം എനിക്ക് മറ്റുള്ളവരെ എഴുതാൻ കഴിയില്ല. അത് Go-യിൽ എഴുതിയിരിക്കുന്നു, അതിനാൽ ഈ മീറ്റിംഗിൽ ഞാൻ അതിനെക്കുറിച്ച് സംസാരിക്കുന്നു.

ടൈം സീരീസ് എന്താണെന്ന് ആർക്കറിയാം? അവനും ഒരുപാട് പേരെ അറിയാം. ജോഡികളുടെ ഒരു പരമ്പരയാണ് സമയ ശ്രേണി (timestamp, значение), ഈ ജോഡികൾ സമയം അനുസരിച്ച് അടുക്കുന്നു. മൂല്യം ഒരു ഫ്ലോട്ടിംഗ് പോയിന്റ് നമ്പറാണ് - float64.

ഓരോ സമയ ശ്രേണിയും ഒരു കീ ഉപയോഗിച്ച് അദ്വിതീയമായി തിരിച്ചറിയുന്നു. ഈ കീ എന്താണ് ഉൾക്കൊള്ളുന്നത്? കീ-മൂല്യം ജോഡികളുടെ ശൂന്യമല്ലാത്ത ഒരു കൂട്ടം ഇതിൽ അടങ്ങിയിരിക്കുന്നു.

ഒരു സമയ ശ്രേണിയുടെ ഒരു ഉദാഹരണം ഇതാ. ഈ സീരീസിന്റെ താക്കോൽ ജോഡികളുടെ ഒരു പട്ടികയാണ്: __name__="cpu_usage" മെട്രിക്കിന്റെ പേരാണ്, instance="my-server" - ഈ മെട്രിക് ശേഖരിക്കുന്ന കമ്പ്യൂട്ടറാണിത്, datacenter="us-east" - ഈ കമ്പ്യൂട്ടർ സ്ഥിതി ചെയ്യുന്ന ഡാറ്റാ സെന്റർ ഇതാണ്.

മൂന്ന് കീ-മൂല്യം ജോഡികൾ അടങ്ങുന്ന ഒരു സമയ ശ്രേണി നാമത്തിൽ ഞങ്ങൾ അവസാനിപ്പിച്ചു. ഈ കീ ജോഡികളുടെ ഒരു ലിസ്റ്റുമായി യോജിക്കുന്നു (timestamp, value). t1, t3, t3, ..., tN - ഇവ ടൈംസ്റ്റാമ്പുകളാണ്, 10, 20, 12, ..., 15 - അനുബന്ധ മൂല്യങ്ങൾ. തന്നിരിക്കുന്ന വരിയുടെ ഒരു നിശ്ചിത സമയത്തെ cpu-ഉപയോഗമാണിത്.

സമയ ശ്രേണി എവിടെ ഉപയോഗിക്കാം? ആർക്കെങ്കിലും എന്തെങ്കിലും ധാരണയുണ്ടോ?

• DevOps-ൽ, നിങ്ങൾക്ക് CPU, RAM, നെറ്റ്‌വർക്ക്, rps, പിശകുകളുടെ എണ്ണം മുതലായവ അളക്കാൻ കഴിയും.
• IoT - നമുക്ക് താപനില, മർദ്ദം, ജിയോ കോർഡിനേറ്റുകൾ എന്നിവയും മറ്റെന്തെങ്കിലും അളക്കാൻ കഴിയും.
• ധനകാര്യവും - എല്ലാത്തരം സ്റ്റോക്കുകളുടെയും കറൻസികളുടെയും വിലകൾ നമുക്ക് നിരീക്ഷിക്കാനാകും.
• കൂടാതെ, ഫാക്ടറികളിലെ ഉൽപ്പാദന പ്രക്രിയകൾ നിരീക്ഷിക്കുന്നതിന് സമയ ശ്രേണി ഉപയോഗിക്കാം. റോബോട്ടുകൾക്കായി കാറ്റ് ടർബൈനുകൾ നിരീക്ഷിക്കാൻ VictoriaMetrics ഉപയോഗിക്കുന്ന ഉപയോക്താക്കളുണ്ട്.
• വിവിധ ഉപകരണങ്ങളുടെ സെൻസറുകളിൽ നിന്ന് വിവരങ്ങൾ ശേഖരിക്കുന്നതിനും സമയ ശ്രേണി ഉപയോഗപ്രദമാണ്. ഉദാഹരണത്തിന്, ഒരു എഞ്ചിന്; ടയർ മർദ്ദം അളക്കുന്നതിന്; വേഗത, ദൂരം അളക്കുന്നതിന്; ഗ്യാസോലിൻ ഉപഭോഗം മുതലായവ അളക്കുന്നതിന്.
• വിമാനങ്ങളെ നിരീക്ഷിക്കാനും സമയ ശ്രേണി ഉപയോഗിക്കാം. ഓരോ വിമാനത്തിനും ഒരു ബ്ലാക്ക് ബോക്‌സ് ഉണ്ട്, അത് വിമാനത്തിന്റെ ആരോഗ്യത്തിന്റെ വിവിധ പാരാമീറ്ററുകൾക്കായി സമയ ശ്രേണി ശേഖരിക്കുന്നു. എയ്‌റോസ്‌പേസ് വ്യവസായത്തിലും സമയ ശ്രേണികൾ ഉപയോഗിക്കുന്നു.
• രക്തസമ്മർദ്ദം, പൾസ് മുതലായവയാണ് ആരോഗ്യ സംരക്ഷണം.

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

എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് ഒരു സമയ ശ്രേണി ഡാറ്റാബേസ് വേണ്ടത്? സമയ ശ്രേണി സംഭരിക്കാൻ നിങ്ങൾക്ക് എന്തുകൊണ്ട് ഒരു സാധാരണ റിലേഷണൽ ഡാറ്റാബേസ് ഉപയോഗിക്കാൻ കഴിയില്ല?

കാരണം, സാധാരണ ഡാറ്റാബേസുകളിൽ സംഭരിക്കാനും പ്രോസസ്സ് ചെയ്യാനും ബുദ്ധിമുട്ടുള്ള വലിയ അളവിലുള്ള വിവരങ്ങൾ സമയ ശ്രേണിയിൽ അടങ്ങിയിരിക്കുന്നു. അതിനാൽ, സമയ ശ്രേണികൾക്കുള്ള പ്രത്യേക ഡാറ്റാബേസുകൾ പ്രത്യക്ഷപ്പെട്ടു. ഈ അടിസ്ഥാനങ്ങൾ ഫലപ്രദമായി പോയിന്റുകൾ സംഭരിക്കുന്നു (timestamp, value) തന്നിരിക്കുന്ന കീ ഉപയോഗിച്ച്. അവർ സംഭരിച്ച ഡാറ്റ കീ വഴിയോ ഒരു കീ-മൂല്യം ജോടി വഴിയോ ഒന്നിലധികം കീ-മൂല്യം ജോഡികൾ വഴിയോ അല്ലെങ്കിൽ regexp വഴിയോ വായിക്കുന്നതിന് ഒരു API നൽകുന്നു. ഉദാഹരണത്തിന്, അമേരിക്കയിലെ ഒരു ഡാറ്റാ സെന്ററിൽ നിങ്ങളുടെ എല്ലാ സേവനങ്ങളുടെയും സിപിയു ലോഡ് കണ്ടെത്താൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു, തുടർന്ന് നിങ്ങൾ ഈ വ്യാജ അന്വേഷണം ഉപയോഗിക്കേണ്ടതുണ്ട്.

സാധാരണയായി സമയ ശ്രേണി ഡാറ്റാബേസുകൾ പ്രത്യേക അന്വേഷണ ഭാഷകൾ നൽകുന്നു, കാരണം സമയ ശ്രേണി SQL വളരെ അനുയോജ്യമല്ല. SQL-നെ പിന്തുണയ്ക്കുന്ന ഡാറ്റാബേസുകൾ ഉണ്ടെങ്കിലും, അത് അത്ര അനുയോജ്യമല്ല. തുടങ്ങിയ ഭാഷകൾ അന്വേഷിക്കുക PromQL, InfluxQL, ഒഴുകുക, Q. ഈ ഭാഷകളിലൊന്നെങ്കിലും ആരെങ്കിലും കേട്ടിട്ടുണ്ടാകുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. PromQL നെ കുറിച്ച് പലരും കേട്ടിട്ടുണ്ടാകും. ഇതാണ് പ്രോമിത്യൂസ് അന്വേഷണ ഭാഷ.

ഒരു ആധുനിക സമയ ശ്രേണി ഡാറ്റാബേസ് ആർക്കിടെക്ചർ വിക്ടോറിയമെട്രിക്സ് ഒരു ഉദാഹരണമായി ഉപയോഗിക്കുന്നത് ഇങ്ങനെയാണ്.

ഇത് രണ്ട് ഭാഗങ്ങൾ ഉൾക്കൊള്ളുന്നു. ഇത് വിപരീത സൂചികയ്ക്കുള്ള സംഭരണവും സമയ ശ്രേണി മൂല്യങ്ങൾക്കുള്ള സംഭരണവുമാണ്. ഈ സംഭരണികൾ വേർതിരിച്ചിരിക്കുന്നു.

ഡാറ്റാബേസിൽ ഒരു പുതിയ റെക്കോർഡ് വരുമ്പോൾ, നൽകിയിരിക്കുന്ന സെറ്റിന്റെ സമയ ശ്രേണി ഐഡന്റിഫയർ കണ്ടെത്താൻ ഞങ്ങൾ ആദ്യം വിപരീത സൂചികയിലേക്ക് പ്രവേശിക്കുന്നു label=value തന്നിരിക്കുന്ന മെട്രിക്കിന്. ഞങ്ങൾ ഈ ഐഡന്റിഫയർ കണ്ടെത്തുകയും ഡാറ്റ സ്റ്റോറിൽ മൂല്യം സംരക്ഷിക്കുകയും ചെയ്യുന്നു.

TSDB-യിൽ നിന്ന് ഡാറ്റ വീണ്ടെടുക്കാൻ ഒരു അഭ്യർത്ഥന വരുമ്പോൾ, ഞങ്ങൾ ആദ്യം വിപരീത സൂചികയിലേക്ക് പോകുന്നു. എല്ലാം നേടട്ടെ timeseries_ids ഈ സെറ്റുമായി പൊരുത്തപ്പെടുന്ന റെക്കോർഡുകൾ label=value. തുടർന്ന് ഇൻഡെക്സ് ചെയ്ത ഡാറ്റ വെയർഹൗസിൽ നിന്ന് ആവശ്യമായ എല്ലാ ഡാറ്റയും നമുക്ക് ലഭിക്കും timeseries_ids.

ഒരു ടൈം സീരീസ് ഡാറ്റാബേസ് ഒരു ഇൻകമിംഗ് തിരഞ്ഞെടുത്ത ചോദ്യം എങ്ങനെ പ്രോസസ്സ് ചെയ്യുന്നു എന്നതിന്റെ ഒരു ഉദാഹരണം നോക്കാം.

• ഒന്നാമതായി, അവൾക്ക് എല്ലാം ലഭിക്കുന്നു timeseries_ids നൽകിയിരിക്കുന്ന ജോഡികൾ ഉൾക്കൊള്ളുന്ന ഒരു വിപരീത സൂചികയിൽ നിന്ന് label=value, അല്ലെങ്കിൽ നൽകിയിരിക്കുന്ന പതിവ് പദപ്രയോഗം തൃപ്തിപ്പെടുത്തുക.
• തുടർന്ന്, കണ്ടെത്തിയവയ്‌ക്കായി ഒരു നിശ്ചിത സമയ ഇടവേളയിൽ ഡാറ്റ സംഭരണത്തിൽ നിന്ന് എല്ലാ ഡാറ്റ പോയിന്റുകളും അത് വീണ്ടെടുക്കുന്നു timeseries_ids.
• ഇതിനുശേഷം, ഉപയോക്താവിന്റെ അഭ്യർത്ഥന അനുസരിച്ച് ഡാറ്റാബേസ് ഈ ഡാറ്റ പോയിന്റുകളിൽ ചില കണക്കുകൂട്ടലുകൾ നടത്തുന്നു. അതിനുശേഷം അത് ഉത്തരം നൽകുന്നു.

ഈ അവതരണത്തിൽ ഞാൻ ആദ്യ ഭാഗത്തെക്കുറിച്ച് നിങ്ങളോട് പറയും. ഇതൊരു അന്വേഷണമാണ് timeseries_ids വിപരീത സൂചിക പ്രകാരം. രണ്ടാം ഭാഗവും മൂന്നാം ഭാഗവും പിന്നീട് കാണാം വിക്ടോറിയമെട്രിക്സ് ഉറവിടങ്ങൾ, അല്ലെങ്കിൽ ഞാൻ മറ്റ് റിപ്പോർട്ടുകൾ തയ്യാറാക്കുന്നത് വരെ കാത്തിരിക്കുക :)

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

ഇത് യഥാർത്ഥത്തിൽ ലളിതമാണ്. ഒരു മൂല്യത്തിലേക്കുള്ള താക്കോൽ മാപ്പ് ചെയ്യുന്ന ഒരു നിഘണ്ടു മാത്രമാണിത്. ഒരു താക്കോൽ എന്താണ്? ഈ ദമ്പതികൾ label=valueഎവിടെ label и value - ഇവ വരികളാണ്. മൂല്യങ്ങൾ ഒരു സെറ്റാണ് timeseries_ids, നൽകിയിരിക്കുന്ന ജോഡി ഉൾപ്പെടുന്നു label=value.

വിപരീത സൂചിക എല്ലാം വേഗത്തിൽ കണ്ടെത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു timeseries_ids, നൽകിയത് label=value.

വേഗത്തിൽ കണ്ടെത്താനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു timeseries_ids നിരവധി ജോഡികൾക്കുള്ള സമയ ശ്രേണി label=value, അല്ലെങ്കിൽ ദമ്പതികൾക്ക് label=regexp. ഇത് എങ്ങനെ സംഭവിക്കുന്നു? സെറ്റിന്റെ കവല കണ്ടെത്തുന്നതിലൂടെ timeseries_ids ഓരോ ജോഡിക്കും label=value.

വിപരീത സൂചികയുടെ വിവിധ നടപ്പാക്കലുകൾ നോക്കാം. ഏറ്റവും ലളിതമായ നിഷ്കളങ്കമായ നടപ്പാക്കലിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം. അവൾ ഇതുപോലെ കാണപ്പെടുന്നു.

ഫംഗ്ഷൻ getMetricIDs സ്ട്രിംഗുകളുടെ ഒരു ലിസ്റ്റ് ലഭിക്കുന്നു. ഓരോ വരിയിലും അടങ്ങിയിരിക്കുന്നു label=value. ഈ ഫംഗ്‌ഷൻ ഒരു ലിസ്റ്റ് നൽകുന്നു metricIDs.

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു? ഇവിടെ നമുക്ക് ഒരു ആഗോള വേരിയബിൾ ഉണ്ട് invertedIndex. ഇതൊരു സാധാരണ നിഘണ്ടു ആണ് (map), ഇത് സ്‌ലൈസ് ഇൻറ്റുകൾക്ക് സ്ട്രിംഗ് മാപ്പ് ചെയ്യും. വരിയിൽ അടങ്ങിയിരിക്കുന്നു label=value.

ഫംഗ്ഷൻ നടപ്പിലാക്കൽ: നേടുക metricIDs ആദ്യമായി label=value, പിന്നെ നമ്മൾ മറ്റെല്ലാ കാര്യങ്ങളിലൂടെയും കടന്നുപോകുന്നു label=value, നമുക്കത് കിട്ടും metricIDs അവർക്കുവേണ്ടി. ഒപ്പം ഫംഗ്‌ഷനെ വിളിക്കുക intersectInts, അത് താഴെ ചർച്ച ചെയ്യും. ഈ ഫംഗ്‌ഷൻ ഈ ലിസ്റ്റുകളുടെ കവലയെ തിരികെ നൽകുന്നു.

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

രണ്ടാമത്തെ പോരായ്മയും മെമ്മറിയുമായി ബന്ധപ്പെട്ടതാണ്. വിപരീത സൂചിക റാമിലേക്ക് യോജിപ്പിക്കണം. ഇത് റാമിന്റെ വലുപ്പം കവിയുന്നുവെങ്കിൽ, വ്യക്തമായും നമുക്ക് ലഭിക്കും - മെമ്മറി പിശക്. കൂടാതെ പ്രോഗ്രാം പ്രവർത്തിക്കില്ല.

പോലുള്ള റെഡിമെയ്ഡ് പരിഹാരങ്ങൾ ഉപയോഗിച്ച് ഈ പ്രശ്നം പരിഹരിക്കാൻ കഴിയും ലെവൽ‌ഡിബി, അല്ലെങ്കിൽ RocksDB.

ചുരുക്കത്തിൽ, മൂന്ന് പ്രവർത്തനങ്ങൾ വേഗത്തിൽ ചെയ്യാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ഒരു ഡാറ്റാബേസ് ആവശ്യമാണ്.

• ആദ്യ പ്രവർത്തനം റെക്കോർഡിംഗ് ആണ് ключ-значение ഈ ഡാറ്റാബേസിലേക്ക്. അവൾ ഇത് വളരെ വേഗത്തിൽ ചെയ്യുന്നു, എവിടെ ключ-значение ഏകപക്ഷീയമായ സ്ട്രിംഗുകളാണ്.
• തന്നിരിക്കുന്ന കീ ഉപയോഗിച്ച് ഒരു മൂല്യത്തിനായുള്ള ദ്രുത തിരയലാണ് രണ്ടാമത്തെ പ്രവർത്തനം.
• തന്നിരിക്കുന്ന പ്രിഫിക്‌സ് ഉപയോഗിച്ച് എല്ലാ മൂല്യങ്ങൾക്കും വേണ്ടിയുള്ള ദ്രുത തിരയലാണ് മൂന്നാമത്തെ പ്രവർത്തനം.

LevelDB, RocksDB - ഈ ഡാറ്റാബേസുകൾ ഗൂഗിളും ഫേസ്ബുക്കും വികസിപ്പിച്ചതാണ്. ആദ്യം വന്നത് LevelDB. തുടർന്ന് ഫേസ്ബുക്കിൽ നിന്നുള്ള ആളുകൾ ലെവൽ ഡിബി എടുത്ത് അത് മെച്ചപ്പെടുത്താൻ തുടങ്ങി, അവർ റോക്സ് ഡിബി ഉണ്ടാക്കി. ഇപ്പോൾ RocksDB, MySQL എന്നിവയിലേക്ക് കൈമാറ്റം ചെയ്യപ്പെട്ടവ ഉൾപ്പെടെ മിക്കവാറും എല്ലാ ആന്തരിക ഡാറ്റാബേസുകളും Facebook-ൽ RocksDB-യിൽ പ്രവർത്തിക്കുന്നു. അവർ അവന് പേരിട്ടു മൈറോക്ക്സ്.

LevelDB ഉപയോഗിച്ച് ഒരു വിപരീത സൂചിക നടപ്പിലാക്കാൻ കഴിയും. ഇത് എങ്ങനെ ചെയ്യാം? ഞങ്ങൾ ഒരു കീ ആയി സംരക്ഷിക്കുന്നു label=value. ഒപ്പം മൂല്യം ജോഡി നിലവിലിരിക്കുന്ന സമയ ശ്രേണിയുടെ ഐഡന്റിഫയർ ആണ് label=value.

നൽകിയിരിക്കുന്ന ജോഡിയുമായി നമുക്ക് നിരവധി സമയ പരമ്പരകൾ ഉണ്ടെങ്കിൽ label=value, അപ്പോൾ ഈ ഡാറ്റാബേസിൽ ഒരേ കീയും വ്യത്യസ്തവുമായ നിരവധി വരികൾ ഉണ്ടാകും timeseries_ids. എല്ലാവരുടെയും ഒരു ലിസ്റ്റ് ലഭിക്കാൻ timeseries_ids, ഇതിൽ തുടങ്ങുന്നു label=prefix, ഈ ഡാറ്റാബേസ് ഒപ്റ്റിമൈസ് ചെയ്ത ഒരു റേഞ്ച് സ്കാൻ ഞങ്ങൾ നടത്തുന്നു. അതായത്, ആരംഭിക്കുന്ന എല്ലാ വരികളും ഞങ്ങൾ തിരഞ്ഞെടുക്കുന്നു label=prefix ആവശ്യമുള്ളത് നേടുകയും ചെയ്യുക timeseries_ids.

Go-ൽ ഇത് എങ്ങനെയായിരിക്കുമെന്നതിന്റെ ഒരു സാമ്പിൾ നടപ്പിലാക്കൽ ഇതാ. ഞങ്ങൾക്ക് ഒരു വിപരീത സൂചികയുണ്ട്. ഇതാണ് LevelDB.

നിഷ്കളങ്കമായ നിർവ്വഹണത്തിന് തുല്യമാണ് പ്രവർത്തനം. ഇത് നിഷ്കളങ്കമായ നടപ്പാക്കൽ ഏതാണ്ട് വരി വരിയായി ആവർത്തിക്കുന്നു. തിരിയുന്നതിനുപകരം എന്നതാണ് ഒരേയൊരു കാര്യം map ഞങ്ങൾ വിപരീത സൂചികയിലേക്ക് പ്രവേശിക്കുന്നു. ആദ്യത്തേതിന്റെ എല്ലാ മൂല്യങ്ങളും നമുക്ക് ലഭിക്കും label=value. പിന്നെ നമ്മൾ ബാക്കിയുള്ള എല്ലാ ജോഡികളിലൂടെയും കടന്നുപോകുന്നു label=value അവയ്‌ക്കായി മെട്രിക്‌ഐഡികളുടെ അനുബന്ധ സെറ്റുകൾ നേടുക. അപ്പോൾ ഞങ്ങൾ കവല കണ്ടെത്തുന്നു.

എല്ലാം ശരിയാണെന്ന് തോന്നുന്നു, പക്ഷേ ഈ പരിഹാരത്തിന് പോരായ്മകളുണ്ട്. VictoriaMetrics തുടക്കത്തിൽ LevelDB അടിസ്ഥാനമാക്കി ഒരു വിപരീത സൂചിക നടപ്പിലാക്കി. പക്ഷെ അവസാനം എനിക്ക് അത് ഉപേക്ഷിക്കേണ്ടി വന്നു.

എന്തുകൊണ്ട്? കാരണം LevelDB നിഷ്കളങ്കമായി നടപ്പിലാക്കുന്നതിനേക്കാൾ മന്ദഗതിയിലാണ്. ഒരു നിഷ്കളങ്കമായ നിർവ്വഹണത്തിൽ, നൽകിയിരിക്കുന്ന ഒരു കീ നൽകിയാൽ, ഞങ്ങൾ ഉടനടി മുഴുവൻ സ്ലൈസും വീണ്ടെടുക്കുന്നു metricIDs. ഇത് വളരെ വേഗത്തിലുള്ള പ്രവർത്തനമാണ് - മുഴുവൻ സ്ലൈസും ഉപയോഗത്തിന് തയ്യാറാണ്.

ലെവൽഡിബിയിൽ, ഓരോ തവണയും ഒരു ഫംഗ്‌ഷൻ വിളിക്കപ്പെടുന്നു GetValues ആരംഭിക്കുന്ന എല്ലാ വരികളിലൂടെയും നിങ്ങൾ പോകേണ്ടതുണ്ട് label=value. കൂടാതെ ഓരോ വരിയുടെയും മൂല്യം നേടുക timeseries_ids. അത്തരം timeseries_ids ഇവയുടെ ഒരു കഷ്ണം ശേഖരിക്കുക timeseries_ids. വ്യക്തമായും, ഇത് കീ ഉപയോഗിച്ച് ഒരു സാധാരണ മാപ്പ് ആക്‌സസ് ചെയ്യുന്നതിനേക്കാൾ വളരെ മന്ദഗതിയിലാണ്.

ലെവൽഡിബി സിയിൽ എഴുതിയിരിക്കുന്നു എന്നതാണ് രണ്ടാമത്തെ പോരായ്മ. ഗോയിൽ നിന്നുള്ള സി ഫംഗ്‌ഷനുകൾ വിളിക്കുന്നത് വളരെ വേഗതയുള്ളതല്ല. ഇതിന് നൂറുകണക്കിന് നാനോ സെക്കൻഡുകൾ എടുക്കും. ഇത് വളരെ വേഗമേറിയതല്ല, കാരണം 1-5 നാനോസെക്കൻഡ് എടുക്കുന്ന go- ൽ എഴുതപ്പെട്ട ഒരു സാധാരണ ഫംഗ്‌ഷൻ കോളുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ, പ്രകടനത്തിലെ വ്യത്യാസം പതിനായിരക്കണക്കിന് മടങ്ങാണ്. വിക്ടോറിയമെട്രിക്സിനെ സംബന്ധിച്ചിടത്തോളം ഇത് ഒരു മാരകമായ പിഴവായിരുന്നു :)

അതിനാൽ ഞാൻ വിപരീത സൂചികയുടെ സ്വന്തം നടപ്പാക്കൽ എഴുതി. അവൻ അവളെ വിളിച്ചു ലയിപ്പിക്കുക.

MergeTree ഡാറ്റാ ഘടനയെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് Mergeset. ഈ ഡാറ്റാ ഘടന ClickHouse-ൽ നിന്ന് കടമെടുത്തതാണ്. വ്യക്തമായും, വേഗത്തിലുള്ള തിരയലിനായി ലയനം ഒപ്റ്റിമൈസ് ചെയ്യണം timeseries_ids നൽകിയിരിക്കുന്ന കീ പ്രകാരം. മെർജെസെറ്റ് പൂർണ്ണമായും ഗോയിലാണ് എഴുതിയിരിക്കുന്നത്. നിങ്ങൾക്ക് കാണാൻ കഴിയും GitHub-ലെ VictoriaMetrics ഉറവിടങ്ങൾ. മെർജസെറ്റ് നടപ്പിലാക്കുന്നത് ഫോൾഡറിലാണ് /lib/mergeset. അവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസിലാക്കാൻ നിങ്ങൾക്ക് ശ്രമിക്കാം.

ലയന API LevelDB, RocksDB എന്നിവയുമായി വളരെ സാമ്യമുള്ളതാണ്. അതായത്, പുതിയ റെക്കോർഡുകൾ അവിടെ വേഗത്തിൽ സംരക്ഷിക്കാനും തന്നിരിക്കുന്ന പ്രിഫിക്‌സ് ഉപയോഗിച്ച് റെക്കോർഡുകൾ വേഗത്തിൽ തിരഞ്ഞെടുക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

ലയനത്തിന്റെ പോരായ്മകളെക്കുറിച്ച് നമുക്ക് പിന്നീട് സംസാരിക്കാം. ഒരു വിപരീത സൂചിക നടപ്പിലാക്കുമ്പോൾ ഉൽ‌പാദനത്തിൽ വിക്ടോറിയമെട്രിക്സിൽ എന്ത് പ്രശ്‌നങ്ങളാണ് ഉണ്ടായതെന്ന് ഇപ്പോൾ നമുക്ക് സംസാരിക്കാം.

എന്തുകൊണ്ടാണ് അവ ഉടലെടുത്തത്?

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

രണ്ടാമത്തെ കാരണം സമയ ശ്രേണികളുടെ വലിയ സംഖ്യയാണ്. തുടക്കത്തിൽ, നിരീക്ഷണം പ്രചാരം നേടുമ്പോൾ, സമയ ശ്രേണികളുടെ എണ്ണം കുറവായിരുന്നു. ഉദാഹരണത്തിന്, ഓരോ കമ്പ്യൂട്ടറിനും നിങ്ങൾ സിപിയു, മെമ്മറി, നെറ്റ്‌വർക്ക്, ഡിസ്ക് ലോഡ് എന്നിവ നിരീക്ഷിക്കേണ്ടതുണ്ട്. ഒരു കമ്പ്യൂട്ടറിന് 4 സമയ ശ്രേണി. നിങ്ങൾക്ക് 100 കമ്പ്യൂട്ടറുകളും 400 സമയ ശ്രേണിയും ഉണ്ടെന്ന് പറയാം. ഇത് വളരെ കുറവാണ്.

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

എന്നാൽ അത് മാത്രമല്ല. ഓരോ പ്രോസസർ കോറിനും നിഷ്‌ക്രിയമായിരിക്കുമ്പോൾ നിഷ്‌ക്രിയം പോലുള്ള നിരവധി അവസ്ഥകൾ ഉണ്ടാകാം. കൂടാതെ യൂസർ സ്‌പെയ്‌സിലും കേർണൽ സ്‌പെയ്‌സിലും മറ്റ് സ്‌റ്റേറ്റുകളിലും പ്രവർത്തിക്കുക. അത്തരത്തിലുള്ള ഓരോ അവസ്ഥയും ഒരു പ്രത്യേക സമയ ശ്രേണിയായി കണക്കാക്കാം. ഇത് വരികളുടെ എണ്ണം 7-8 മടങ്ങ് വർദ്ധിപ്പിക്കുന്നു.

ഒരു മെട്രിക്കിൽ നിന്ന് ഒരു കമ്പ്യൂട്ടറിന് 40 x 8 = 320 മെട്രിക്‌സ് ലഭിച്ചു. 100 കൊണ്ട് ഗുണിച്ചാൽ നമുക്ക് 32-ന് പകരം 000 ലഭിക്കും.

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

ഉയർന്ന ചോർച്ച നിരക്ക് നമുക്ക് സൂക്ഷ്മമായി പരിശോധിക്കാം. ഉൽപ്പാദനത്തിൽ ഉയർന്ന ചോർച്ച നിരക്ക് ഉണ്ടാകുന്നത് എന്താണ്? കാരണം ലേബലുകളുടെയും ടാഗുകളുടെയും ചില അർത്ഥങ്ങൾ നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്നു.

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

ഇത് എന്തിലേക്ക് നയിച്ചു? മാത്രമല്ല, ഓരോ പുതിയ വിന്യാസത്തിലും, എല്ലാ പഴയ സമയ ശ്രേണികളും തടസ്സപ്പെടുന്നു, അവയ്‌ക്ക് പകരം, പുതിയ സമയ ശ്രേണി ഒരു പുതിയ ലേബൽ മൂല്യത്തിൽ ആരംഭിക്കുന്നു deployment_id. അത്തരം വരികൾ നൂറുകണക്കിന് ആയിരങ്ങളും ദശലക്ഷക്കണക്കിന് പോലും ഉണ്ടാകാം.

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

ഒരു നിശ്ചിത സമയ ഇടവേളയിൽ നൽകിയിരിക്കുന്ന ഒരു കൂട്ടം ലേബലുകൾക്കായി എല്ലാ സമയ ശ്രേണിയിലും സ്ഥിരമായ തിരയൽ വേഗത ഉറപ്പാക്കുക എന്നതാണ് ഉയർന്ന ചോർച്ച നിരക്കിന്റെ പ്രധാന പ്രശ്നം. സാധാരണ ഇത് അവസാന മണിക്കൂറിലെയോ അവസാന ദിവസത്തേയോ ഉള്ള സമയ ഇടവേളയാണ്.

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

ഈ വിപരീത സൂചികകളിൽ നിന്ന് സാമ്പിൾ ചെയ്യുമ്പോൾ, നൽകിയിരിക്കുന്ന ഇടവേളയിൽ വരുന്ന ഒരു കൂട്ടം വിപരീത സൂചികകൾ ഞങ്ങൾ കണ്ടെത്തുന്നു. അതനുസരിച്ച്, ഞങ്ങൾ അവിടെ നിന്ന് സമയ ശ്രേണിയുടെ ഐഡി തിരഞ്ഞെടുക്കുന്നു.

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

ഈ പ്രശ്നം പരിഹരിക്കാൻ മറ്റൊരു ഓപ്ഷൻ ഉണ്ട്. ഇത് ഓരോ ദിവസവും ആ ദിവസം സംഭവിച്ച സമയ ശ്രേണിയുടെ ഐഡികളുടെ പ്രത്യേക ലിസ്റ്റ് സംഭരിക്കുന്നതിനാണ്.

മുമ്പത്തെ പരിഹാരത്തേക്കാൾ ഈ പരിഹാരത്തിന്റെ പ്രയോജനം, കാലക്രമേണ അപ്രത്യക്ഷമാകാത്ത സമയ ശ്രേണി വിവരങ്ങൾ ഞങ്ങൾ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുന്നില്ല എന്നതാണ്. അവ നിരന്തരം നിലനിൽക്കുന്നു, മാറുന്നില്ല.

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

എനിക്ക് അവളോട് യുദ്ധം ചെയ്യേണ്ടിവന്നു. ഈ നിർവ്വഹണത്തിൽ നിങ്ങൾ ഇനിയും ഒരു വലിയ സംഖ്യ തിരഞ്ഞെടുക്കേണ്ടതുണ്ട് എന്നതായിരുന്നു സമരം timeseries_ids വിപരീത സൂചിക സമയം പാർട്ടീഷൻ ചെയ്യുമ്പോൾ ഡാറ്റയ്ക്ക്.

ഈ പ്രശ്നം ഞങ്ങൾ എങ്ങനെ പരിഹരിച്ചു? ഒരു ഐഡന്റിഫയറിന് പകരം ഓരോ വിപരീത സൂചിക എൻട്രിയിലും നിരവധി ടൈം സീരീസ് ഐഡന്റിഫയറുകൾ സംഭരിച്ചുകൊണ്ട് ഞങ്ങൾ അത് യഥാർത്ഥ രീതിയിൽ പരിഹരിച്ചു. അതായത്, ഞങ്ങൾക്ക് ഒരു താക്കോൽ ഉണ്ട് label=value, ഇത് എല്ലാ സമയ ശ്രേണിയിലും സംഭവിക്കുന്നു. ഇപ്പോൾ ഞങ്ങൾ പലതും സംരക്ഷിക്കുന്നു timeseries_ids ഒരു എൻട്രിയിൽ.

ഇതാ ഒരു ഉദാഹരണം. മുമ്പ് ഞങ്ങൾക്ക് N എൻട്രികൾ ഉണ്ടായിരുന്നു, എന്നാൽ ഇപ്പോൾ ഞങ്ങൾക്ക് ഒരു എൻട്രി ഉണ്ട്, അതിന്റെ പ്രിഫിക്‌സ് മറ്റെല്ലാവർക്കും തുല്യമാണ്. മുമ്പത്തെ എൻട്രിക്ക്, മൂല്യത്തിൽ എല്ലാ സമയ ശ്രേണി ഐഡികളും അടങ്ങിയിരിക്കുന്നു.

അത്തരമൊരു വിപരീത സൂചികയുടെ സ്കാനിംഗ് വേഗത 10 മടങ്ങ് വരെ വർദ്ധിപ്പിക്കാൻ ഇത് സാധ്യമാക്കി. കാഷെയുടെ മെമ്മറി ഉപഭോഗം കുറയ്ക്കാൻ ഇത് ഞങ്ങളെ അനുവദിച്ചു, കാരണം ഇപ്പോൾ ഞങ്ങൾ സ്ട്രിംഗ് സംഭരിക്കുന്നു label=value N തവണ ഒരുമിച്ച് കാഷെയിൽ ഒരിക്കൽ മാത്രം. നിങ്ങളുടെ ടാഗുകളിലും ലേബലുകളിലും നീണ്ട വരകൾ സംഭരിച്ചാൽ ഈ ലൈൻ വലുതായിരിക്കും, അത് കുബർനെറ്റസ് അവിടെ ചലിപ്പിക്കാൻ ഇഷ്ടപ്പെടുന്നു.

വിപരീത സൂചികയിൽ തിരയുന്നത് വേഗത്തിലാക്കുന്നതിനുള്ള മറ്റൊരു ഓപ്ഷൻ ഷാർഡിംഗ് ആണ്. ഒന്നിന് പകരം നിരവധി വിപരീത സൂചികകൾ സൃഷ്ടിക്കുകയും അവയ്ക്കിടയിൽ കീ ഉപയോഗിച്ച് ഡാറ്റ പങ്കിടുകയും ചെയ്യുന്നു. ഇതൊരു സെറ്റാണ് key=value നീരാവി. അതായത്, നമുക്ക് നിരവധി സ്വതന്ത്ര വിപരീത സൂചികകൾ ലഭിക്കുന്നു, അവ പല പ്രൊസസറുകളിലും സമാന്തരമായി അന്വേഷിക്കാൻ കഴിയും. മുമ്പത്തെ നടപ്പാക്കലുകൾ സിംഗിൾ-പ്രോസസർ മോഡിൽ മാത്രമേ പ്രവർത്തിക്കാൻ അനുവദിക്കൂ, അതായത്, ഒരു കോറിൽ മാത്രം ഡാറ്റ സ്കാൻ ചെയ്യുന്നു. ClickHouse ചെയ്യാൻ ഇഷ്ടപ്പെടുന്നതുപോലെ, ഒരേസമയം നിരവധി കോറുകളിലെ ഡാറ്റ സ്കാൻ ചെയ്യാൻ ഈ പരിഹാരം നിങ്ങളെ അനുവദിക്കുന്നു. ഇതാണ് ഞങ്ങൾ നടപ്പിലാക്കാൻ ഉദ്ദേശിക്കുന്നത്.

ഇപ്പോൾ നമുക്ക് നമ്മുടെ ആടുകളിലേക്ക് മടങ്ങാം - കവല പ്രവർത്തനത്തിലേക്ക് timeseries_ids. എന്തെല്ലാം നടപ്പാക്കലുകൾ ഉണ്ടാകുമെന്ന് നമുക്ക് നോക്കാം. ഈ ഫംഗ്ഷൻ നിങ്ങളെ കണ്ടെത്താൻ അനുവദിക്കുന്നു timeseries_ids തന്നിരിക്കുന്ന സെറ്റിനായി label=value.

ആദ്യ ഓപ്ഷൻ നിഷ്കളങ്കമായ നടപ്പാക്കലാണ്. രണ്ട് നെസ്റ്റഡ് ലൂപ്പുകൾ. ഇവിടെ നമുക്ക് ഫംഗ്ഷൻ ഇൻപുട്ട് ലഭിക്കും intersectInts രണ്ട് കഷണങ്ങൾ - a и b. ഔട്ട്പുട്ടിൽ, ഈ സ്ലൈസുകളുടെ കവലയിലേക്ക് അത് ഞങ്ങൾക്ക് തിരികെ നൽകണം.

നിഷ്കളങ്കമായ നടപ്പാക്കൽ ഇതുപോലെ കാണപ്പെടുന്നു. സ്ലൈസിൽ നിന്ന് എല്ലാ മൂല്യങ്ങളും ഞങ്ങൾ ആവർത്തിക്കുന്നു a, ഈ ലൂപ്പിനുള്ളിൽ ഞങ്ങൾ സ്ലൈസിന്റെ എല്ലാ മൂല്യങ്ങളിലൂടെയും കടന്നുപോകുന്നു b. ഞങ്ങൾ അവയെ താരതമ്യം ചെയ്യുന്നു. അവ പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, ഞങ്ങൾ ഒരു കവല കണ്ടെത്തി. ഒപ്പം അതിൽ സേവ് ചെയ്യുക result.

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

രണ്ടാമത്തെ നടപ്പാക്കൽ ഭൂപടത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഞങ്ങൾ മാപ്പ് സൃഷ്ടിക്കുന്നു. സ്ലൈസിൽ നിന്നുള്ള എല്ലാ മൂല്യങ്ങളും ഞങ്ങൾ ഈ മാപ്പിൽ ഇടുന്നു a. പിന്നെ ഞങ്ങൾ ഒരു പ്രത്യേക ലൂപ്പിൽ സ്ലൈസിലൂടെ കടന്നുപോകുന്നു b. ഈ മൂല്യം സ്ലൈസിൽ നിന്നാണോ എന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു b ഭൂപടത്തിൽ. അത് നിലവിലുണ്ടെങ്കിൽ, അത് ഫലത്തിലേക്ക് ചേർക്കുക.

എന്താണ് നേട്ടങ്ങൾ? രേഖീയ സങ്കീർണ്ണത മാത്രമേ ഉള്ളൂ എന്നതാണ് നേട്ടം. അതായത്, വലിയ സ്ലൈസുകൾക്ക് ഫംഗ്ഷൻ വളരെ വേഗത്തിൽ പ്രവർത്തിക്കും. ഒരു ദശലക്ഷക്കണക്കിന് വലിപ്പമുള്ള സ്ലൈസിന്, മുമ്പത്തെ ഫംഗ്‌ഷന്റെ ട്രില്യൺ ആവർത്തനങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, ഈ ഫംഗ്‌ഷൻ 2 ദശലക്ഷം ആവർത്തനങ്ങളിൽ നടപ്പിലാക്കും.

ഈ മാപ്പ് സൃഷ്ടിക്കാൻ ഈ ഫംഗ്‌ഷന് കൂടുതൽ മെമ്മറി ആവശ്യമാണ് എന്നതാണ് പോരായ്മ.

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

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

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

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

കൂടാതെ, മാപ്പ് നടപ്പാക്കലുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇത് വളരെ കുറച്ച് മെമ്മറി ഉപയോഗിക്കുന്നു. കാരണം ഞങ്ങൾ ഇവിടെ എട്ട്-ബൈറ്റ് മൂല്യങ്ങൾക്ക് പകരം ബിറ്റുകൾ സംഭരിക്കുന്നു.

ഈ നടപ്പാക്കലിന്റെ പോരായ്മ അത് അത്ര വ്യക്തമല്ല, നിസ്സാരമല്ല എന്നതാണ്.

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

ഈ ഘടന നടപ്പിലാക്കുന്നത് പരിഗണിക്കാം. നിങ്ങൾക്ക് നോക്കണമെങ്കിൽ, അത് വിക്ടോറിയമെട്രിക്സ് ഉറവിടങ്ങളിൽ, ഫോൾഡറിൽ സ്ഥിതിചെയ്യുന്നു lib/uint64set. വിക്ടോറിയമെട്രിക്സ് കേസിനായി ഇത് പ്രത്യേകമായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു timeseries_id ഒരു 64-ബിറ്റ് മൂല്യമാണ്, ഇവിടെ ആദ്യത്തെ 32 ബിറ്റുകൾ അടിസ്ഥാനപരമായി സ്ഥിരവും അവസാനത്തെ 32 ബിറ്റുകൾ മാത്രമേ മാറുന്നുള്ളൂ.

ഈ ഡാറ്റ ഘടന ഡിസ്കിൽ സംഭരിച്ചിട്ടില്ല, ഇത് മെമ്മറിയിൽ മാത്രം പ്രവർത്തിക്കുന്നു.

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

പ്രവർത്തനങ്ങൾ ഉണ്ട് add, ഇത് പുതിയ മൂല്യങ്ങൾ ചേർക്കുന്നു. ഒരു ചടങ്ങുണ്ട് has, ഇത് പുതിയ മൂല്യങ്ങൾ പരിശോധിക്കുന്നു. ഒപ്പം ഒരു ഫംഗ്ഷനുമുണ്ട് del, മൂല്യങ്ങൾ നീക്കം ചെയ്യുന്നു. ഒരു സഹായി പ്രവർത്തനം ഉണ്ട് len, ഇത് സെറ്റിന്റെ വലുപ്പം നൽകുന്നു. ഫംഗ്ഷൻ clone ധാരാളം ക്ലോണുകൾ. ഒപ്പം പ്രവർത്തനവും appendto ഈ സെറ്റ് സ്ലൈസിലേക്ക് പരിവർത്തനം ചെയ്യുന്നു timeseries_ids.

ഈ ഡാറ്റാ ഘടനയുടെ നടപ്പാക്കൽ ഇങ്ങനെയാണ്. സെറ്റിന് രണ്ട് ഘടകങ്ങളുണ്ട്:

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

• രണ്ടാമത്തെ ഫീൽഡ് ആണ് buckets. ഇത് ഘടനയിൽ നിന്നുള്ള സ്ലൈസാണ് bucket32. ഓരോ ഘടനയും സംഭരിക്കുന്നു hi വയൽ. ഇവയാണ് മുകളിലെ 32 ബിറ്റുകൾ. ഒപ്പം രണ്ട് കഷ്ണങ്ങളും - b16his и buckets നിന്ന് bucket16 ഘടനകൾ.

16-ബിറ്റ് ഘടനയുടെ രണ്ടാം ഭാഗത്തിന്റെ മികച്ച 64 ബിറ്റുകൾ ഇവിടെ സംഭരിച്ചിരിക്കുന്നു. ഇവിടെ ഓരോ ബൈറ്റിന്റെയും താഴത്തെ 16 ബിറ്റുകൾക്കായി ബിറ്റ്സെറ്റുകൾ സംഭരിക്കുന്നു.

Bucket64 ഒരു അറേ ഉൾക്കൊള്ളുന്നു uint64. ഈ സ്ഥിരാങ്കങ്ങൾ ഉപയോഗിച്ചാണ് നീളം കണക്കാക്കുന്നത്. ഒന്നിൽ bucket16 പരമാവധി സംഭരിക്കാൻ കഴിയും 2^16=65536 ബിറ്റ്. നിങ്ങൾ ഇതിനെ 8 കൊണ്ട് ഹരിച്ചാൽ, അത് 8 കിലോബൈറ്റ് ആണ്. നിങ്ങൾ വീണ്ടും 8 കൊണ്ട് ഹരിച്ചാൽ, അത് 1000 ആണ് uint64 അർത്ഥം. അതാണ് Bucket16 - ഇതാണ് ഞങ്ങളുടെ 8-കിലോബൈറ്റ് ഘടന.

ഒരു പുതിയ മൂല്യം ചേർക്കുന്നതിനുള്ള ഈ ഘടനയുടെ ഒരു രീതി എങ്ങനെ നടപ്പിലാക്കുന്നുവെന്ന് നോക്കാം.

എല്ലാം ആരംഭിക്കുന്നു uint64 അർത്ഥങ്ങൾ. ഞങ്ങൾ മുകളിലെ 32 ബിറ്റുകൾ കണക്കാക്കുന്നു, ഞങ്ങൾ താഴത്തെ 32 ബിറ്റുകൾ കണക്കാക്കുന്നു. നമുക്ക് എല്ലാം കടന്നുപോകാം buckets. ഓരോ ബക്കറ്റിലെയും മികച്ച 32 ബിറ്റുകളെ ഞങ്ങൾ കൂട്ടിച്ചേർക്കുന്ന മൂല്യവുമായി താരതമ്യം ചെയ്യുന്നു. അവ പൊരുത്തപ്പെടുന്നുവെങ്കിൽ, ഞങ്ങൾ ഫംഗ്ഷനെ വിളിക്കുന്നു add ഘടന b32 ൽ buckets. അവിടെ താഴെയുള്ള 32 ബിറ്റുകൾ ചേർക്കുക. പിന്നെ തിരിച്ചു വന്നാലോ true, അപ്പോൾ ഇതിനർത്ഥം ഞങ്ങൾ അവിടെ അത്തരമൊരു മൂല്യം ചേർത്തു, ഞങ്ങൾക്ക് അത്തരമൊരു മൂല്യം ഇല്ലായിരുന്നു എന്നാണ്. അത് തിരികെ വന്നാൽ false, അപ്പോൾ അത്തരമൊരു അർത്ഥം ഇതിനകം നിലവിലുണ്ടായിരുന്നു. അപ്പോൾ നമ്മൾ ഘടനയിലെ മൂലകങ്ങളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നു.

നിങ്ങൾക്ക് ആവശ്യമുള്ളത് ഞങ്ങൾ കണ്ടെത്തിയില്ലെങ്കിൽ bucket ആവശ്യമായ ഹൈ-വാല്യൂ ഉപയോഗിച്ച്, ഞങ്ങൾ ഫംഗ്ഷനെ വിളിക്കുന്നു addAlloc, അത് പുതിയൊരെണ്ണം നിർമ്മിക്കും bucket, അത് ബക്കറ്റ് ഘടനയിൽ ചേർക്കുന്നു.

ഇതാണ് ഫംഗ്ഷൻ നടപ്പിലാക്കുന്നത് b32.add. ഇത് മുമ്പത്തെ നടപ്പാക്കലിന് സമാനമാണ്. ഞങ്ങൾ ഏറ്റവും പ്രധാനപ്പെട്ട 16 ബിറ്റുകൾ കണക്കാക്കുന്നു, ഏറ്റവും കുറഞ്ഞ പ്രാധാന്യമുള്ള 16 ബിറ്റുകൾ.

അപ്പോൾ നമ്മൾ മുകളിലെ 16 ബിറ്റുകളിലേക്കും പോകുന്നു. ഞങ്ങൾ പൊരുത്തങ്ങൾ കണ്ടെത്തുന്നു. ഒരു പൊരുത്തമുണ്ടെങ്കിൽ, ഞങ്ങൾ ആഡ് രീതി എന്ന് വിളിക്കുന്നു, അത് അടുത്ത പേജിൽ ഞങ്ങൾ പരിഗണിക്കും bucket16.

ഇവിടെ ഏറ്റവും താഴ്ന്ന നിലയുണ്ട്, അത് കഴിയുന്നത്ര ഒപ്റ്റിമൈസ് ചെയ്യണം. ഞങ്ങൾ കണക്കാക്കുന്നു uint64 സ്ലൈസ് ബിറ്റിലും ഐഡി മൂല്യവും bitmask. നൽകിയിരിക്കുന്ന 64-ബിറ്റ് മൂല്യത്തിനായുള്ള മാസ്‌കാണിത്, ഈ ബിറ്റിന്റെ സാന്നിധ്യം പരിശോധിക്കുന്നതിനോ സജ്ജമാക്കുന്നതിനോ ഇത് ഉപയോഗിക്കാം. ഈ ബിറ്റ് സജ്ജീകരിച്ച് സജ്ജമാക്കിയിട്ടുണ്ടോ എന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു, കൂടാതെ സാന്നിധ്യം തിരികെ നൽകുന്നു. ഇത് ഞങ്ങളുടെ നടപ്പാക്കലാണ്, ഇത് പരമ്പരാഗത മാപ്പുകളെ അപേക്ഷിച്ച് സമയ ശ്രേണിയുടെ വിഭജിക്കുന്ന ഐഡികളുടെ പ്രവർത്തനം 10 മടങ്ങ് വേഗത്തിലാക്കാൻ ഞങ്ങളെ അനുവദിച്ചു.

ഈ ഒപ്റ്റിമൈസേഷന് പുറമേ, വിക്ടോറിയമെട്രിക്സിന് മറ്റ് നിരവധി ഒപ്റ്റിമൈസേഷനുകളുണ്ട്. ഈ ഒപ്റ്റിമൈസേഷനുകളിൽ ഭൂരിഭാഗവും ഒരു കാരണത്താൽ ചേർത്തു, പക്ഷേ പ്രൊഡക്ഷനിൽ കോഡ് പ്രൊഫൈൽ ചെയ്തതിന് ശേഷം.

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

ബിറ്റ്സെറ്റിനെക്കുറിച്ച് എനിക്ക് ഒരു ചോദ്യമുണ്ട്. ഒപ്റ്റിമൈസ് ചെയ്ത ബിറ്റ്സെറ്റ്, C++ വെക്റ്റർ ബൂൾ നടപ്പിലാക്കലിനോട് വളരെ സാമ്യമുണ്ട്. അവിടെ നിന്നാണോ നടപ്പാക്കൽ എടുത്തത്?

ഇല്ല, അവിടെ നിന്നല്ല. ഈ ബിറ്റ്സെറ്റ് നടപ്പിലാക്കുമ്പോൾ, വിക്ടോറിയമെട്രിക്സിൽ ഉപയോഗിക്കുന്ന ഈ ഐഡികളുടെ ടൈംസറികളുടെ ഘടനയെക്കുറിച്ചുള്ള അറിവാണ് എന്നെ നയിച്ചത്. അവയുടെ ഘടന മുകളിലെ 32 ബിറ്റുകൾ അടിസ്ഥാനപരമായി സ്ഥിരമായിരിക്കും. താഴെയുള്ള 32 ബിറ്റുകൾ മാറ്റത്തിന് വിധേയമാണ്. കുറഞ്ഞ ബിറ്റ്, പലപ്പോഴും അത് മാറാം. അതിനാൽ, ഈ ഡാറ്റാ ഘടനയ്ക്കായി ഈ നടപ്പാക്കൽ പ്രത്യേകമായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു. C++ നടപ്പിലാക്കൽ, എനിക്കറിയാവുന്നിടത്തോളം, പൊതുവായ കേസിനായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു. നിങ്ങൾ പൊതുവായ കേസിനായി ഒപ്റ്റിമൈസ് ചെയ്യുകയാണെങ്കിൽ, ഒരു നിർദ്ദിഷ്ട കേസിന് ഇത് ഏറ്റവും അനുയോജ്യമാകില്ല എന്നാണ് ഇതിനർത്ഥം.

അലക്സി മിലോവിഡിന്റെ റിപ്പോർട്ട് കാണാനും ഞാൻ നിങ്ങളെ ഉപദേശിക്കുന്നു. ഏകദേശം ഒരു മാസം മുമ്പ്, നിർദ്ദിഷ്ട സ്പെഷ്യലൈസേഷനുകൾക്കായി ക്ലിക്ക്ഹൗസിലെ ഒപ്റ്റിമൈസേഷനെ കുറിച്ച് അദ്ദേഹം സംസാരിച്ചു. പൊതുവായ സാഹചര്യത്തിൽ, ഒരു C++ നടപ്പിലാക്കൽ അല്ലെങ്കിൽ മറ്റേതെങ്കിലും നടപ്പിലാക്കൽ ഒരു ആശുപത്രിയിൽ ശരാശരി നന്നായി പ്രവർത്തിക്കുന്നതിന് അനുയോജ്യമാണെന്ന് അദ്ദേഹം പറയുന്നു. നമ്മുടേത് പോലെയുള്ള വിജ്ഞാന-നിർദ്ദിഷ്‌ട നിർവ്വഹണത്തേക്കാൾ മോശമായി ഇത് പ്രവർത്തിച്ചേക്കാം, അവിടെ മികച്ച 32 ബിറ്റുകൾ സ്ഥിരമാണെന്ന് ഞങ്ങൾക്കറിയാം.

എനിക്ക് രണ്ടാമത്തെ ചോദ്യമുണ്ട്. InfluxDB-യിൽ നിന്നുള്ള അടിസ്ഥാന വ്യത്യാസം എന്താണ്?

അടിസ്ഥാനപരമായ നിരവധി വ്യത്യാസങ്ങളുണ്ട്. പ്രകടനത്തിന്റെയും മെമ്മറി ഉപഭോഗത്തിന്റെയും കാര്യത്തിൽ, ഉയർന്ന കാർഡിനാലിറ്റി ടൈം സീരീസിനായി ടെസ്റ്റുകളിലെ InfluxDB 10 മടങ്ങ് കൂടുതൽ മെമ്മറി ഉപഭോഗം കാണിക്കുന്നു, നിങ്ങൾക്ക് അവ ധാരാളം ഉള്ളപ്പോൾ, ഉദാഹരണത്തിന്, ദശലക്ഷക്കണക്കിന്. ഉദാഹരണത്തിന്, VictoriaMetrics ഒരു ദശലക്ഷം സജീവ വരികളിൽ 1 GB ഉപയോഗിക്കുന്നു, അതേസമയം InfluxDB 10 GB ഉപയോഗിക്കുന്നു. അതൊരു വലിയ വ്യത്യാസമാണ്.

രണ്ടാമത്തെ അടിസ്ഥാന വ്യത്യാസം, InfluxDB-ക്ക് വിചിത്രമായ അന്വേഷണ ഭാഷകളുണ്ട് - Flux, InfluxQL. താരതമ്യപ്പെടുത്തുമ്പോൾ സമയ ശ്രേണിയിൽ പ്രവർത്തിക്കാൻ അവ വളരെ സൗകര്യപ്രദമല്ല PromQL, ഇത് VictoriaMetrics പിന്തുണയ്ക്കുന്നു. പ്രോമിത്യൂസിൽ നിന്നുള്ള ഒരു അന്വേഷണ ഭാഷയാണ് PromQL.

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

വിക്ടോറിയമെട്രിക്സിൽ എല്ലാം വളരെ ലളിതമാണ്. അവിടെ, ഓരോ സമയ ശ്രേണിയും ഒരു പ്രധാന മൂല്യമാണ്. മൂല്യം പോയിന്റുകളുടെ ഒരു കൂട്ടമാണ് - (timestamp, value), കീ സെറ്റ് ആണ് label=value. ഫീൽഡുകളും അളവുകളും തമ്മിൽ വേർതിരിവില്ല. ഏത് ഡാറ്റയും തിരഞ്ഞെടുക്കാനും തുടർന്ന് സംയോജിപ്പിക്കാനും കൂട്ടിച്ചേർക്കാനും കുറയ്ക്കാനും ഗുണിക്കാനും ഹരിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, InfluxDB പോലെയല്ല, വ്യത്യസ്ത വരികൾക്കിടയിലുള്ള കണക്കുകൂട്ടലുകൾ എനിക്കറിയാവുന്നിടത്തോളം നടപ്പിലാക്കിയിട്ടില്ല. അവ നടപ്പിലാക്കിയാലും, അത് ബുദ്ധിമുട്ടാണ്, നിങ്ങൾ ധാരാളം കോഡ് എഴുതണം.

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

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

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

രണ്ടാമത്തേതിന് ഞാൻ ഉടൻ ഉത്തരം നൽകും. ഞങ്ങൾ ഇതുവരെ ആ അവസ്ഥയിൽ എത്തിയിട്ടില്ല. എന്നാൽ ആവശ്യമെങ്കിൽ ഞങ്ങൾ അവിടെ എത്തും. പിന്നെ ആദ്യത്തേത്, എന്തായിരുന്നു ചോദ്യം?

നിങ്ങൾ രണ്ട് സാഹചര്യങ്ങൾ ചർച്ച ചെയ്തു. കൂടുതൽ സങ്കീർണ്ണമായ നടപ്പാക്കലോടെയാണ് തങ്ങൾ രണ്ടാമത്തേത് തിരഞ്ഞെടുത്തതെന്ന് അവർ പറഞ്ഞു. സമയം അനുസരിച്ച് ഡാറ്റ വിഭജിക്കപ്പെടുന്ന ആദ്യത്തേത് അവർ തിരഞ്ഞെടുത്തില്ല.

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

അതിനാൽ - അതെ, സമയ വിഭജനം ഒരു നല്ല ഓപ്ഷനാണ്. പ്രൊമിത്യൂസ് അത് ഉപയോഗിക്കുന്നു. എന്നാൽ പ്രോമിത്യൂസിന് മറ്റൊരു പോരായ്മയുണ്ട്. ഈ ഡാറ്റാ ഭാഗങ്ങൾ ലയിപ്പിക്കുമ്പോൾ, എല്ലാ ലേബലുകൾക്കും ടൈംസറികൾക്കുമുള്ള മെമ്മറി മെറ്റാ വിവരങ്ങൾ അത് സൂക്ഷിക്കേണ്ടതുണ്ട്. അതിനാൽ, അത് ലയിപ്പിക്കുന്ന ഡാറ്റയുടെ ഭാഗങ്ങൾ വലുതാണെങ്കിൽ, വിക്ടോറിയമെട്രിക്സിൽ നിന്ന് വ്യത്യസ്തമായി ലയിപ്പിക്കുമ്പോൾ മെമ്മറി ഉപഭോഗം വളരെയധികം വർദ്ധിക്കുന്നു. ലയിപ്പിക്കുമ്പോൾ, VictoriaMetrics മെമ്മറി ഉപഭോഗം ചെയ്യുന്നില്ല; ലയിപ്പിച്ച ഡാറ്റയുടെ വലുപ്പം പരിഗണിക്കാതെ തന്നെ രണ്ട് കിലോബൈറ്റുകൾ മാത്രമേ ഉപയോഗിക്കൂ.

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

ഡാറ്റയിലൂടെ സഞ്ചരിക്കാൻ നമുക്ക് എന്തുകൊണ്ട് കഴ്‌സറുകൾ ഉപയോഗിക്കരുത്?

അതെ.

ഞങ്ങൾ അടുക്കിയ വരികൾ LevelDB അല്ലെങ്കിൽ ലയനത്തിൽ സംഭരിക്കുന്നു. നമുക്ക് കഴ്സർ നീക്കി കവല കണ്ടെത്താം. എന്തുകൊണ്ട് നമ്മൾ അത് ഉപയോഗിച്ചുകൂടാ? കാരണം അത് മന്ദഗതിയിലാണ്. കാരണം കഴ്‌സറുകൾ അർത്ഥമാക്കുന്നത് ഓരോ ലൈനിനും നിങ്ങൾ ഒരു ഫംഗ്‌ഷൻ വിളിക്കേണ്ടതുണ്ട് എന്നാണ്. ഒരു ഫംഗ്‌ഷൻ കോൾ 5 നാനോ സെക്കൻഡ് ആണ്. നിങ്ങൾക്ക് 100 ലൈനുകൾ ഉണ്ടെങ്കിൽ, ഫംഗ്‌ഷനെ വിളിക്കാൻ ഞങ്ങൾ അര സെക്കൻഡ് ചെലവഴിക്കുന്നുവെന്ന് ഇത് മാറുന്നു.

അങ്ങനെ ഒരു കാര്യമുണ്ട്, അതെ. പിന്നെ എന്റെ അവസാനത്തെ ചോദ്യവും. ചോദ്യം അൽപ്പം വിചിത്രമായി തോന്നാം. ഡാറ്റ വരുന്ന നിമിഷത്തിൽ ആവശ്യമായ എല്ലാ അഗ്രഗേറ്റുകളും വായിക്കാനും ആവശ്യമായ ഫോമിൽ സംരക്ഷിക്കാനും കഴിയാത്തത് എന്തുകൊണ്ട്? VictoriaMetrics, ClickHouse മുതലായ ചില സിസ്റ്റങ്ങളിൽ വലിയ വോള്യങ്ങൾ ലാഭിക്കുകയും പിന്നീട് അവയിൽ ധാരാളം സമയം ചെലവഴിക്കുകയും ചെയ്യുന്നത് എന്തുകൊണ്ട്?

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

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

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

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

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

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

രണ്ടാമത്തെ കാര്യം, ClickHouse പോലെയുള്ള VictoriaMetrics, വലിയ അളവിലുള്ള അസംസ്‌കൃത ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ ഒപ്റ്റിമൈസ് ചെയ്‌തിരിക്കുന്നു, അതിനാൽ നിങ്ങളുടെ സിസ്റ്റത്തിൽ നിരവധി കോറുകൾ ഉണ്ടെങ്കിൽ ഒരു സെക്കന്റിൽ താഴെ സമയത്തിനുള്ളിൽ ഇതിന് ഒരു ബില്യൺ ലൈനുകൾ കോരികയാക്കാനാകും. വിക്ടോറിയമെട്രിക്സിലെ സമയ ശ്രേണി പോയിന്റുകൾ സ്കാൻ ചെയ്യുന്നു - ഓരോ കോറിനും സെക്കൻഡിൽ 50 പോയിന്റുകൾ. ഈ പ്രകടനം നിലവിലുള്ള കോറുകളിലേക്ക് സ്കെയിൽ ചെയ്യുന്നു. അതായത്, നിങ്ങൾക്ക് 000 കോറുകൾ ഉണ്ടെങ്കിൽ, ഉദാഹരണത്തിന്, നിങ്ങൾ സെക്കൻഡിൽ ഒരു ബില്യൺ പോയിന്റുകൾ സ്കാൻ ചെയ്യും. VictoriaMetrics, ClickHouse എന്നിവയുടെ ഈ പ്രോപ്പർട്ടി ഡൗൺസാംലിംഗിന്റെ ആവശ്യകത കുറയ്ക്കുന്നു.

VictoriaMetrics ഈ ഡാറ്റ ഫലപ്രദമായി കംപ്രസ്സുചെയ്യുന്നു എന്നതാണ് മറ്റൊരു സവിശേഷത. ഉൽപാദനത്തിൽ ശരാശരി കംപ്രഷൻ ഒരു പോയിന്റിന് 0,4 മുതൽ 0,8 ബൈറ്റുകൾ വരെയാണ്. ഓരോ പോയിന്റും ഒരു ടൈംസ്റ്റാമ്പ് + മൂല്യമാണ്. കൂടാതെ ഇത് ശരാശരി ഒരു ബൈറ്റിൽ താഴെയായി കംപ്രസ് ചെയ്യപ്പെടുന്നു.

സെർജി. എനിക്കൊരു ചോദ്യമുണ്ട്. ഏറ്റവും കുറഞ്ഞ റെക്കോർഡിംഗ് സമയ ക്വാണ്ടം എന്താണ്?

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

ഞാൻ സംസാരിച്ച വ്യക്തി പറയുന്നത് അവർക്ക് സെക്കൻഡ് മുതൽ സെക്കൻഡ് വരെയുള്ള കൃത്യതയുണ്ടെന്ന് - അവർക്ക് അത് മതി, കാരണം ഇത് ടൈം സീരീസ് ഡാറ്റാബേസിൽ സംഭരിക്കുന്ന ഡാറ്റയെ ആശ്രയിച്ചിരിക്കുന്നു. ഇത് DevOps ഡാറ്റയോ ഇൻഫ്രാസ്ട്രക്ചറിൽ നിന്നുള്ള ഡാറ്റയോ ആണെങ്കിൽ, നിങ്ങൾ മിനിറ്റിൽ 30 സെക്കൻഡ് ഇടവിട്ട് ശേഖരിക്കുന്നുണ്ടെങ്കിൽ, രണ്ടാമത്തെ കൃത്യത മതി, നിങ്ങൾക്ക് അതിൽ കുറവൊന്നും ആവശ്യമില്ല. ഉയർന്ന ഫ്രീക്വൻസി ട്രേഡിംഗ് സിസ്റ്റങ്ങളിൽ നിന്നാണ് നിങ്ങൾ ഈ ഡാറ്റ ശേഖരിക്കുന്നതെങ്കിൽ, നിങ്ങൾക്ക് നാനോ സെക്കൻഡ് കൃത്യത ആവശ്യമാണ്.

VictoriaMetrics-ലെ മില്ലിസെക്കൻഡ് കൃത്യത DevOps കേസിനും അനുയോജ്യമാണ്, റിപ്പോർട്ടിന്റെ തുടക്കത്തിൽ ഞാൻ സൂചിപ്പിച്ച മിക്ക കേസുകൾക്കും ഇത് അനുയോജ്യമാകും. ഇത് അനുയോജ്യമല്ലാത്ത ഒരേയൊരു കാര്യം ഉയർന്ന ഫ്രീക്വൻസി ട്രേഡിംഗ് സിസ്റ്റങ്ങളാണ്.

നന്ദി! ഒപ്പം മറ്റൊരു ചോദ്യവും. PromQL-ൽ എന്താണ് അനുയോജ്യത?

പൂർണ്ണമായ പിന്നോക്ക അനുയോജ്യത. VictoriaMetrics പൂർണ്ണമായും PromQL-നെ പിന്തുണയ്ക്കുന്നു. കൂടാതെ, ഇത് PromQL-ൽ കൂടുതൽ വിപുലമായ പ്രവർത്തനം ചേർക്കുന്നു, അതിനെ വിളിക്കുന്നു MetricsQL. ഈ വിപുലമായ പ്രവർത്തനത്തെക്കുറിച്ച് YouTube-ൽ ഒരു ചർച്ചയുണ്ട്. സെന്റ് പീറ്റേഴ്‌സ്ബർഗിലെ വസന്തകാലത്ത് മോണിറ്ററിംഗ് മീറ്റപ്പിൽ ഞാൻ സംസാരിച്ചു.

ടെലിഗ്രാം ചാനൽ വിക്ടോറിയമെട്രിക്സ്.

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

പ്രൊമിത്യൂസിനായി നിങ്ങളുടെ ദീർഘകാല സംഭരണമായി വിക്ടോറിയമെട്രിക്സിലേക്ക് മാറുന്നതിൽ നിന്ന് നിങ്ങളെ തടയുന്നതെന്താണ്? (അഭിപ്രായങ്ങളിൽ എഴുതുക, ഞാൻ അത് വോട്ടെടുപ്പിൽ ചേർക്കും))

• 71,4%ഞാൻ Prometheus5 ഉപയോഗിക്കുന്നില്ല

• 28,6%VictoriaMetrics2 നെ കുറിച്ച് അറിയില്ലായിരുന്നു

7 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 12 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

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